Re: [selectors] feedback

On Tue, Apr 22, 2014 at 3:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Fri, Apr 18, 2014 at 8:09 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Thu, Apr 17, 2014 at 1:41 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> This does not seem clear to me with respect to the above remark. You'd
>>> have to interpret "arbitrary additional information" which is not a
>>> defined term, in creative ways.
>>
>> It's defined as *arbitrary additional information*.  Plain english
>> words.  Anything additional your tree structure might have.  Because
>> it's arbitrary, that includes things like more types of nodes, etc.
>
> If you define it as an element tree one might think you are actually
> dealing with an element tree rather than a node tree. E.g. in
>
> A
> - B
> - #text
> - C
>
> given that A, B, C, are elements and #text is a node, are B and C
> siblings? Are they siblings when doing selector matching? From what
> text does this follow?

You are dealing with an element-tree.  The presence of a text node is
"arbitrary additional information", while the sibling combinator
operates on the list of children the element is in.

Yes, the sibling combinator doesn't currently state that - I'm holding
off on doing a more complete rewrite of the tree-related language in
the spec until we resolve our conversation.  (Though if you think it
could help, I could go ahead and do the rewrite - I can always revert
the commit, so it's just some wasted time.)  I plan to rewrite the
combinator definitions into the same form as the /deep/ combinator:
<http://dev.w3.org/csswg/css-scoping/#deep-combinator>.

>> Another reason I'm somewhat against switching to basing it on DOM is
>> that the tree model used by Selectors is *wider* than DOM.  It
>> contains pseudo-elements, for instance, which don't exist in DOM.  So
>> even if I switched over, I'd still be working off a somewhat abstract
>> tree with more information in it.
>
> No, pseudo-elements operate on the node you matched against. They are
> a good reason for making things clearer. E.g. if you have html::before
> you first match until you find html and then there is some kind of
> check for its associated before structure, if any.

[Private discussion with Anne in #whatwg resulted in the two of us
agreeing that it should be okay to use the DOM, but augment it with
pseudo-elements for the purpose of Selectors.]

> We should probably
> also have some kind of flag as to whether pseudo-elements being
> present should count as a match or not, for the DOM (or an expectation
> setting of the results).

This already exists in the "match a selector" algo - one of the
possible arguments is what pseudo-elements you want to allow the algo
to return (defaulting to "all").

~TJ

Received on Tuesday, 22 April 2014 16:17:29 UTC