[whatwg] Making elements match the :active pseudoclass
Currently,
http://www.whatwg.org/specs/web-apps/current-work/complete/links.html#pseudo-classes
states that the only elements which can receive the :active
pseudoclass are a handful of form elements and any other element which
is specially focusable.
This does not match any current browser. All 5 of the major browsers
allow any element to be :active when clicked. They do differ slightly
on how they determine when an element is :active, though:
* Firefox and Webkit make the target of clicks and all its ancestors :active.
* IE8 and IE9 make only the target of the click :active
* I'm not 100% sure about Opera's behavior, but it appears that it
finds the first ancestor of the target which would match an :active
rule, and makes that element :active.
You can see this behavior in the following two example pages:
!doctype html
style
:active { border: 2px solid red; }
/style
pfoo a href=bar spanbaz/span/a/p
!doctype html
style
p:active { border: 2px solid red; }
/style
pfoo a href=bar spanbaz/span/a/p
(The pages may exhibit surprising behavior - remember that html and
body are present in the DOM as well and can potentially match
:active.)
~TJ
Re: [whatwg] Making elements match the :active pseudoclass
On 12/28/2010 04:27 PM, Tab Atkins Jr. wrote:
Currently,http://www.whatwg.org/specs/web-apps/current-work/complete/links.html#pseudo-classes
states that the only elements which can receive the :active
pseudoclass are a handful of form elements and any other element which
is specially focusable.
This does not match any current browser. All 5 of the major browsers
allow any element to be :active when clicked. They do differ slightly
on how they determine when an element is :active, though:
* Firefox and Webkit make the target of clicks and all its ancestors :active.
I'll note CSS specs explicitly allow making the ancestors of the
activated element to also match :active.
* IE8 and IE9 make only the target of the click :active
So
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aa%3Aactive%20{%20background%3A%20green%3B%20}%0Aa%20{%20background%3A%20red%3B%20color%3A%20white%3B%20}%0A%3C%2Fstyle%3E%0A%3Ca%20href%3D%22%22%3E%3Cspan%3EClick%20to%20make%20green.%3C%2Fspan%3E%3C%2Fa%3E%0A
does not turn green? That seems pretty broken.
* I'm not 100% sure about Opera's behavior, but it appears that it
finds the first ancestor of the target which would match an :active
rule, and makes that element :active.
That's... interesting.
FWIW, I think the behavior currently in the spec makes the most sense.
If the element has no behavior to activate, it doesn't make sense to
me for the element to ever match :active. And if there is behavior to
activate, it should be keyboard-activateable as well, not just mouse-
clickable.
I'm also interested to know whether there's a web-compat issue here or
just a bug-compat issue, and what the implementers think.
~fantasai
Re: [whatwg] Making elements match the :active pseudoclass
On Tue, Dec 28, 2010 at 2:06 PM, fantasai fantasai.li...@inkedblade.net wrote:
On 12/28/2010 04:27 PM, Tab Atkins Jr. wrote:
* IE8 and IE9 make only the target of the click :active
So
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aa%3Aactive%20{%20background%3A%20green%3B%20}%0Aa%20{%20background%3A%20red%3B%20color%3A%20white%3B%20}%0A%3C%2Fstyle%3E%0A%3Ca%20href%3D%22%22%3E%3Cspan%3EClick%20to%20make%20green.%3C%2Fspan%3E%3C%2Fa%3E%0A
does not turn green? That seems pretty broken.
Yes (it stays red), and I agree that it's totally broken.
FWIW, I think the behavior currently in the spec makes the most sense.
If the element has no behavior to activate, it doesn't make sense to
me for the element to ever match :active. And if there is behavior to
activate, it should be keyboard-activateable as well, not just mouse-
clickable.
I'm also interested to know whether there's a web-compat issue here or
just a bug-compat issue, and what the implementers think.
I know that I've written pages in the past which implement button-like
things with non-interactive elements. This wasn't a great idea, as
it's inaccessible for keyboard users, but I don't think I'm alone in
making this mistake. (It was for some intranet apps for my previous
employer, so at least it's not exposed to the public.)
~TJ
