ECMAScript discouraged/legacy feature

[captainbrosset]

I'm going over the last remaining javascript.* BCD keys that correspond to legacy/non-standard features and that we haven't mapped yet, and trying to create features for them in the repo.

A few of them are mentioned in the ECMAScript spec as legacy, which is great, because we can link that those notes in according_to. However, a bunch of other features are simply non-standard and therefore do not exist in the spec. Maybe they once did, but not anymore, and there's no official note saying that they are now deprecated.

The only feature in this PR contains the keys for which there's a note in the spec. So that's the easy case.
The other cases are listed below, with my notes:

Not mentioned in the spec, only mentioned in BCD compat table on MDN.

• javascript.builtins.AggregateError.serializable_object

Discouraged on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Symbol.species
Potentially related note in the spec: https://tc39.es/ecma262/#sec-arrayspeciescreate
which says something about historical browser behavior.

• javascript.builtins.Array.@@species

Not on MDN, not in spec

• javascript.builtins.Atomics.pause

Discouraged on MDN, but no mentions in spec.

• javascript.builtins.Function.arguments
• javascript.builtins.Function.caller
• javascript.builtins.Function.displayName

Not in strict mode according to:
https://tc39.es/ecma262/#sec-strict-mode-of-ecmascript

• javascript.functions.arguments.callee

Discouraged on MDN, but no mentions in spec.

• javascript.builtins.InternalError.InternalError
• javascript.builtins.InternalError

Mentioned as optional by MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#return_value
Likely due to this spec note: https://tc39.es/ecma402/#sec-intl.datetimeformat

• javascript.builtins.Intl.DateTimeFormat.DateTimeFormat.IntlLegacyConstructedSymbol
• javascript.builtins.Intl.NumberFormat.NumberFormat.IntlLegacyConstructedSymbol

Deprecated on MDN, but not mentioned in the spec

• javascript.builtins.RegExp.input
• javascript.builtins.RegExp.lastMatch
• javascript.builtins.RegExp.lastParen
• javascript.builtins.RegExp.leftContext
• javascript.builtins.RegExp.n
• javascript.builtins.RegExp.rightContext

??

• javascript.grammar.trailing_commas.trailing_commas_in_dynamic_import

??

• javascript.operators.import.options_parameter

(See #2565) MDN notes that there once was an assert keyword: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import/with
But not in spec. Likely was never standard. Might need to ignore this until it gets removed from BCD.

• javascript.statements.import.import_assertions
• javascript.statements.import.import_assertions.type_css
• javascript.statements.import.import_assertions.type_json

Non-standard on MDN, and not in spec.

• javascript.builtins.Error.Error.fileName_parameter
• javascript.builtins.Error.Error.lineNumber_parameter
• javascript.builtins.Error.cause.displayed_in_console
• javascript.builtins.Error.columnNumber
• javascript.builtins.Error.fileName
• javascript.builtins.Error.lineNumber
• javascript.builtins.Error.stack

[ddbeck]

MDN notes that there once was an assert keyword: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import/with But not in spec. Likely was never standard. Might need to ignore this until it gets removed from BCD.

• javascript.statements.import.import_assertions
• javascript.statements.import.import_assertions.type_css
• javascript.statements.import.import_assertions.type_json

This one feels like a trick on the part of the spec authors. They subbed in a new proposal in the husk of the old proposal, burying the failed proposal. This feels like a case where a feature actually existed, was briefly promoted to developers, then yanked. web-features should reflect that.

I think this would actually be a good demonstration of a path for a removed-from-spec feature (and later a "deleted" feature). I've opened #2565 for these keys.

[ddbeck]

I'm suggesting a possible alternate route here: break these out into smaller features, to make the discouragement data more useful, when it comes to referencing current (and future) alternatives data.

I'll break this down in the line comments.

[ddbeck]

I think breaking this out into a separate feature (something like "escape() and unescape()") would help us do better discouragement information. We don't have all the data for this yet (it'd be nice to reference and "internal" feature on javascript for encodeURIComponent() and friends) but I'm thinking ahead here about how a consumer like MDN might be able to use this data for useful developer content (as on the current MDN page).

[ddbeck]

These also look like they might work better as standalone HTML wrapper methods feature, an alternative being the dom feature.

[ddbeck]

This one could be a "__defineGetter__() and __defineSetter__()" feature. For now it could have functions as an alternative, with the possibility of referencing an inner feature (get and set syntax) in the future.

[ddbeck]

I guess these two could make sense together as well.

[ddbeck]

Now that I've gotten to the end, I'm left with just a few miscellaneous, single-key items:

• __proto__
• RegExp.compile()
• toGMTString

This isn't too bad? I'd be willing to tolerate having features for these, if it makes the consistency and shape of the other features mentioned above more legible.

[ddbeck]

Not mentioned in the spec, only mentioned in BCD compat table on MDN.

• javascript.builtins.AggregateError.serializable_object

I think this one might actually be standard track. It's so messy though. I've sent mdn/browser-compat-data#25744 to settle the question.

[ddbeck]

Discouraged on MDN, but no mentions in spec.

• javascript.builtins.Function.arguments
• javascript.builtins.Function.caller

These are mentioned in Forbidden extensions. I think we could override BCD with these and say that they're specified only to the extent that authors should not use them. What do you think of that?

[ddbeck]

Mentioned as optional by MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat#return_value Likely due to this spec note: https://tc39.es/ecma402/#sec-intl.datetimeformat

• javascript.builtins.Intl.DateTimeFormat.DateTimeFormat.IntlLegacyConstructedSymbol

• javascript.builtins.Intl.NumberFormat.NumberFormat.IntlLegacyConstructedSymbol

I think this was wrongly recorded in BCD. I've sent mdn/browser-compat-data#25749.