This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
http://dom.spec.whatwg.org/#interface-parentnode [[ For each element e in elementSet, append the elements that are not in result and result from matching s against e's root using scoping root e, to result. [SELECTORS] ]] This should say something about pseudo-elements. In implementations they seem to be valid, but not match anything.
I don't understand why we need to mention them.
Well, based on the current spec, I don’t know what is supposed to happen when I use document.query('p::after'). Does it throw? Return null? Ignore ::after and return a <p> element? It’s either specified in a part of the spec that I missed, or it’s not defined which is bad for interop.
How would what it is matched be ever up to DOM? That's up to the Selectors specification.
It's not a matter of what gets matched (Selectors does indeed define that), but what gets returned by the function. When you match a selector against a tree, you might get pseudo-elements. In that case, what gets added to _result_ and ultimately returned to the user? (The right answer is to use the new PseudoElement interface, I think, but the match-current-implementation behavior is to ignore them.)
> The right answer is to use the new PseudoElement interface, I think Defining the right behavior there could get ... pretty exciting. I think the right thing here is in fact to match current implementations.
Wait, Selectors matches against a DOM, not a layout tree Tab. This again shows you not defining the actual tree creates problems.
(In reply to Anne from comment #6) > Wait, Selectors matches against a DOM, not a layout tree Tab. This again > shows you not defining the actual tree creates problems. Dunno what you're talking about, bro. Selectors totally returns pseudo-elements when you specify them, at least in CSS. Agree that there's still gaps there that need to be filled in, though.
Bro? What I talk about is that pseudo-elements are not in the DOM so there's no way to return them.
Is this solved with the updates to Selectors?
It’s not clear to me that the issue is solved, but I guess DOM now says what it can/should and the issue is now in Selectors. Moved to http://lists.w3.org/Archives/Public/www-style/2014Feb/0447.html