Fails in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040512
Hmm... The spec basically says that what :active means is up to the UA, does it
not? I suppose it could be argued that there is no reasonable way to call that
<p> active in this particular test, but that makes some assumptions about what
:active means that are not actually in the spec.
So I'm not sure how valid this test is, to be truthful.
Note also bug 65917 as far as our private issues with :active go, though.
> The :active pseudo-class applies while an element is being activated by the
> user. For example, between the times the user presses the mouse button and
> releases it.
The question is probably what the editor understanded under "activated".
*** Bug 255713 has been marked as a duplicate of this bug. ***
I'm pretty sure the WG explicitly decided that this is up to the UA, and there
are significant advantages to doing it this way -- it gives authors more
flexibility and power, it's easier to implement, and the implementation doesn't
need to be constantly revised.
The CSS2.1 spec doesn't say it's up to the UA, it only states :
"CSS doesn't define which elements may be in the above states,
or how the states are entered and left."
CSS3 Selectors states :
"There may be document language or implementation specific limits on which
elements can become :active or acquire :focus."
Thus, it is not up to the UA, though UA specific limits may affect if :active is
applied or not, so it should only apply to those elements in the (X)HTML, and
other XML based specs define that an element can be activated. eg. HTML4
"When the A element's href attribute is set, the element defines
a source anchor for a link that may be activated"
There are similar definitions for submit and reset buttons, and maybe other
elements as well. It certainly does not define that any element may be activated.
Also, take a look at the test cases I linked to for bug 255713
Any element that can have an onclick handler can be "activated"...
(In reply to comment #6)
> Any element that can have an onclick handler can be "activated"...
Yes, that is true. CSS2.1 does state in section 5.11.3:
"Scripting may change whether elements react to user events or not..."
So, perhaps :active should also apply when certain event handlers are applied to
the element, such as onclick, ondblclick, onmousedown, etc...
What about bubbling/capturing handlers that activate for that target?
The point is, deciding whether an event handler will activate when clicking on
an element is basically the halting problem.