Re: [selectors] feedback

On 08/17/2015 10:40 PM, Anne van Kesteren wrote:
> 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:
>>>
>>> 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.

Well, it would be confusing if the behavior was implied from how
we interpret the tree. But it's not: it's explicitly called out:

   "Non-element nodes (e.g. text between elements) are ignored when
    considering the adjacency of elements."

As I mentioned, equivalent text has been there since CSS Level 2.

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

How about instead of providing a algorithm for finding matches in a
subtree, we used "match" as the hook, and DOM provides the list of
things that need to be evaluated against the selector?

You could then write something like

   Returns the document-ordered set of all elements [various conditions]
   that match selector S
   when scope-filtered to scoping element Y.

https://drafts.csswg.org/selectors-4/#match
https://drafts.csswg.org/selectors-4/#scope-filtered

The benefit of "match" as a hook is that it's been the terminology
used to describe selector operations for forever, and even though
we may need to do a bit of spec work to tighten up the definitions,
anybody working with selectors already knows what it means. Also
it's a much simpler interface, because it doesn't need to manage
the results or infer the inputs. I think this makes the interaction
between the specs easier to understand, and means that we're less
likely to run into complications/rewrites/cross-spec amends going
forward.

This would also solve Simon Pieters's concern in
   https://lists.w3.org/Archives/Public/www-style/2014Mar/0592.html
and give us more room to resolve dbaron's complaint in
   https://lists.w3.org/Archives/Public/www-style/2015Mar/0432.html

We'd need to do a bit of extra work to make sure the shadow DOM
selectors are correctly handled, but we (the Selectors, Scoping,
and DOM specs) all need to do extra work to make shadow DOM stuff
hook up correctly anyway, as it's not currently.

Additionally the "evaluate a selector" section being referenced
is very handwavy (i.e. more-or-less undefined) about what combinators,
in addition to ::shadow, ::content, and various other things, do
anyway, so it's not really giving us much benefit over "match".

~fantasai

Received on Thursday, 27 August 2015 01:42:29 UTC