Re: [csswg-drafts] [css-syntax-3][css-cascade][css-conditional] Missing definition of `<declaration>` (#13003)

  > Fixed by 140f4d1?

Its [definition](https://drafts.csswg.org/css-conditional-5/#typedef-declaration) does not match [this test from WPT](https://github.com/web-platform-tests/wpt/blob/a0922f6ecb98873239584c0e6b618c6384bc4736/css/css-cascade/parsing/supports-import-parsing.html#L62C3-L62C83), which all main browsers [pass](https://wpt.fyi/results/css/css-cascade/parsing/supports-import-parsing.html?label=stable&label=master&aligned) it in their stable version:

  > ```js
  > test_invalid_supports_import('@import url("nonexist.css") supports(foo: bar);');
  > ```

  > `<declaration>` here matches anything that would be successfully parsed by [consume a declaration](https://www.w3.org/TR/css-syntax-3/#consume-a-declaration), ignoring the context-validation check at the end of that algorithm.

However, CSS Cascade also requires:

  > If a `<declaration>` is given in place of a `<supports-condition>`, it must be interpreted as a `<supports-decl>` (i.e. the extra set of parentheses is implied) and treated as a `<supports-condition>`.

This appears in a [section](https://drafts.csswg.org/css-cascade-6/#import-conditions) defining how to evaluate import conditions, so *interpreted* can be understood as *evaluated* instead of *parsed and evaluated*.

If it is understood as *parsed and evaluated*, `<supports-condition>` would catch an invalid `<declaration>` because it produces `( <any-value>? )`.

But even if it is understood as *evaluated*, `@import` accepts `<media-query-list>` as its last value, which is parsed forgivingly, and should match an invalid `supports()`.

So this test is certainly incorrect.

Now, if the goal is to forgive any invalid input in `supports()`, I think this should be achieved generally and consistently, by parsing an unwrapped `support()` argument as if it was wrapped in parens, rather than by defining `<declaration>` with a relatively open value range, as well as some feature test functions, inconsistently:

  - `font-format()` and `font-tech()` accept a closed range of keywords
  - `at-rule()`, `env()`, `named-feature()`, accept an open range of `<ident>`
  - `<supports-condition-name>` accept an open range of `<dashed-ident>`

Except custom environment variables and custom condition names, the result from evaluating these features cannot change over time. If it is performed at parse time, and if features evaluating to false are made invalid, it can make the implementation to evaluate these features easier.

-- 
GitHub Notification of comment by cdoublev
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13003#issuecomment-4175281179 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 April 2026 07:35:15 UTC