Bug 198204
| Summary: | :matches() shouldn't allow pseudo-elements inside. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Emilio Cobos Álvarez (:emilio) <emilio> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | dino, hi, koivisto, rniwa, simon.fraser |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Emilio Cobos Álvarez (:emilio)
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>
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Emilio Cobos Álvarez (:emilio)
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.
Ryosuke Niwa
This would have prevented bugs like https://bugs.webkit.org/show_bug.cgi?id=198147 in the first place too.
Ryosuke Niwa
I think we'd be okay with disallowing this.
WDYT, Simon / Dean?
Devin Rousso
What about situations like `:matches(::before, ::after)`? For complex selectors, this can "save" a lot of characters.
Antti Koivisto
> :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.
Antti Koivisto
*** This bug has been marked as a duplicate of bug 206654 ***