Re: [selectors] feedback

On Tue, Aug 18, 2015 at 4:16 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 04/22/2014 03:28 AM, Anne van Kesteren wrote:
>> 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.

Right, which makes it confusing. Sometimes your text operates on one
kind of tree and sometimes another. It's going to be even more
confusing once Shadow DOM becomes a part of DOM.

It would really be far better for selector matching to be defined in
terms of DOM, which is what is actually being implemented.


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

Well, you could still have it and say that the current set of
selectors is equivalent to the nextElementSibling et al properties DOM
has.


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

It took me a while too! But I think what I meant is that for methods
like querySelector() and matches(), I need to be able to indicate that
pseudo-elements do not constitute a match, because I cannot handle
them. (There might be alternative ways to handle this, but right now
it doesn't follow from the algorithms.)


-- 
https://annevankesteren.nl/

Received on Tuesday, 18 August 2015 05:40:39 UTC