W3C home > Mailing lists > Public > www-style@w3.org > December 2012

Re: [css3-conditional] @supports "not(" without space

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 06 Dec 2012 17:18:29 -0800
Message-ID: <50C143E5.6070705@inkedblade.net>
To: www-style@w3.org
On 12/06/2012 12:29 AM, Simon Pieters wrote:
> 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?

I guess we can say there's an issue here on whether to make
"not(", "or(", "and(" be equivalent to "not (", "or (", "and ("
for usability reasons.

~fantasai
Received on Friday, 7 December 2012 01:18:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT