Re: [selectors] feedback

On 04/22/2014 03:28 AM, Anne van Kesteren 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?

They are not considered siblings, as pretty much everything in Selectors
ignores text nodes (and most other types of DOM nodes), except for the
:blank pseudo-class we recently introduced.

This is defined very explicitly in the sibling combinator section:
   "Non-element nodes (e.g. text between elements) are ignored when
   considering the adjacency of elements."
Equivalent text has been there since CSS Level 2.

(I don't think this was the best decision ever made, because quite frankly
I think authors would've found it much more useful to define siblingness,
first-child-ness, etc as "not separated by elements or non-whitespace text"
rather than as "not separated by elements". But we're pretty far down this
hole already. :| )

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

I didn't understand that last sentence. Could you clarify?

~fantasai

Received on Tuesday, 18 August 2015 03:25:37 UTC