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

[css-shadow-parts] are rules for which pseudo-classes and pseudo-elements work after ::part() parse-time or match-time? #10786

Open
dbaron opened this issue Aug 27, 2024 · 2 comments

Comments

@dbaron
Copy link
Member

dbaron commented Aug 27, 2024

When I read the spec for ::part(), it describes rules about allowing pseudo-elements and pseudo-classes after ::part() in selectors. Those rules seem to say that all pseudo-classes and pseudo-elements are syntactically allowed, but that some of them never match.

I believe implementations across Chromium, Gecko, and WebKit have instead implemented these restrictions as parse-time restrictions that make the selectors not be syntactically valid. I know this is true in Chromium (I was working on the relevant code today), and I just added a test to WPT that appears to confirm that WebKit and Gecko agree (unless I'm misunderstanding things).

(I plan to open a separate issue, also related to the above test, about the fact that those tests depend on somewhat-vague wording that might be interpreted in different ways; see for example #9795 for previous confusion.)

How intentional was that wording in the spec? Should the spec change? Or is there sufficient justification to attempt to change multiple somewhat-interoperable engines here?

@cdoublev
Copy link
Collaborator

I think parse-time validation is not ideal for backward compatibility, if there is a chance that a restriction will be removed later.

@tabatkins
Copy link
Member

I strongly prefer not putting more parse-time restrictions on Selectors than absolutely necessary, given the terrible behavior of Selectors wrt validity. So I'd really prefer that everything be allowed at parse time, and ones that aren't applicable just never match.

I can live with it going either way, tho.

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