Simplifying the hover and active quirks? #75
Comments
|
Tests would be good to verify that's indeed Chromium's behavior. I think WebKit would be okay with attempting to align with that, yes. |
|
Here's a test-case. One quirk here is that at least Blink and Gecko parse <!doctype html>
<body>
<script>
let selectors = [
`*:hover`,
`:hover`,
`span:hover`,
`:is(a, span):hover`,
`:is(span):hover`,
`:not(div):hover`,
`[data-attr]:hover`,
`:hover:nth-child(1)`,
`:hover:first-child`,
];
for (let selector of selectors) {
let frame = document.createElement("iframe");
frame.src = `data:text/html,` + encodeURIComponent(`
<style>${selector} { background-color: rgba(0, 0, 0, .2) }</style>
<div id=root>
<p><strong>${selector}</strong>
<p><a data-attr href="#">Link</a>
<p><span data-attr>Non-link</span>
</div>
`);
document.body.appendChild(frame);
}
</script> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the issue with the Quirks Mode Standard?
https://quirks.spec.whatwg.org/#the-active-and-hover-quirk has a list of conditions that doesn't keep up with new CSS features.
It seems implementations do subtly different things that end up in subtle bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1856285:
I think Blink's behavior (which if I understand correctly is "only apply the quirk if the only thing in the selector is
:hoveror:activeand it's not nested) is simpler, and I think we should change the spec to match that, if my understanding is correct.@lilles / @andruud: Could you confirm my read of Blink's source is correct?
@annevk: Would WebKit be fine with that change? If so I'd be happy to send a PR.
cc @whatwg/css, I assume making stuff less quirky is generally good if we can get away with it...
The text was updated successfully, but these errors were encountered: