Skip to content

Commit b3c5007

Browse files
dbarondbaron
committed
[css-conditional-5] Add explainer for named-feature().
1 parent 0220ef7 commit b3c5007

1 file changed

Lines changed: 111 additions & 0 deletions

File tree

‎css-conditional-5/named-feature-explainer.md‎

Lines changed: 111 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,111 @@
1+
# Specific feature detection: The `named-feature()` function for `@supports`
2+
3+
L. David Baron ([@dbaron](https://github.com/dbaron)), January 2026
4+
5+
## Particpate
6+
7+
* https://github.com/w3c/csswg-drafts/issues
8+
* https://github.com/w3c/csswg-drafts/issues/3559
9+
* https://github.com/w3c/csswg-drafts/issues/9875
10+
11+
## Introduction
12+
13+
Developers writing stylesheets sometimes want to use new features
14+
in a way that improves the experience for users
15+
using implementations that support those features,
16+
but that gracefully degrades to a usable but less ideal experience
17+
in older implementations that do not.
18+
19+
The first mechanism for feature detection in CSS is its error handling rules.
20+
CSS has well-defined parsing rules that cause syntax not known to an implementation
21+
to be ignored.
22+
This allows newly-introduced syntax to be ignored by older implementations.
23+
This is sufficient when ignoring only the new syntax is enough.
24+
25+
However, sometimes developers need other pieces of CSS syntax to be ignored
26+
along with the new syntax, so that styles work together depending on whether or not
27+
a new feature is supported.
28+
The CSS `@supports` rule was introduced to address this need;
29+
it is a mechanism for feature detection in CSS syntax.
30+
It has general mechanisms for detecting support for CSS properties and values,
31+
CSS selectors, CSS at-rules, and some other general mechanisms.
32+
33+
However, sometimes feature-detection for a specific new feature would be useful
34+
for developers to improve the experience for their users,
35+
but the feature doesn't fit into the general mechanisms that `@supports` provides.
36+
For example, a piece of CSS syntax might work in a new situation where it didn't do so before,
37+
such as on a new CSS display type or a new type of element.
38+
Adding mechanisms to `@supports` to detect every such case
39+
would require defining "support" for millions of combinations of these features,
40+
which would be infeasable to standardize, implement, test, and get interoperability on.
41+
However, there are a small number of such features introduced
42+
(probably a low single digit number per year)
43+
where we know there is real demand for such feature detection.
44+
45+
The `named-feature()` function is designed to address this demand for feature detection
46+
by adding names for the features where feature detection is needed
47+
without needing to solve the problem of defining
48+
what combinations of support mean across millions of possible combinations.
49+
50+
## Proposed approach
51+
52+
The proposed approach to address this is to add the `named-feature()` function
53+
to the `@supports` rule,
54+
and have the CSS specification define a limited number of keywords
55+
to address specific feature detection problems.
56+
57+
For example, if a developer wants to detect whether the `align-content` property
58+
is supported on elements with `display: block`, they could do something like:
59+
60+
```css
61+
@supports named-feature(align-content-on-display-block) {
62+
main {
63+
min-height: min-content;
64+
align-content: stretch;
65+
}
66+
}
67+
```
68+
69+
## Alternatives considered
70+
71+
### Feature detection for combinations of features
72+
73+
An alternative that was considered was feature detection for combinations of features.
74+
For example, we could add a syntax like `with` to `@supports` rules such as
75+
76+
```css
77+
@supports (align-content: stretch) with (display: block) {
78+
/* rules here */
79+
}
80+
```
81+
82+
The problem with this syntax is that there are millions of combinations
83+
and there is no existing data source that represents which ones are meaningful
84+
today and which ones are not.
85+
This means that the working group would need to define the behavior for these
86+
millions of combinations
87+
which would either dramatically slow the development of CSS overall
88+
or would lead to many combinations that are initially defined wrong,
89+
which would then make the feature detection not work when the combination
90+
is actually supported meaningfully.
91+
92+
## Accessibility, Internationalization, Privacy, and Security Considerations
93+
94+
While developers in general need to test feature detection code carefully
95+
to make sure that their testing covers all of the relevant branches,
96+
this doesn't pose any considerations that are specific to accessibility or internationalization
97+
other than generally increasing their testing matrix
98+
(because the testing matrices for accessibility and internationalization should probably
99+
combine with the matrices for feature detection, at least to some degree).
100+
101+
We're not aware of any privacy and security considerations
102+
since this feature detection is generally testing characteristics of the implementation
103+
which are already detectable by developers in other ways.
104+
105+
## Stakeholder Feedback / Opposition
106+
107+
- Chromium: Positive, see https://chromestatus.com/feature/5153932394102784
108+
- Gecko: Unknown
109+
- WebKit: Unknown
110+
111+

0 commit comments

Comments
 (0)