[css-conditional] Unbalanced brackets in @supports condition

[upsuper]

Gecko and Edge seem to reject (return false for CSS.supports) a condition if there is any unbalanced bracket, while Blink seems to accept it.

e.g. There are two conditions in Gecko's test suite:

• not ({ something @with (unbalanced brackets })
• (color: green) or an-extension(that is [unbalanced)

Gecko and Edge return false for both, while Blink returns true for both.

The spec doesn't seem to have anything about this. The question is, should it allow or disallow unbalanced brackets? Either way, it should probably be stated explicitly in the spec.

[SimonSapin]

general_enclosed links to any in CSS 2.1, which does require balancing. (Though EOF with unclosed blocks is OK.) So I think Blink is incorrect here.

By the way, maybe it should use the more general value instead of any.

If CSS Conditional syntax were to be re-expressed in terms of CSS Syntax 3 instead of the old CSS 2.1 grammar, it should probably use <any-value> from CSS Values. (It corresponds to (value | unused)* in 2.1 terms.)

[tabatkins]

Using Syntax 3 (and invoking the "parse as CSS" entry point) will auto-close any blocks. Using <any-value> (which I agree is correct there), however, will cause both of the OP's examples to be invalid, because of the unmatched } and ) tokens.

[tabatkins]

In other words, not ({ something @with (unbalanced brackets }) will parse into the equivalent of not ({ something @with (unbalanced brackets })}), with the first } being unmatched, while (color: green) or an-extension(that is [unbalanced) will parse into the equivalent of (color: green) or an-extension(that is [unbalanced)]), with the first ) after unbalanced being unamtched.

[svgeesus]

The spec already seems to reference Syntax 3. The only reference to CSS 2.1 is the definition of width.

general_enclosed links to any in CSS 2.1, which does require balancing.

It did in the 2013 CR but in the current draft <general-enclosed> links to MQ5 which does indeed use <any-value

So I think this issue is overtaken by events and can be closed.

[svgeesus]

@upsuper do you agree?

[upsuper]

While I don't understand what do you mean by

this issue is overtaken by events and can be closed.

As far as we are going to require it to be balanced I'm happy with it. Maybe it would be good to have a wpt and file a bug to those browsers after we close this.

[tabatkins]

Yeah, the specs now normatively reference Syntax 3 properly, so everything's well defined. Missing closing brackets will be auto-closed by the CSS parser (and thus are perfectly fine), but unbalanced brackets are invalid per the <any-value> production.

So (color: green) or an-extension(that is [unclosed is valid, (color: green) or an-extension(that is [unbalanced) is invalid.