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

Re: [css-syntax][selectors] Added a COLUMN token to Syntax

From: Simon Sapin <simon.sapin@exyr.org>
Date: Fri, 05 Apr 2013 09:24:31 +0200
Message-ID: <515E7C2F.4040303@exyr.org>
To: "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Le 05/04/2013 05:55, Kang-Hao (Kenny) Lu a écrit :
> (13/04/04 18:13), Simon Sapin wrote:
>> Le 04/04/2013 02:06, Tab Atkins Jr. a écrit :
>>> I just added a COLUMN token to the Syntax draft, matching "||".  It's
>>> needed for Selectors, so it can maintain LL(1).  (Otherwise, seeing
>>> "*" followed by "|" is ambiguous until you look at the*next*  token.)
>> Hi,
>> I’m not objecting, but shouldn’t LL(1) be only an implementation
>> concern? AFAICT, it is not detectable whether an implementation parses
>> "||" as a single token, or looks ahead for two delim tokens.
> x |/**/| y ?

Ah, yes of course.

> I agree that maintaining LL(1) isn't too important but I don't see much
> harm in introducing a new token either.

I don’t see much harm either, but the underlying point is about similar 
differences that wouldn’t be detectable. For example, what if my parser 
has separate INTEGER and NUMBER tokens rather than having a type flag on 
NUMBER tokens? What if it represents percentages as DIMENSION tokens 
with '%' for the unit, rather than as a separate token?

As long as tokens/component values are not exposed to the platform, 
these are only an implementation details. I do believe that exposing 
them eventually (maybe only on variables) is the way to go to enable CSS 
polyfills, but that would effectively freeze the tokenizer.

(This is also a concern for me, as author of a parsing library where CSS 
tokens are part of the public API.)

Simon Sapin
Received on Friday, 5 April 2013 07:25:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:28 UTC