-
Notifications
You must be signed in to change notification settings - Fork 208
Add discouraged to schema (and with statement demo feature)
#2388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 8 commits
2404295
99cd502
855b48e
308a3ef
036e19e
78311b6
3a5896b
eb62063
fc94af6
a9a00dc
d1dbb46
54fdc49
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,24 @@ | ||
| name: with | ||
| description: The `with` JavaScript statement adds a given object to the chain of scopes used to evaluate names. | ||
| spec: https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-with-statement | ||
| group: javascript | ||
| discouraged: | ||
| # One thing that is potentially missing here is a "reason" like this: | ||
|
|
||
| # reason: browser-warning | ||
| # reason: spec-caution | ||
| # reason: pending-removal | ||
|
|
||
| # This would allow us to signal to tools how "fatal" the discouragement is | ||
| # (e.g., pending-removal should trigger noisy errors for developers but spec | ||
| # caution would not). I'm not sure the full range of these yet; I think it | ||
| # might be easier to choose the set of reasons after we've enumerated a bunch | ||
| # of discouraged features. | ||
| according_to: | ||
| - https://tc39.es/ecma262/multipage/ecmascript-language-statements-and-declarations.html#sec-with-statement | ||
| alternatives: | ||
| - destructuring | ||
| compat_features: | ||
| - javascript.statements.with | ||
| - javascript.builtins.Symbol.unscopables | ||
| - javascript.builtins.Array.@@unscopables |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,50 @@ | ||
| # Generated from: with.yml | ||
| # Do not edit this file by hand. Edit the source file instead! | ||
|
|
||
| status: | ||
| baseline: false | ||
| support: | ||
| chrome: "38" | ||
| chrome_android: "38" | ||
| edge: "12" | ||
| firefox: "48" | ||
| firefox_android: "48" | ||
| safari: "10" | ||
| safari_ios: "10" | ||
|
Comment on lines
+5
to
+13
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Given the current Baseline definition, this is correct. That said, I expect consumers (like MDN and caniuse) to choose to suppress the Baseline information when there's a discouragement. |
||
| compat_features: | ||
| # baseline: high | ||
| # baseline_low_date: 2016-08-02 | ||
| # baseline_high_date: 2019-02-02 | ||
| # support: | ||
| # chrome: "38" | ||
| # chrome_android: "38" | ||
| # edge: "12" | ||
| # firefox: "48" | ||
| # firefox_android: "48" | ||
| # safari: "9" | ||
| # safari_ios: "9" | ||
| - javascript.builtins.Symbol.unscopables | ||
|
|
||
| # baseline: high | ||
| # baseline_low_date: 2016-09-20 | ||
| # baseline_high_date: 2019-03-20 | ||
| # support: | ||
| # chrome: "38" | ||
| # chrome_android: "38" | ||
| # edge: "12" | ||
| # firefox: "48" | ||
| # firefox_android: "48" | ||
| # safari: "10" | ||
| # safari_ios: "10" | ||
| - javascript.builtins.Array.@@unscopables | ||
|
|
||
| # baseline: false | ||
| # support: | ||
| # chrome: "1" | ||
| # chrome_android: "18" | ||
| # edge: "12" | ||
| # firefox: "1" | ||
| # firefox_android: "4" | ||
| # safari: "1" | ||
| # safari_ios: "1" | ||
| - javascript.statements.with | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -57,6 +57,30 @@ | |
| "description": "Short description of the feature, as an HTML string", | ||
| "type": "string" | ||
| }, | ||
| "discouraged": { | ||
| "additionalProperties": false, | ||
| "description": "Whether developers are formally discouraged from using this feature", | ||
| "properties": { | ||
| "according_to": { | ||
| "description": "Links to a formal discouragement notice, such as specification text, intent-to-unship, etc.", | ||
| "items": { | ||
| "description": "URI", | ||
| "format": "uri", | ||
| "type": "string" | ||
| }, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think about making this an object with both URI and link text? Having the URI only forces consumers to come up with some link text on their own (or display the full URI, which isn't great).
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is a good idea, but I'm slightly concerned about us making guesses about what kind of text that consumers would like. I could imagine several different plausible ways to turn discouragement citations into text (I had a try below). I think it might be better to see how MDN and others actually end up using this and what works with developers, before committing to a single way of doing link text. I do think we should revisit this, like the reason enums. Possible ways to show this stuff:
All are possible without a handwritten text field. |
||
| "type": "array" | ||
| }, | ||
| "alternatives": { | ||
| "description": "IDs for features that substitute some or all of this feature's utility", | ||
| "items": {}, | ||
| "type": "array" | ||
| } | ||
| }, | ||
| "required": [ | ||
| "according_to" | ||
| ], | ||
| "type": "object" | ||
| }, | ||
|
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a semver minor event. |
||
| "group": { | ||
| "anyOf": [ | ||
| { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would omit the "non-standard" part here. There are many non-standard (yet) features that are not discouraged, per se.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've removed this with fc94af6. I think it's true—particularly when a spec absorbs some but not all functionality from a non-standard predecessor—but it probably doesn't add clarity here (without more explanation).