- From: L. David Baron <dbaron@dbaron.org>
- Date: Wed, 19 Dec 2012 12:11:13 -0500
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Simon Pieters <simonp@opera.com>, "www-style@w3.org" <www-style@w3.org>
On Wednesday 2012-12-05 09:28 -0800, Tab Atkins Jr. wrote:
> On Wed, Dec 5, 2012 at 6:20 AM, Simon Pieters <simonp@opera.com> wrote:
> > Hi,
> >
> > Are these two supposed to be equivalent?
> >
> > @supports (not (foo: bar)) { }
> > @supports (not(foo: bar)) { }
> >
> > heycam says[1] that not( is tokenized into a FUNCTION and thus
> > general_enclosed will match instead of supports_negation.
> >
> > supports_negation's grammar has S* rather than S (I think it was S in an
> > earlier version?), suggesting that one should be able to omit the space.
> >
> > To me, this smells like a spec bug. If the space is supposed to be optional,
> > it should parse into supports_negation when the space is absent. If not, the
> > grammar for supports_negation should say S instead of S*.
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=816045#c10
>
> The space *is* technically optional. heycam is right that "not("
> always parses into a FUNCTION token, but "not/**/(" parses into IDENT
> (.
Another alternative here, by the way, is to make the spaces after
'not' and on both sides of 'and' and 'or' be mandatory. This is
roughly what we did with calc(). It's more internally consistent,
though not all that popular.
-David
--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla http://www.mozilla.org/ 𝄂
Received on Wednesday, 19 December 2012 17:11:57 UTC