javascript.statements.with - The feature is NOT deprecated

[dcleao]

What information was incorrect, unhelpful, or incomplete?

Indication that the feature is deprecated is incorrect.
The feature is not allowed in strict mode.
However, the feature is allowed in "sloppy" mode, even if its use is highly discouraged.

What did you expect to see?

Either no indication of deprecation at all, or an indication of only being available in strict mode, possibly, complemented with a note of discouraged use.

MDN page report details

• Query: javascript.statements.with
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with
• Report started: 2021-05-14T11:02:09.499Z

[queengooborg]

Deprecated doesn't necessarily mean that it isn't supported in browsers any longer, but rather that its use is not recommended and it may be removed from browsers in the near future. In other words, yes, the data is correct. The MDN page does include a note mentioning that this feature is not available in ECMAScript 5's strict mode.

[dcleao]

@vinyldarkscratch I disagree with your interpretation. Deprecated means, in any reasonable interpretation, that the feature has been officially deprecated. But it has not. Can you find such a deprecation notice in any ECMAScript document?

The MDN page itself is correct. What is incorrect is the browser compat table, with the down pointing hand character and the associated legend.

[queengooborg]

What I've described comes straight from the schema documentation for the deprecated property on BCD content:

If deprecated is true, then the feature is no longer recommended. It might be removed in the future or might only be kept for compatibility purposes. Avoid using this functionality.

[ddbeck]

To elaborate a little on this point, BCD uses the term deprecated to mean discouraged from use, not just the cases where a standards body has used the word "deprecated." This is to capture all of the ways that various standards organizations and browser vendors signal to web developers that certain features are to be avoided. This also lets us set meaningful data even if there are conflicting signals (e.g., when browser vendors begin to withdraw features which are still part of active specifications).

For example, the HTML spec uses the term "obsolete" to describe features which are specified and widely-supported but nevertheless discouraged. We mark those features as deprecated, even though that's not the terminology used by the HTML spec authors.

In the case of the with statement, we've made a judgement that the ECMAScript authors are discouraging the use of the feature by forbidding it in strict mode, which is no longer opt-in in many contexts. While they have not (and to my knowledge, never intend to) formally deprecate any feature, they have made the with feature broadly incompatible with new language features (such as modules). We think that's a pretty strong signal about what web developers should do with the with statement, even if the specification requires implementers to continue to support it.

[dcleao]

In my opinion, MDN or BCD should not have a distinct definition of either "deprecated" or "obsolete" than the specification which defines a feature. It's irrelevant (for me, at least) what "engines" think of or advise about a feature. They either implement it or not (or in some form). In a documentation page, you describe a feature as defined in the referenced specifications, and it should be as defined in those referenced specifications that a feature is listed as deprecated or not.

As for the several nuances of the meaning of deprecation, you should probably consider the introduction of a new category such as "discouraged use" or "legacy" to map to the cases where the specification does not deprecate a feature (possibly because it cannot), but still advises people to not use it.

As is, I believe that the information you provide is specially confusing and needlessly interpretative.

[dcleao]

@ddbeck what do you think of my arguments?

[ddbeck]

@dcleao I appreciate where you're coming from on this issue and I share some of your frustrations.

A funny thing about having worked on this project for a long time is that everything is subject to interpretation. Seemingly simple questions about whether something is or isn't supported are up for debate more often than you might suspect. There are over 13,000 features recorded in BCD. Most of the time things are clear cut, but our schema has to cover the edges cases too.

For example, you said that it wasn't relevant to you what an engine thinks of a particular feature, which is fair. Nevertheless, our schema needs to accommodate features which are non-standard, unspecified, or were formerly specified and dropped or deferred from specifications. Standard organizations are just one actor in a broad community of people who make the web platform; their perspective is important, but it's not the only one.

Now, perhaps we erred in calling the field "deprecated" or the way we defined it. There are several things about BCD that I'd love to go back and rethink. But we do have 13,000 features and several consumers of compat data (apart from MDN), so it's hard to make big changes quickly. I'll keep your ideas in mind, but there are several big issues already on our agenda, so this specific area is not likely to get attention soon.

I do have one bit of good news, however: in general, we're trying to de-emphasize the status data. For example, we're trying to fill out all the spec_url data, which we believe will more accurately represent the standards status of features than our existing standard_track field. Someday, we hope to retire the standard_track field, or set it automatically based on the specifications themselves. Similarly, we've recently revamped the way we set the experimental status, again with the aim of eventually setting it automatically based on support data or retiring it outright (see #9933).

I've gone on long enough, but here's my last word on it: these efforts will take time, but it's our hope that as our data coverage and accuracy improves, you'll get a complete story of every feature. Perhaps you'll never agree with our deprecation status, but I want to make sure that the other data, such as specifications and which browsers continue to support a feature, will tell you what you need to know to make informed decisions for yourself about what features to use or not use.

[dcleao]

@ddbeck Thank you for your response.

When I say that "it's irrelevant to me what engines think", I'm talking specifically about their "opinion" and "interpretation" on what is considered deprecated (and kind of assuming, possibly incorrectly, that it is people from the "engines" which are collecting this data and writing these "opinions"). What I mean is that, whatever their opinion and interpretation it should not be stated as being what is specified. Something is considered obsolete/deprecated or not exactly as stated in the associated spec.

If a feature has no standard's body specification, when, for example, it was "invented" by a certain engine, then, their opinion is the one that counts — they created the specification, after all. This is a degenerate case.

When engines have a different implementation of what is spec'ed, or if and when they decide to stop supporting a non-deprecated feature (as defined by the spec), that's exactly the data that you are/should be capturing — the deviations from the spec, and I think you do that very well.

Alas, except when "you" deviate from whatever is the specific spec's obsolete/deprecation meaning and status. There should be no doubt when a statement is the opinion/choice of an engine(s).

The authoritative body and specification regarding the OP is ECMAScript, TC-39, not MDN or BCD.

Finally, you may come to change it or not, depending on all sorts of constraints — that's life! But, the discussion here is whether you should do it or not — the discussion is nowhere constrained by those constraints.

So, it would be great if "you" could be clear regarding whether "you" think this should eventually be changed or if "you" would do it differently, if "you" could. The quick closing of the issue surely wasn't clear (or seen as polite/correct) to me. And, up until now, nor did the given justifications convince me.

In any case, peace! And, I wish you do a great work!

[ddbeck]

@dcleao Thank you! I apologize that the original closure was unclear to you. Lots of issues come up, so it's easy to get on autopilot and assume too much understanding of the background details.

So, it would be great if "you" could be clear regarding whether "you" think this should eventually be changed or if "you" would do it differently, if "you" could. The quick closing of the issue surely wasn't clear (or seen as polite/correct) to me. And, up until now, nor did the given justifications convince me.

I'll be as clear as I can about what could or would happen next:

• I think the specific case here (with statement deprecation) should not change. I think we've set the correct value with respect to the definition we have promised to BCD's consumers. To change this data would require changing our definition of deprecated, or to replace it with something else.
• I'd be open to proposals changing that stuff, but I don't plan to follow up on this myself (with a new issue, for example), for two main reasons: 1) BCD's consumers (MDN itself, caniuse, etc.) have not expressed demand for this yet and 2) I don't have the time, with respect to other ongoing projects.
• That said, I will keep this in mind. This is the first time I can recall there being much of a dispute about the way we use deprecated in BCD, but that doesn't mean it will be the last. If this (or something similar) is raised in the future, I'll certainly reevaluate.

Additionally, I wanted to highlight a couple things about these points:

The authoritative body and specification regarding the OP is ECMAScript, TC-39, not MDN or BCD.

it is people from the "engines" which are collecting this data and writing these "opinions"

You're partly right, in that browser vendors are well-represented when it comes to participation in BCD. But we get lots of participation here from specification authors, web developers of various allegiances, and independent technical experts. It's not uncommon for a spec author to correct an error in our data. Like MDN more broadly, BCD tries to be vendor neutral; nobody can build websites for just one browser, after all. The data you see here ought to reflect a consensus viewpoint, not an assertion from any one party.

[dcleao]

@ddbeck Thank you, once more, for your patience and response.

Regarding:

this is the first time I can recall there being much of a dispute about the way we use deprecated in BCD

This might be a relevant data point:
https://stackoverflow.com/questions/48810592/is-the-javascript-keyword-with-really-deprecated

[ddbeck]

@dcleao Thank you! That's a really interesting link. This has kicked off a bit more research into ways of representing deprecation in MDN and BCD. I'll tag you if/when issues come out of it.