[css-conditional-5] Feature detection for descriptors

Currently, @supports and CSS.supports only support property: value pairs. The only way for web developers to detect support for a certain descriptor in an at-rule is to use JavaScript. For example:

let e = document.createElement("style");
e.textContent = "@font-face { font-display: swap; }";
document.documentElement.appendChild(e);
let isFontDisplaySupported = e.sheet.cssRules[0].cssText.indexOf("font-display") != -1;

(from https://bugzilla.mozilla.org/show_bug.cgi?id=1296373#c6)

It would be good if CSS can test whether a user agent supports a descriptor: value pair.

See also a related issue in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=600137

Tagged as "unknown/future spec" for now, because I'm not sure if we should extend @supports (which is in css-conditional), or develop a new mechanism for it.

I agree that being able to detect descriptor support is valuable. I would have thought it belongs in CSS Conditional.

Yeah, it's Conditional - this is precisely why we took care to include arbitrary functional terms in the @supports grammar which resolve to unknown, so we can add more types of support-testing in the future.

(Need to also be able to test for types, like if "1foo" is a <length>, etc.)

Something like @supports descriptor(@media, font-display: block) { ... }.

@tabatkins

@tabatkins Did you mean to write:

@supports descriptor(@font-face, font-display: block) { ... }

(Need to also be able to test for types, like if "1foo" is a , etc.)

Maybe. We have a clear syntax extension path if we want to, but why do we need to test if 1foo is supported independently of testing if bar: 1foo is supported?

Did you mean to write:

Yes, I did mean that.

Maybe. We have a clear syntax extension path if we want to, but why do we need to test if 1foo is supported independently of testing if bar: 1foo is supported?

Yeah, one could do that, but given that UAs will have explicit parsers for each value type for Typed OM purposes, we'll be able to expose that directly, if it makes one's intent clearer.

Sure, but when you want to use a value, you're going to use it somewhere. And it is possible that the UA supports that value without supporting it where you planned to use it.

For instance, a newer version of a property may accept % and length while the old one only took %. The browser you're in does not yet support the length version yet, but does support the new fancy length unit you want to use in places where it does support length.

In that sense, while @supports unit(1ch) would something that is technically true, it seems a bit of a footgun: @supports unit(1ch) { prop-that-used-to-take-percent-only: 1ch; }

The unit(…) function could only be exposed from within CSS.supports(…) but not from @supports, that would solve the footgun issue while allowing developers to test for unit support from JavaScript, also the unit(…) function is off‑topic and should be discussed in a separate issue.

It'd be nice to have this for @property so we could feature detect the support from CSS directly with something like:

  @supports descriptor(@property, syntax: "<color>") { ... }

It'd be nice to have this for @property so we could feature detect the support from CSS directly with something like:
  @supports descriptor(@property, syntax: "<color>") { ... }

Yeah, @property urgently needs this feature, Chrome is ready to ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/3ygpsew53a0

@andruud

Especially in [css-properties-values-api] currently implemented by Chrome, syntax: '<image>' is not yet supported, which makes it difficult to detect it. cc @andruud

Bug 1928335 [wpt PR 48907] - Implement at-rule for use with @supports.…

@yisibl

@yisibl

@stoyan

Safari supports size-adjust but none of the others.

It is now supported by all major browsers. See https://web.dev/articles/css-size-adjust

Safari 16 is still quite big, as it’s the last version to support iPhone 8 (last iPhone model before Face ID; excluding iPhone SE 3) and iPhone X.

@stoyan

@stoyan

Safari supports size-adjust but none of the others.

It is now supported by all major browsers. See https://web.dev/articles/css-size-adjust

@yisibl My point exactly. I only want a @font-face block if the browser supports size-adjust and ascent-override. Supporting size-adjust but not ascent-override makes things worse than not supporting size-adjust at all

Bug 1928335 [wpt PR 48907] - Implement at-rule for use with @supports.…

Microsoft's new proposal:

@supports at-rule(@property; syntax: "<color>") {
    /* declare custom properties with color syntax */
}

See https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AtRuleFeatureDetection/explainer.md#detect-whether-a-given-declaration-is-supported-within-an-at-rule-block

See also the suggestion in #12622 which could do the same detection with something like this:

@supports-condition --color-property {
	@property --foo {
		syntax: "<color>";
		inherits: false;
		initial-value: black;
	}
}
@supports --color-property {
	/* declare custom properties with color syntax */
}

It's definitely more verbose as afaik you'd need to provide a complete valid @property rule instead of just the descriptor on its own. Then again, some descriptors' requirements depend on what other descriptors are specified.

Bug 1928335 [wpt PR 48907] - Implement at-rule for use with @supports.…

[css-conditional-5] Spec at-rule() per CSSWG resolutions. w3c#2463, w…

[css-conditional-5] Spec at-rule() per CSSWG resolutions. #2463, #6966,

fix: evaluate supported at-rules in feature queries

Navigation Menu

Repository navigation

[css-conditional-5] Feature detection for descriptors #2463

36 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-conditional-5] Feature detection for descriptors #2463

Description

Activity

svgeesus commented on Mar 22, 2018

tabatkins commented on Mar 22, 2018

tabatkins commented on Mar 22, 2018

frivoal commented on Mar 23, 2018

frivoal commented on Mar 23, 2018

tabatkins commented on Mar 23, 2018

frivoal commented on Mar 23, 2018

ExE-Boss commented on Oct 17, 2018

mrego commented on Apr 24, 2020

yisibl commented on Apr 24, 2020

yisibl commented on Apr 24, 2020

36 remaining items

ExE-Boss commented on Nov 5, 2024

stoyan commented on Nov 5, 2024

yisibl commented on Sep 10, 2025

AtkinsSJ commented on Sep 10, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions