- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Fri, 05 Apr 2013 09:24:31 +0200
- 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