- 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