#1186: Other Spec Review: named-feature() function for CSS @supports

Visit on Github

Opened Jan 15, 2026

Specification

https://drafts.csswg.org/css-conditional-5/#typedef-supports-named-feature-fn

Explainer

https://github.com/w3c/csswg-drafts/blob/main/css-conditional-5/named-feature-explainer.md

Links

  • Previous early design review, if any: N/A
  • An introduction to the feature, aimed at unfamiliar audiences: see introduction to explainer
  • A description of the problems that end-users were facing before this proposal: see introduction to explainer. (This is a little bit meta: it's about helping users get the benefits of other new CSS features sooner, in cases where there's a graceful degradation path for the lack of those features.)
  • Alternatives considered: see alternatives considered section of explainer
  • Examples of how to use the proposal to solve the end-users' problems: see proposed approach section of explainer
  • What do the end-users experience with this proposal: This helps end users get the benefits of other CSS features sooner, in cases where there is a graceful degradation path for implementations that lack the feature.
  • User research you did to validate the problem and/or design, if any: None
  • Web Platform Tests: None yet

The specification

Where and by whom is the work is being done?

Feedback so far

You should also know that...

No response

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1186

Discussions

Log in to see TAG-private discussions.

Discussed Jan 26, 2026 (See Github)

(see above)

Comment by @christianliebel Jan 26, 2026 (See Github)

@dbaron Thank you for your proposal. We are concluding it as satisfied with concerns, with the primary concern being that you might either transfer the “Cartesian explosion” of potential combinations to the named-feature registry or, if it’s seldom used, end up with a potentially abandoned list that will need to be maintained indefinitely. Apart from that, we believe your proposal benefits site authors.

Same side note as for @supports(at-rule(…)): We believe that feature detection might theoretically allow for fingerprinting. While feature support could be derived from the user agent string, initiatives are underway to reduce its entropy, such as by freezing or restricting it. In that case, feature detection might provide an additional fingerprinting bit. However, depending on the exact feature, developers are likely already able to query support by defining a certain style and checking if it is applied properly.