W3C home > Mailing lists > Public > www-style@w3.org > February 2013

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

From: L. David Baron <dbaron@dbaron.org>
Date: Thu, 7 Feb 2013 13:55:27 -0800
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Simon Pieters <simonp@opera.com>, www-style@w3.org, Simon Sapin <simon.sapin@kozea.fr>
Message-ID: <20130207215527.GA12827@crum.dbaron.org>
On Wednesday 2012-12-19 12:11 -0500, L. David Baron wrote:
> 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.

To follow up here, this is what the working group agreed to do in:
http://lists.w3.org/Archives/Public/www-style/2012Dec/0330.html and
the change was made in https://dvcs.w3.org/hg/csswg/rev/34b185ae3bac .

Actually making the change required switching away from the
traditional grammar principle that all productions allow trailing
whitespace at their end, and thus basically involved restructuring
all the whitespace parts of the grammar.  Despite that, I think it
was relatively straightforward, although it wouldn't be a bad idea
if somebody else checks it.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Thursday, 7 February 2013 21:56:09 GMT

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