Re: [selectors] feedback

On Tue, Apr 15, 2014 at 3:53 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 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?

Oh shoot, you're right, it does now.  Hmm, maybe there's not much
reason to phrase it this way, then.

>>> * 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).

Yeah, I suppose you're right.

>>> 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.

You keep asserting that there's complexity or bugs, but I'm having
trouble seeing it.  Can you elaborate?

The paragraph transforming the DOM to an element tree is just:

# In a DOM document,
# the DOM is used as the <a>element tree</a>.
# Each DOM element is an element in the <a>element tree</a>,
# with the DOM element's namespace and local name as the type,
# and its ID, class list, attributes, and child elements
# as the ID, classes, attributes, and child elements in the <a>element tree</a>.
# The rest of the information in the DOM is also accessible
# as the arbitrary additional information in the <a>element tree</a>.

That's as close to an identity transform as I can get.

>>> 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.

I've explicitly said that the element tree has the structure defined
in DOM.  Does that suffice?

>>> * "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.

I think it's probably good to mention that default values may or may
not be matchable by Selectors.

Do you think there's a problem with the current spec text, after I've
pointed out that the normative reqs are guarded by a MAY?

>>> * 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.

Cool, I'll shift the language as soon as people start implementing. ^_^

>>> * :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.

Whoops, good catch.  My reflexes occasionally miss a 2119 violation in notes. :/

>>> * 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.

True, I call them "Parser Entry Points" or "Parser Algorithms" in
Syntax.  Are you just objecting to the naming of the section?

~TJ

Received on Tuesday, 15 April 2014 22:28:09 UTC