W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [selectors] feedback

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 22 Apr 2014 09:16:38 -0700
Message-ID: <CAAWBYDBHP82S1u4H_WmJESbHsuoYK4YC_1n_bO=RrVtNgOFgpA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "www-style@w3.org" <www-style@w3.org>
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:

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

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC