Re: Selector Parsing for Selectors API

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 UTC