Skip to content

named-feature-explainer.md

Latest commit

 

History

History
111 lines (86 loc) · 4.61 KB

named-feature-explainer.md

File metadata and controls

111 lines (86 loc) · 4.61 KB

Specific feature detection: The named-feature() function for @supports

L. David Baron (@dbaron), January 2026

Particpate

Introduction

Developers writing stylesheets sometimes want to use new features in a way that improves the experience for users using implementations that support those features, but that gracefully degrades to a usable but less ideal experience in older implementations that do not.

The first mechanism for feature detection in CSS is its error handling rules. CSS has well-defined parsing rules that cause syntax not known to an implementation to be ignored. This allows newly-introduced syntax to be ignored by older implementations. This is sufficient when ignoring only the new syntax is enough.

However, sometimes developers need other pieces of CSS syntax to be ignored along with the new syntax, so that styles work together depending on whether or not a new feature is supported. The CSS @supports rule was introduced to address this need; it is a mechanism for feature detection in CSS syntax. It has general mechanisms for detecting support for CSS properties and values, CSS selectors, CSS at-rules, and some other general mechanisms.

However, sometimes feature-detection for a specific new feature would be useful for developers to improve the experience for their users, but the feature doesn't fit into the general mechanisms that @supports provides. For example, a piece of CSS syntax might work in a new situation where it didn't do so before, such as on a new CSS display type or a new type of element. Adding mechanisms to @supports to detect every such case would require defining "support" for millions of combinations of these features, which would be infeasable to standardize, implement, test, and get interoperability on. However, there are a small number of such features introduced (probably a low single digit number per year) where we know there is real demand for such feature detection.

The named-feature() function is designed to address this demand for feature detection by adding names for the features where feature detection is needed without needing to solve the problem of defining what combinations of support mean across millions of possible combinations.

Proposed approach

The proposed approach to address this is to add the named-feature() function to the @supports rule, and have the CSS specification define a limited number of keywords to address specific feature detection problems.

For example, if a developer wants to detect whether the align-content property is supported on elements with display: block, they could do something like:

@supports named-feature(align-content-on-display-block) {
  main {
    min-height: min-content;
    align-content: stretch;
  }
}

Alternatives considered

Feature detection for combinations of features

An alternative that was considered was feature detection for combinations of features. For example, we could add a syntax like with to @supports rules such as

@supports (align-content: stretch) with (display: block) {
  /* rules here */
}

The problem with this syntax is that there are millions of combinations and there is no existing data source that represents which ones are meaningful today and which ones are not. This means that the working group would need to define the behavior for these millions of combinations which would either dramatically slow the development of CSS overall or would lead to many combinations that are initially defined wrong, which would then make the feature detection not work when the combination is actually supported meaningfully.

Accessibility, Internationalization, Privacy, and Security Considerations

While developers in general need to test feature detection code carefully to make sure that their testing covers all of the relevant branches, this doesn't pose any considerations that are specific to accessibility or internationalization other than generally increasing their testing matrix (because the testing matrices for accessibility and internationalization should probably combine with the matrices for feature detection, at least to some degree).

We're not aware of any privacy and security considerations since this feature detection is generally testing characteristics of the implementation which are already detectable by developers in other ways.

Stakeholder Feedback / Opposition