Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Conversation

diekus
Copy link

@diekus diekus commented Oct 14, 2025

@github-actions github-actions bot added the feature definition Creating or defining new features or groups of features. label Oct 14, 2025
Comment on lines +4 to +6
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

@ddbeck ddbeck Oct 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I like the idea of linking to, in order of preference:

  1. An actual spec known to browser-specs
  2. A PR against an actual spec known to browser-specs
  3. Any other PR
  4. Any other URL

#2647 exists to track this idea though it doesn't mention the proposal behavior. I'll put a comment there file a new issue. (edit: no it doesn't, wrong thing)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I created #3470

Copy link
Contributor

@captainbrosset captainbrosset left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of suggestions for the name and description.

features/at-rule.yml Outdated Show resolved Hide resolved
features/at-rule.yml Outdated Show resolved Hide resolved
diekus and others added 2 commits October 14, 2025 15:22
Co-authored-by: Patrick Brosset <patrickbrosset@gmail.com>
Co-authored-by: Patrick Brosset <patrickbrosset@gmail.com>
@@ -0,0 +1,7 @@
name: at-rule()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +4 to +6
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
Copy link
Collaborator

@ddbeck ddbeck Oct 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I like the idea of linking to, in order of preference:

  1. An actual spec known to browser-specs
  2. A PR against an actual spec known to browser-specs
  3. Any other PR
  4. Any other URL

#2647 exists to track this idea though it doesn't mention the proposal behavior. I'll put a comment there file a new issue. (edit: no it doesn't, wrong thing)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature definition Creating or defining new features or groups of features.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

Morty Proxy This is a proxified and sanitized view of the page, visit original site.