- From: Alex Danilo <alex@abbra.com>
- Date: Wed, 10 Aug 2011 17:18:30 +1000
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-style@w3.org, Vitor Menezes <vmenezes@mozilla.com>
Hi David, --Original Message--: >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)) The nesting of brackets is sensible to an arbitrary depth. >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. If the property value can contain shorthand, then this may be a path to parsing pain. Perhaps it's more sensible to keep the brackets and if there's a good later need/agreement it's easy to remove that restriction. Cheers, Alex >Does this seem reasonable? If so, I'll attempt to restructure the >grammar along these lines. > >-David > >-- >𝄞 L. David Baron http://dbaron.org/ 𝄂 >𝄢 Mozilla Corporation http://www.mozilla.com/ >
Received on Wednesday, 10 August 2011 07:19:46 UTC