Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element.matches and pseudo-elements #185

Open
SimonSapin opened this issue Mar 4, 2016 · 13 comments
Open

Element.matches and pseudo-elements #185

SimonSapin opened this issue Mar 4, 2016 · 13 comments

Comments

@SimonSapin
Copy link

https://dom.spec.whatwg.org/#dom-element-matches links to https://drafts.csswg.org/selectors-4/#match-a-selector-against-an-element which links to https://drafts.csswg.org/selectors-4/#evaluate-a-selector which says:

APIs using this algorithm […] may optionally provide […] which pseudo-elements are allowed to show up in the match list, if any. If not specified, this defaults to allowing all pseudo-elements.

As far as I understand, "allowing all pseudo-elements" means that pseudo-elements are effectively ignored during matching. For example, document.body.matches('body::after') should return true. This seems backwards, and indeed Firefox 44 and Chromium 49 both return false.

The DOM spec should probably add “with an empty list of pseudo-elements” near “the result of match a selector against an element”.

Other Selectors-related APIs likely have similar issues.

@annevk
Copy link
Member

annevk commented Mar 5, 2016

I don't really understand the setup here. @tabatkins how can CSS just return a pseudo-element? The engine needs to have the context of a node or a set of nodes, no?

@tabatkins
Copy link
Contributor

The prose algorithm can return pseudos, because the result might be used by further prose algorithms that understand pseudo-elements.

Obviously there's not currently any way to surface pseudo-elements in JS.

@annevk
Copy link
Member

annevk commented Mar 8, 2016

Don't you need to have a node and a pseudo? It seems like you're assuming the node tree and the layout tree are intertwined, which would be weird.

@annevk
Copy link
Member

annevk commented Aug 17, 2016

@tabatkins ping.

@tabatkins
Copy link
Contributor

Augh, I didn't pay enough attention to the OP here anyway.

Wrt the OP, document.body.matches('body::after') definitely returns false as currently specified. "Evaluate the selector" ends up returning just the body's ::after pseudo-element, and then "match the selector against an element" doesn't find <body> in the list, so you get false, as expected. So, DOM doesn't need to do anything here.

querySelector() does need to pass an empty list of allowed pseudo-elements, tho, since otherwise you get nonsensical results (there's no way to reflect a pseudo-element as a JS object right now).

@annevk
Copy link
Member

annevk commented Aug 17, 2016

How can it return a pseudo-element though? Does that carry a pointer to the element?

@tabatkins
Copy link
Contributor

Yes, pseudo-elements (the spec concept) have a pointer to their originating element. If/when we expose pseudo-elements to JS, they'll similarly have a parentElement attribute.

@annevk
Copy link
Member

annevk commented Aug 17, 2016

Thanks, and the pseudo-element gets returned because the selector was parsed successfully and it is the last thing in the list? No out-of-band information involved?

@tabatkins
Copy link
Contributor

Your first question confuses me a little bit - the pseudo-element gets returned because that's what the selector selects. Unclear what out-of-band information you could be talking about.

@annevk
Copy link
Member

annevk commented Aug 17, 2016

I'm wondering if we're on the same page that the input to the algorithm is the selector and the node tree only.

@tabatkins
Copy link
Contributor

Yes, that's it. But the output isn't restricted to things from the node tree (it's nodes + pseudo-elements).

@annevk
Copy link
Member

annevk commented Aug 18, 2016

I still don't understand why it would default to allowing all pseudo-elements. This algorithm is specifically designed for querySelector() and matches(). Why make the invocation more complicated?

Does it have any invocations other than those two APIs?

@annevk
Copy link
Member

annevk commented Mar 16, 2017

@tabatkins ping.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants