- From: Alan Gresley <alan@css-class.com>
- Date: Wed, 10 Aug 2011 12:23:21 +1000
- To: "L. David Baron" <dbaron@dbaron.org>
- CC: www-style@w3.org, Vitor Menezes <vmenezes@mozilla.com>
On 10/08/2011 10:28 AM, L. David Baron wrote: > I asked Vitor Menezes, an intern this summer at Mozilla, to work on > implementing @supports (as @-moz-supports). He pointed out the > following problem with the grammar: The grammar currently *attempts* > to avoid allowing nesting extra sets of parentheses, e.g., to allow > @supports (display:block) and (display:inline) > but disallow: > @supports (display:block) and ((display:inline)) > but it fails to do that in one case, which is that it allows double > (but not more) parentheses around the argument to "not". > > On reflection, I think forbidding doubling of parentheses is a bad > idea because it makes it harder for people to test things by > commenting them out. In other words, since an author may want to > experiment with: > @supports not ((display:block) and (display:inline)) > by changing it to: > @supports not ((display:block) /*and (display:inline)*/) > it should be legal to write: > @supports not ((display:block)) I never liked this form of nesting. It does not occur in CSS3 mediaqueries nor any other syntax that has statements with blocks. I believe that several arguments appearing between blocks are better separated by commas or keywords, like shown below for the ease of commenting parts out but more so to hunt down parsing errors. @supports not (display:block and display:inline) @supports not (display:block , display:inline) Commented: @supports not (display:block /*and display:inline*/) @supports not (display:block /*, display:inline*/) > Now, the one other thing I'm reconsidering is my idea of forbidding > the declaration not being in parentheses. In other words, my > current grammar attempts to allow these: > @supports (display:block) {} > @supports (display:block) and (display:inline) {} > @supports not (display:block) {} > but it disallows: > @supports display:block {} > I'm inclined to remove that restriction as well and allow the last > of the above as well. > > Does this seem reasonable? If so, I'll attempt to restructure the > grammar along these lines. > > -David I support this also but does this limit such syntax structure in future to at-rules type statements? -- Alan Gresley http://css-3d.org/ http://css-class.com/
Received on Wednesday, 10 August 2011 02:23:40 UTC