Bug 198147 introduced a check for sub-selectors to know the property whitelist to apply. I think the right fix is not to parse :matches(::before) to begin with. It just doesn't really make much sense that webkit parses stuff like `:matches(::before):matches(::before)::before`. Other pseudo-classes like :host() or pseudo-elements like :host-context() don't allow pseudo-elements in the grammar for this very same reason. Also, in case you disagree, the check introduced in that bug wouldn't produce the correct behavior, I bet (haven't built myself) that that patch would stop the background / width / etc. from applying to the <li> element in the following test-case: <!doctype html> <style> :matches(::marker, li) { width: 100px; height: 100px; background: green; } </style> <li>foo</li>
Well, I dug through the spec and the spec technically allows (but does not define of course) this grammar. WebKit is also incompatible with other engines for stuff like :host and such. I filed https://github.com/w3c/csswg-drafts/issues/3963.
This would have prevented bugs like https://bugs.webkit.org/show_bug.cgi?id=198147 in the first place too.
I think we'd be okay with disallowing this. WDYT, Simon / Dean?
What about situations like `:matches(::before, ::after)`? For complex selectors, this can "save" a lot of characters.
> :matches(::marker, li) { I'm aware of this, it didn't seem something that would matter in practice. There is definitely no need to allow :matches(::marker), not sure about other cases.
*** This bug has been marked as a duplicate of bug 206654 ***