Skip to content

[css-conditional] Better <supports-condition> syntax #13012

@cdoublev

Description

@cdoublev

The main motivations are to accept all support features in supports() and prevent (almost) any invalid argument from making its context invalid (if(), @when, @import).

@supports prelude is defined with <supports-condition>, therefore it accepts (almost) any value wrapped in parens. supports() takes <supports-condition> but also other values that can make it invalid, like supports(garbage).

The current (simplified) syntax is:

<supports-in-parens> = (<supports-condition>) | <supports-feature> | <general-enclosed>
<supports-feature> = (<declaration> | <extension-name>)
                   | at-rule(<at-keyword-token>)
                   | font-format(<font-format>)
                   | font-tech(<font-tech>)
                   | selector(<complex-selector>)
<supports()> = supports(<supports-condition> | <declaration>)

The suggested syntax:

<supports-in-parens> = (<supports-condition> | <supports-feature>)
                   | at-rule(<at-keyword-token>)
                   | font-format(<font-format>)
                   | font-tech(<font-tech>)
                   | selector(<complex-selector>)
<supports-feature> = <declaration>
                   | <extension-name>
                   | at-rule(<at-keyword-token>)
                   | font-format(<font-format>)
                   | font-tech(<font-tech>)
                   | selector(<complex-selector>)
                   | <any-value>
<supports()> = supports(<supports-condition> | <supports-feature>)

Related: #12903.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions