[css-conditional] Should CSS.supports() accept !important in the 2nd argument?

[Loirooriol]

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 [css-conditional-3] Are there issues with !important in @supports? (Is the grammar wrong?) #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.

[SelenIT]

I'm not sure that these cases should necessarily be consistent in regard to the !important flag. Since the difference between two cases essentially boils down to the difference between CSS declaration and CSS value, and, per [css-syntax-3], only parsing the CSS declaration has an extra step of removing the !important part from the parsed value (step 5), I'd consider different results of adding !important in these two cases quite expected.

Also basing on the CSS Syntax logic, I believe that the behavior of Firefox and Chromium is correct, and WebKit has a bug.

[Que-tin]

I personally think it should be as it is in Firefox / Chromium. Meaning:

CSS.supports("background: green !important"); // true
CSS.supports("background", "green !important"); // false

It's similar to function overloading. As the arguments are different.

At CSS.supports(conditionText) the !important is seen as part of the condition and the whole term is evaluated as one.

At CSS.supports(property, value) the !important has no real affiliation to neither of the two arguements. As in this case the two arguments are parsed separately and the value parses according to that property’s grammar.

• 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.
• Otherwise, if property is a custom property name string, return true.
• Otherwise, return false.

[Loirooriol]

Thinking more about this, basically CSS.supports(property, value) is useful if it tells you whether element.style.setProperty(property, value) will work. And setProperty doesn't allow mixing the value and the priority, you need a third argument for that.

So CSS.supports("background", "green !important") should be false because these don't work:

element.style.background = "green !important";
element.style.setProperty("background", "green !important");

[Que-tin]

@Loirooriol so you don't have anymore questions or concerns regarding the current implementation right?

If so I guess this issue / discussion can be closed.

[Loirooriol]

Closing is fine for me. But in #5559 (comment) @fantasai told me to file the issue because she thought the spec may not be particularly clear. So she may want some clarification.

[svgeesus]

@fantasai could you clarify?

[fantasai]

Added a note. @Loirooriol if this looks good to you, would you close out the issue?