- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 06 Dec 2012 09:29:39 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Wed, 05 Dec 2012 18:28:02 +0100, Tab Atkins Jr. <jackalmage@gmail.com>
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
> (.
Yes, right. Still, my point stands. The two examples *look* like they do
the same thing. No?
--
Simon Pieters
Opera Software
Received on Thursday, 6 December 2012 08:30:16 UTC