Add more spec_urls; set some standard_tracks to false (APIs A-E)#27671
Add more spec_urls; set some standard_tracks to false (APIs A-E)#27671
Conversation
github-actions
bot
added
data:api
|
Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs). |
| }, | ||
| "entries": { | ||
| "__compat": { | ||
| "spec_url": "https://webaudio.github.io/web-audio-api/#audioparammap", |
There was a problem hiding this comment.
Some exploratory thoughts:
- Could we remove
spec_urls identical to the parent in the builtdata.json? (This way, we can still validate, but keep the published data concise.) - What if we changed the data to
spec: { url: "…" }, allowingspec: "inherit"andspec: { pr_url: "…" }? (Doesn't mean we have to change the published data.)
There was a problem hiding this comment.
The goal for having a spec_url is to be sure that the BCD feature points to something that is real and standardized. We already have several BCD features pointing to the same spec_url. I don't understand why it would be desirable to introduce additional complexity (neither from the authoring side nor from the publishing side).
From a published data point of view, my sense is that always having a spec_url would be great for consumers. And if there isn't one, it means the feature is not specified anywhere. That goal is also formulated in #1531.
Is it okay to merge? |
Yes, thanks for taking a look! I will proceed with more additions like this given that no one seems to hate it :) |
|
Let's mark as draft for now then, I'll happily go through the changes to double check once complete. |
github-actions
bot
added
size:l
Elchi3
changed the title
github-actions
bot
added
the
merge conflicts 🚧
|
This pull request has merge conflicts that must be resolved before it can be merged. |
github-actions
bot
added
linter
Mostly: ```diff -https://drafts.fxtf.org/geometry/ +https://drafts.csswg.org/geometry/ ```
github-actions
bot
removed
the
merge conflicts 🚧
| "force_parameter": { | ||
| "__compat": { | ||
| "description": "`force` parameter", | ||
| "spec_url": "https://dom.spec.whatwg.org/#dom-domtokenlist-toggle", |
There was a problem hiding this comment.
@Elchi3 This is actually a good example of how an internal "inherit" value could prevent the spec_url from diverging from the parent spec_url:
- force_parameter: https://dom.spec.whatwg.org/#dom-domtokenlist-toggle
- parent: https://dom.spec.whatwg.org/#ref-for-dom-domtokenlist-toggle①
Essentially "inherit" would mean there's no specific fragment for this subfeature; see the parent feature.
Also, having "inherit" might actually encourage people to add more specific fragment links.
github-actions
bot
added
the
merge conflicts 🚧
|
This pull request has merge conflicts that must be resolved before it can be merged. |
3 participants
This is a bit of a test PR to see if we could add spec_urls everywhere (especially for behavioral sub features).
Some things came up where we should probably agree on spec_url consistency for a few common sub features:
I decided to use the spec_url for the interface itself, happy to hear other thoughts.
Also, I think when a sub aspect of e.g. a method is described then it is okay to link to the same spec section as the method. So, basically the sub feature gets the same spec_url as the parent feature.
I marked standard_track false for a few things: CSSPrimitiveValue, CSSValue, CSSValueList, DOMError, FeaturePolicy. Doesn't look like these will be going anywhere.
Fixes #27456.