Re: [selectors] feedback

On Tue, Aug 18, 2015 at 6:33 PM, fantasai <> wrote:
> On 04/17/2014 01:41 AM, Anne van Kesteren wrote:
>> On Tue, Apr 15, 2014 at 11:27 PM, Tab Atkins Jr. <>
>> wrote:
>>> On Tue, Apr 15, 2014 at 3:53 AM, Anne van Kesteren <>
>>> wrote:
>>>> In syntax you are not calling it in API hook. If e.g. syntax uses this
>>>> algorithm (and I hope it can) it seems rather weird to name it an API
>>>> hook.
>>> True, I call them "Parser Entry Points" or "Parser Algorithms" in
>>> Syntax.  Are you just objecting to the naming of the section?
>> Not objecting, but yes.
> I think this section ("parse a selector") is obnoxious, and, as Simon Sapin
> points out, not really necessary. The whole structure of it reminds me of
> the C++/Java approach to "Hello, World": a lot of formulaic incantation
> when all you want to say is "print 'Hello, World';".

I don't understand what you think is "a lot of formulaic incantation".
In a spec, you say, "Parse a selector from foo. It it returns failure,
throw a SyntaxError. Otherwise...".  This is identical to what you
suggest people should write, below.

> We define what an invalid selector is already:
> All DOM needs to say is
>   "If the selector is _invalid_, throw a SyntaxError. Otherwise [...]."
> This is much more direct and easier to read imho, and not in any way
> more ambiguous.

No, because *you don't have a selector until it's parsed*. You have a
*string*.  You have to turn it into a selector, and to do that, you
have to specify how it's turned into one, which means specifying what
grammar to validate it against.  The "parse a selector" API entry
point does that for you, so you don't have to write any unnecessary
boilerplate in your spec.  (It also takes care of validating against
"things the UA supports" for you, which is *not* automatically done
when you parse against the generic selectors grammar.)


Received on Wednesday, 19 August 2015 21:19:02 UTC