You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: