W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2020

[csswg-drafts] Should CSS.supports() accept !important in the 2nd argument? (#5692)

From: Oriol Brufau via GitHub <sysbot+gh@w3.org>
Date: Tue, 03 Nov 2020 14:52:37 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-735386586-1604415153-sysbot+gh@w3.org>
Loirooriol has just created a new issue for https://github.com/w3c/csswg-drafts:

== Should CSS.supports() accept !important in the 2nd argument? ==
According to https://drafts.csswg.org/css-conditional-3/#the-css-namespace,

- `CSS.supports(conditionText)`
    > 1. If `conditionText`, parsed and evaluated as a `<supports-condition>`, would return `true`, return `true`.
    > 2. Otherwise, If `conditionText`, wrapped in parentheses and then parsed and evaluated as a `<supports-condition>`, would return `true`, return `true`.
    > 3. Otherwise, return `false`.

    Therefore, and according to #5559, we should have
    CSS.supports("background: green !important"); // true
    as all Chromium, WebKit and Firefox already do.

- `CSS.supports(property, value)`
    > 1. If `property` is an ASCII case-insensitive match for any defined CSS property that the UA supports, and `value` successfully parses according to that property’s grammar, return `true`.
    > 2. Otherwise, if `property` is a custom property name string, return `true`.
    > 3. Otherwise, return `false`.

   I don't think `!important` is part of the property’s grammar, so I would expect
    CSS.supports("background", "green !important"); // false
   However, accepting `!important` in the single argument case, but rejecting it in the 2 arguments one, can seem inconsistent.
   And we don't have interoperability here: Firefox and Chromium return `false`, but WebKit returns `true`.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5692 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 3 November 2020 14:52:39 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:22 UTC