Re: [selectors] feedback

On Tue, Apr 15, 2014 at 12:41 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Apr 10, 2014 at 7:18 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> * For "evaluating a selector" when would you want to provide an
>> explicit "selector match list" rather than a "selector match root"? It
>> seems the typical scenario would be to match against a tree of sorts.
>
> Evaluating a list of compound selectors against a particular set of
> elements, such as in <content select>.

Doesn't that also operate on the subtree of the element the shadow DOM
is attached to, making that element the root?


>> Providing all the elements as input seems rather odd.
>
> In what way?  All the elements are possible outputs.

My mental model of how this works when no fast paths are in place is
that I have a list of selectors and a root, and then iterate through
the tree and see if any of the selectors in the list match any of the
nodes in the tree. Providing an explicit reference to all elements in
the tree as input to this algorithm seems odd.


>> * You don't define the term "context".
>
> That's because I'm not sure how to define it.  :/  Any suggestions?

It might be better actually to leave it out and have everyone that
wants to do selector matching provide the root (or list of elements if
that's really better).


>> It's not entirely clear to me why
>> selectors does not directly operate on the DOM and we need this level
>> in between. In other contexts it seems people can define a mapping to
>> the DOM as needed.
>
> It does directly operate on the DOM, when the DOM is what's being
> matched against.
>
> For anything else, it seems like mapping to the DOM rather than
> mapping to CSS's simpler structure is just requiring more complexity
> than is really needed.

Except now you put the complexity (and bugs) on the dominant case.


>> Part of why this is problematic is that you do not
>> define your elements very well yet assume in other sections that terms
>> such as "sibling" make sense.
>
> How much definition needs to be given for a tree?  (Serious question;
> it seems like a generic computing term that we don't need to define,
> any more than we need to define "byte" in Syntax.)

Byte is defined by the Encoding Standard:
http://encoding.spec.whatwg.org/#byte Given that historically it has
meant different things, having a definition seems like a good thing.
DOM has an elaborate definition of what a tree is and what associated
concepts a tree has: http://dom.spec.whatwg.org/#trees

I think it is important that specifications define their things from
first principles. Dictionary knowledge can be assumed, but anything
above that ought to be clearly explained.


>> * "Default attribute values in DTDs" is this actually implemented
>> anywhere? I would prefer we make no requirements on this one way or
>> another. Seems like something we might want to simplify down the line.
>
> I think the section already makes no requirements.  All the normative
> stuff is a MAY.
>
> What do you mean by "simplify"?

Remove support for.


>> * Actually, the way classes and IDs are proposed to work is with a
>> generic class="" and id="" attribute defined by DOM. HTML, SVG,
>> MathML, xml:id, are all irrelevant.
>
> Has that been accepted?  I'm happy to edit Selectors if that's
> definitely happening.

It's awaiting implementations to make the shift. Certainly had large buy-in.


>> * :hover should mention that the specifics of hit testing are not
>> defined (but should be at some point). Suggesting it's as simple as a
>> box the mouse is hovering over is misleading.
>
> Added a note.

You might want s/should/will/ if you try to follow RFC 2119.


>> * Why is parsing a selector an API hook?
>
> It seems similar to the structure exposed by Syntax for its parsing algos?

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.


-- 
http://annevankesteren.nl/

Received on Tuesday, 15 April 2014 10:54:15 UTC