Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 243459 - CSS3 Selectors HTML css3-modsel-19a.html
: CSS3 Selectors HTML css3-modsel-19a.html
: css3, qawanted, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Other Branch
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Jet Villegas (:jet)
: 255713 (view as bug list)
Depends on: 65917
  Show dependency treegraph
Reported: 2004-05-12 17:14 PDT by Bob Clary [:bc:]
Modified: 2004-08-15 21:59 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Bob Clary [:bc:] 2004-05-12 17:14:27 PDT
Fails in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040512
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2004-05-12 17:26:57 PDT
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.
Comment 2 Anne (:annevk) 2004-05-13 02:00:20 PDT
> 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".
Comment 3 Mats Palmgren (:mats) 2004-08-15 19:18:10 PDT
*** Bug 255713 has been marked as a duplicate of this bug. ***
Comment 4 David Baron :dbaron: ⌚️UTC-7 (busy until November 7) 2004-08-15 19:35:57 PDT
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.
Comment 5 Lachlan Hunt 2004-08-15 19:40:41 PDT
The CSS2.1 spec doesn't say it's up to the UA, it only states [1]:

  "CSS doesn't define which elements may be in the above states,
   or how the states are entered and left."

CSS3 Selectors states [2]:

  "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
mentions [1]:

  "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

Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2004-08-15 21:39:29 PDT
Any element that can have an onclick handler can be "activated"...
Comment 7 Lachlan Hunt 2004-08-15 21:54:45 PDT
(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...
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2004-08-15 21:59:30 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.