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

Re: Selector Parsing for Selectors API

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 30 Oct 2012 16:50:09 +0100
Message-ID: <CAAWBYDCZLQEa=euuFV2WdJHVyBUGYY1iU_ZyLtO2dW74vL3ufw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style@w3.org
On Tue, Oct 30, 2012 at 3:31 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/30/12 6:42 AM, Lachlan Hunt wrote:
>>
>> I would like for Selectors 4 to more clearly address these issues by
>> defining parsing in a better way.
>
> That sounds great, as long as it's done by reference to CSS parsing (e.g. by
> saying that at the end of the selector string end-of-stylesheet rules
> apply).  Just please don't go write a separate, incompatible, selector
> parsing spec.  ;)

Yes.  Selectors should reference the CSS *tokenization* algorithm
normatively.  It has no need for special tokenizing rules.

(This happens to also handle unclosed comments automatically - they
auto-close at EOF.)

As for the actual parser, Syntax is minimal in what is restricted from
being in a selector - it can contain literally anything except a { or
} token.  As long as we make sure that these are appropriately handled
as an error by a Selectors parsing spec, then Selectors can do pretty
much whatever it wants with its own parser.

If possible, yeah, me defining a reusable "close every block" thing in
Syntax for reuse in Selectors would be great.  It's trivial enough
that I wouldn't be sad about just copying it over and tweaking as
necessary, but keeping it compatible is obviously the right answer.


>> In particular, defining when an
>> implementation should and should not throw a syntax error for those
>> cases discussed in the thread.
>
> My personal vote would be to not throw on anything handled by existing CSS
> error recovery rules (which happens to be the behavior of every UA that
> implements said rules right now).

Agreed.

~TJ
Received on Tuesday, 30 October 2012 15:51:00 GMT

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