Support <general-enclosed> in @supports

Added by @nex3

• Proposal
• Specs
• Dart Sass
• LibSass

---

Hi @nex3 and friends! I’ve noticed that there are a few gaps between CSS’s specified syntax and what dart-sass will parse, one area in particular is parsing @supports conditions. The following examples should all be valid in CSS syntax but each generate parsing errors in dart-sass:

@supports (a b) {}
@supports c(d) {}
@supports (e(f)) {}

The syntax for @supports conditions in CSS is defined here: https://drafts.csswg.org/css-conditional-3/#typedef-supports-condition

<supports-condition> = not <supports-in-parens>
                     | <supports-in-parens> [ and <supports-in-parens> ]*
                     | <supports-in-parens> [ or <supports-in-parens> ]*
<supports-in-parens> = ( <supports-condition> ) | <supports-feature> | <general-enclosed>
<supports-feature> = <supports-decl>
<supports-decl> = ( <declaration> )

One thing that seems missing is that the CSS syntax allows <general-enclosed> productions, which are very open-ended in what they can contain.

<general-enclosed> = [ <function-token> <any-value> ) ] | ( <ident> <any-value> )

It looks like this might be the section of the dart-sass parser where these conditions are read, but I’m not sure right now how to fix this or improve the code that’s there.

When tokenized as CSS, @supports c(d) {} should look like this:

{
  "type": "AT-RULE",
  "value": {
    "type": "BLOCK",
    "value": [],
    "name": "{"
  },
  "name": "supports",
  "prelude": [
    {
      "token": "WHITESPACE"
    },
    {
      "type": "FUNCTION",
      "value": [
        {
          "token": "IDENT",
          "value": "d"
        }
      ],
      "name": "c"
    },
    {
      "token": "WHITESPACE"
    }
  ]
}

You can use this tool to check what different browsers will parse out of a string of CSS input. Or run this code to parse and re-stringify a string of CSS in any browser to see the same kind of result:

import('https://unpkg.com/cssomtools').then(({parse, stringify}) =>
  console.log(
    stringify(
      parse`
         @supports c(d) {}
      `
    )
  )
)

It looks like Safari struggles with @supports conditions that aren’t inside () parens, but Chrome and Firefox both seem to follow the spec a little more closely:

Safari

Firefox

It would be great if dart-sass could parse CSS more accurately in this area, please let me know if there’s any way I can be of further help in identifying or testing this.

Thanks ❤️

[nex3]

Marking this as accepted now.

[nex3]

I’m not making any claims about authorial intent, just the text of the specification, which is unambiguous. Regardless, this is all irrelevant to Sass since we plan on adding support for <general-enclosed> whether or not your use case is valid CSS, so I would like to stop discussing it.