Adds the at-rule feature
#3449
Adds the at-rule feature
#3449
Conversation
Adds the at-rule feature.
github-actions
bot
added
the
feature definition
| https://www.w3.org/TR/css-conditional-5/ | ||
| https://github.com/w3c/csswg-drafts/pull/12945 | ||
| https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AtRuleFeatureDetection/explainer.md |
There was a problem hiding this comment.
I'm the one who asked Diego to add all 3 URLs here, but we should choose one. @ddbeck do you think it's better to link to the spec (even if doesn't have the changes for this feature in it yet), the PR that's making the changes, or the explainer?
There was a problem hiding this comment.
Looking at other features, it seems like we could choose between pointing to the explainer or the PR. I would vote for the PR because this way it's easy to later check if the PR has been merged, and update the link to the proper spec.
If we link to the explainer, it's maybe more useful for developers, but there's no easy sign to know that an explainer has graduated to a spec, and which one.
So let's perhaps use the PR URL only.
But, also, the build will fail if we do this. To make the build happy, please also add the PR URL to the defaultAllowlist array in /scripts/specs.ts, with a reason why the PR is allowed (e.g. because that's the closest thing we have to a spec).
There was a problem hiding this comment.
Of the 3 links suggested, I think we should only link the w3c/csswg-drafts#12945. That's something that a script can look at and determine when the PR is merged and the spec URL can be updated.
@ddbeck has proposed that we should use proposal instead of spec for this situation, and that would avoid the defaultAllowlist problem.
There was a problem hiding this comment.
Yes, I like the idea of linking to, in order of preference:
- An actual spec known to
browser-specs - A PR against an actual spec known to
browser-specs - Any other PR
- Any other URL
#2647 exists to track this idea though it doesn't mention the . I'll proposal behaviorput a comment there file a new issue. (edit: no it doesn't, wrong thing)
Co-authored-by: Patrick Brosset <patrickbrosset@gmail.com>
Co-authored-by: Patrick Brosset <patrickbrosset@gmail.com>
| @@ -0,0 +1,7 @@ | |||
| name: at-rule() | |||
There was a problem hiding this comment.
I think this needs a different ID, to avoid confusion with the concept of an at-rule in general. An ID like supports-at-rule (thinking that this might some day fold into @supports) might be a good alternative.
| https://www.w3.org/TR/css-conditional-5/ | ||
| https://github.com/w3c/csswg-drafts/pull/12945 | ||
| https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AtRuleFeatureDetection/explainer.md |
There was a problem hiding this comment.
Yes, I like the idea of linking to, in order of preference:
- An actual spec known to
browser-specs - A PR against an actual spec known to
browser-specs - Any other PR
- Any other URL
#2647 exists to track this idea though it doesn't mention the . I'll proposal behaviorput a comment there file a new issue. (edit: no it doesn't, wrong thing)
4 participants
See: