[css-syntax-3] At-rules and qualified rules allow simple blocks in prelude

[SebastianZ]

The Parsing section within the CSS Syntax 3 module defines that the prelude of at-rules and qualified rules contains a list of component values. And component values may contain a simple block.

That allows at-rules like @name {} {} and qualified rules like {} {}, causing ambiguities, as the {}-block might either belong to the component value of the current rule or be part of the next rule.

Therefore, an {}-block should not be allowed in the prelude of the rules.

Sebastian

[tabatkins]

Yeah, that won't happen when the rule is parsed (the first {} will end up being the body), but if you manipulate such a rule via the OM you can produce a rule that can't be serialized back out.

So I support explicitly disallowing those.

(We could theoretically still allow {} in the prelude of a body-less at-rule like @import, but that would prevent extension to a body-full rule later, and would just be a confusing sort of thing to allow.)

[matthew-dean]

In addition, the CSS spec seems to define blocks (including curly blocks) very generically, and AFAIK doesn't explicitly disallow the possibility that a CSS property won't be added in the future that also can contain a curly value, like:

.box {
  new-prop: value1 value2 {value3};
}

This possibility, of course, would be devastating to CSS parsers with nested syntax if such a value could ever be assigned to a (non-custom) property. Not that that has to be a CSSWG concern, necessarily, but when I discovered that in CSS grammar I was like 😬 😬 😬

Also:

(We could theoretically still allow {} in the prelude of a body-less at-rule like @import, but that would prevent extension to a body-full rule later, and would just be a confusing sort of thing to allow.)

This also would potentially be very bad for parsers outside of the browser, so I hope that doesn't come to pass either. So that is just to say, I think it would help if curly-brace blocks in CSS were defined less generically (than, say, square brackets or parentheses) in terms of where they will and won't appear.

[tabatkins]

Curly braces in property values has, in fact, been proposed before as a way to more explicitly address the sub-parts of longhand properties, like

.foo {
  background: {image: url(...); color: red;};
}

It doesn't have the syntactic issues of curly-blocks in preludes, so what would make it "devastating to CSS parsers with nested syntax", @matthew-dean?