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 18:50:52 +0100
Message-ID: <CAAWBYDD1rGrxoF2Z0WHMcokmfjDdjNdDMVOJWXfjqUpFmu2daw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: www-style@w3.org
On Tue, Oct 30, 2012 at 5:20 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 10/30/12 11:50 AM, Tab Atkins Jr. wrote:
>> 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.
>
> No, it can't, imo.  For example, it shouldn't define different parsing
> behavior from actual CSS selector parsing given the same token stream for
> the cases when the string is a valid selector.  In my opinion.

Sorry, you're reading more into my statement than I meant.

The Syntax spec, as currently defined, says *nothing* about parsing
selectors, except that selectors are a sequence of any token besides {
and }.  The parser generates style rules and sets their selector
property to the given stream of tokens, but leaves the actual parsing
of the selector's tokens into something meaningful to the Selectors
spec.

I assumed as a given that the Selector spec's rules for parsing a
token stream into a meaningful selector would be compatible with
current CSS.  Both CSS and Selectors API will just use the Selectors
parsing definitions.

~TJ
Received on Tuesday, 30 October 2012 17:51:43 GMT

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