Recipes For Detecting Support For CSS At-Rules

The @supports at-rule has been expanded several times since its initial release. Previously it could only check support for property/value pairs, now it can check for a selector using selector() Wrapper function and various font formats and technologies font-format() And font-tech()respectively. However, one feature the community still craves is testing other at-rules support.

@supports at-rule(@new-rule) {
  /* @new-rule is supported */
}

The The CSSWG made its decision in 2022 to add the prior at-rule() Wrapper function. While this is welcome and wonderful news, we are now two years later and don’t have many updates on when it will be added to browsers. So how can we seek support in the meantime?

Funny coincidence: just yesterday The Chrome team has changed the status from new to assigned. as if she knew I’ve thought about it.

While looking for an answer, I found it this post by Bramus This provides a workaround: although we cannot search for a CSS at rule in @supports at-rule we can instead test a property that was shipped with a specific at-rule, assuming that if a corresponding feature was released we would do so may test and it is supported, then the feature we can’t test is probably also supported… and vice versa. Bramus provides an example that verifies support for animation-timeline property to check whether the @scroll-timeline at-rule (which has been discontinued) is supported because both were shipped together.

@supports (animation-timeline: works) {
  /* @scroll-timeline is supported*/
}

/* Note: @scroll-timeline doesn't exist anymore */

Bramus calls these “telltale” properties, which is a fun way to think about it, as it is similar to a deduction puzzle where we have to find a related property to check whether their rule is supported.

I wanted to see how many of these puzzles I could solve, and in the process know which at-rules we can reliably test today. So I have identified a complete list of supportable at rules that I could find.

I’ve excluded at rules that don’t have browser support, for example @color-profile, @whenAnd @elseas well as outdated at rules, such as @document. I also exclude older at-rules that have enjoyed broad browser support for years – such as @page, @import, @media, @font-face, @namespace And @keyframes – as these are more obvious.

@container Size queries (Basic support)

Testing support for size queries is fairly trivial, as the module in particular introduces several telltale properties container-type, container-name And container. Choose your favorite because everyone should rate the same. And if this property is supported, then @container should also be supported since it was introduced at the same time.

@supports (container-type: size) {
  /* Size queries are supported! */
}

You can combine both by nesting a @supports Query within a @container and vice versa.

@supports (container-type: size) {
  @container (width > 800px) {
    /* Styles */
  }
}

@container style queries (partial support)

Size queries give us many tell-tale properties to work with, but the same cannot be said for style queries. Because every element has a style by default, there is no specific property or value for that element. We can get around this by forgetting it @supports and write the styles into a style query instead. Style queries work in supporting browsers, but are otherwise ignored. Therefore, we can write some basic styles for older browsers that are overridden by modern browsers.

.container {
  --supports-style-queries: true;
}

.container .child {
  /* Base styles */
}

@container style(--supports-style-queries: true) {
  /* Container queries are supported! */
  .child {
    /* We can override the base styles here */
  }
}

@counter-style (partial support)

The @counter-style at-rule allows us to do this Create custom counters for lists. The styles are defined in a @counter-style with individual name.

@counter-style triangle {
  system: cyclic;
  symbols: ‣;
  suffix: " ";
}

ul {
  list-style: triangle;
}

We don’t have one telltale trait that helps us solve this puzzle; Value. The list-style-type The property used to accept some predefined keyword values, but has since supported additional values @counter-style was introduced. That means we should be able to check if the browser supports it Values ​​for list-style-type.

@supports (list-style: custom-ident) {
  /* @counter-style is supported! */
}

@font-feature-values (Basic support)

Some fonts contain alternative glyphs in the font file that can be customized using @font-feature-values usually. These custom glyphs can be displayed with font-variant-alternatesl, so this is our telltale property for checking support in this case:

@supports (font-variant-alternates: swash(custom-ident)) {
  /* @font-feature-values is supported! */
}

@font-palette-values (Basic support)

The same concept can be applied to the @font-palette-values at-rule, which allows us to make changes multicolored fonts with the font-palette Trait that we can use as a telltale trait.

@supports (font-palette: normal) {
  /* @font-palette-values is supported! */
}

@position-try (partial support)

The @position-try at-rule is used to create custom anchor fallback positions Anchor positioning. It’s probably the rule in this list that needs more support since it’s such a new feature. Luckily, there are plenty of telltale characteristics in the same module that we can grab hold of. However, be careful because Some properties have been renamed since its introduction. I recommend testing support for @position-try use anchor-name or position-try as telltale characteristics.

@supports (position-try: flip-block) {
  /* @position-try is supported! */
}

@scope (partial support)

The @scope at-rule seems difficult to test at first, but it turns out that the same strategy we used with style queries can be applied. Create a base style for browsers that don’t support it @scope and then overwrite these styles in a @scope Block valid only in supporting browsers. A progressive improvement strategy if ever there was one!

.foo .element {
  /* Base style */
}

@scope (.foo) to (.bar) {
  :scope .element {
    /* @scope is supported, override base style */
  }
}

@view-transition (partial support)

The last at-rule in this list is @view-transition. It’s another feature that’s quickly making its way into browser implementations but isn’t being considered yet Basic support.

The easiest way would be to use the appropriate one view-transition-name Property close together since their release:

@supports (view-transition-name: custom-ident) {
  /* @view-transition is supported! */
}

But we might as well use this selector() Function to check whether one of its many pseudo-elements is supported:

@supports selector(::view-transition-group(transition-name)) {
  /* @view-transition is supported! */
}

A small resource

I have included this list in a demo that is being used @supports to design different at rules based on the test recipes we covered:

The Unsolved

While I feel like I’ve put together a solid list, there are three at-rules that I haven’t been able to test: @layer, @propertyAnd @starting-style.

Luckily, each of them is fairly well supported in modern browsers. But that doesn’t mean that we shouldn’t Test for support. I guess we can text @layer Support similar to approaches to testing support for style() Inquiries with @container We establish a base style and use progressive enhancements where support exists.

The other two? I have no idea. But please let me know how you are looking for support @property And @starting-style – or how to check support for a different feature than the one I have here. This is a tricky puzzle!