- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 27 Aug 2015 09:41:00 +0200
- To: www-style@w3.org, Anne van Kesteren <annevk@annevk.nl>
On 08/27/2015 08:06 AM, Anne van Kesteren wrote: > On Thu, Aug 27, 2015 at 3:41 AM, fantasai <fantasai.lists@inkedblade.net> wrote: >> 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. > > I know, but this text doesn't always apply. Otherwise :empty would not > work. Suddenly with :empty you operate on a different tree. Right, this text doesn't appear in the section on :empty. > It seems you also ignored my comment about Shadow DOM. I didn't have a reply for it. :) >> 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? > > Doesn't work for :empty. And still doesn't help with pseudo-elements > and such as the input for matching those would be the same. Why doesn't it work for :empty? If it's not an element, it can't match :empty anyway. Perhaps you're misunderstanding what I meant. DOM provides the entire DOM tree for pattern-matching--of course. But for its .query methods the DOM spec compiles the list of elements that are potential output and filters them by whether or not they match. Selectors only defines what it means for an element to match. This way Selectors doesn't need to decide what elements are valid output, or define how to traverse the DOM tree to find said potential output elements, or define out the output of .querySelector is sorted or otherwise represented. These are particulars of the .query methods, not particulars of how selectors work, so they belong in DOM, not in Selectors. ~fantasai
Received on Thursday, 27 August 2015 07:41:42 UTC