:checked should work on selected OPTION elements




19 years ago
4 years ago


(Reporter: bnb, Unassigned)


({css3, testcase})

css3, testcase

Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)



19 years ago
If you can use CSS to specify the colors of a selection within a form you
should be able to specify a different set of colors for an active option to
a non-active option. The CSS :active class seems to allow you to do this,
however it doesn't work within forms!!

The current situation seems most unsatisfactory, since if you do specify colors
you can't see what you've selected, http://www.looking-glass.org/gallery/ is an
example of this.

Comment 1

19 years ago
The 2000-04-09-08-M15 nightly binary on WinNT appears to be displaying this
page as specified, although not as intended. While the mouse button is held 
down over an <OPTION>, that option is shown as red on white, as specified
bu the OPTION:active selector. But once the mouse button is let up, that
element is no longer active. 

I don't know much css, but adding an OPTION:focus selector might do the trick,
see http://www.w3.org/TR/REC-CSS2/selector.html#dynamic-pseudo-classes

Because Mozilla *is* honouring the OPTION:active selector, marking this
report INVALID.
Last Resolved: 19 years ago
Resolution: --- → INVALID

Comment 2

19 years ago
Wait a sec...

:focus is only valid when you have input focus (i.e. tabbed to appropriate box) 
this is explictly stated
:hover is only valid when the mouse is over the top
:visited is only valid on a visited link (this is not a link)
:link is only valid for a link

If :active doesn't tell you what option is selected then there isn't anything 
else that does!!! It is obviously wrong not to be able to specify the colors of 
an selected option separately from a non active one.

The CSS document I was refered to only says "for example" about having the 
mouse button pressed. Surely a selected option is always active? If not then 
the only other sensible action is to ignore CSS styles for a selected option 
(which is what IE5 even on the Mac does).

Comment 3

19 years ago
I'll agree that :focus is not exactly on target, but I would have thought that
the <OPTION> would be given focus in the process of being selected. This
may not work with a MULTIPLE <SELECT>, and the focus would go away when the
submit button is pressed, but at that point the new page should load, so that's
not a big loss. 

By extension from links, :active could be argued to apply at all SELECTED 
options until the the form is submitted, or it could be argued to apply only
in the process of making that <OPTION> SELECTED.

To my mind, the proper selector for SELECTED <OPTION>s would intuitively
be ":selected".

Calling in a CSS expert, as I have no idea what is planned for CSS3. 
Ian, what do you think?
There is a proposed solution for this in a working draft of CSS3:


The :checked pseudo-class should apply in this case.  (:selected is also
defined, but it has an entirely different meaning - relating to the current

I'm not so sure it's wise to implement the draft at this stage, although CSS3
seems to be moving rather slowly right now...

Comment 5

19 years ago
Bug 30551 which looked to me as if it got "lost" in bugzilla, seems to be
a duplicate of this. Unfortantly bugzilla doesn't seem to want to let me
reopen this bug, or mark it as a duplicate :(

Comment 6

19 years ago
Frustratingly though, the CSS3 draft doesn't mention select boxes explicitly either. We could argue about 3 or 4 different pseudo-classes applying in this case. Some clarification is required here.
Actually it does mention selects explicitly, since it mentions the SELECTED
attribute, which is only an attribute for OPTIONs.  Therefore :checked is the
relevant pseudo-class.

Comment 8

19 years ago
I'm reopening this bug as a reminder for the form controls to know about 
:checked when it works. Currently, it appears it isn't implemented.
Resolution: INVALID → ---

Comment 9

19 years ago
*** Bug 30551 has been marked as a duplicate of this bug. ***

Comment 10

19 years ago
marking as later because it deals with CSS3 issues
Last Resolved: 19 years ago19 years ago
Resolution: --- → LATER
Summary: CSS :active does not work within forms → [CSS3] :active does not work within forms

Comment 11

19 years ago
Not sure -- the fix for bug 25869, "[FIX]Select color can't override inline 
style", might be relevant to this bug.

Comment 12

19 years ago
It's relative in that the discussion was about showing an option selected. 


19 years ago
Keywords: css3

Comment 13

19 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Comment 14

19 years ago
reopening and marking Future...
Resolution: LATER → ---
Target Milestone: --- → Future

Comment 15

19 years ago
Marking as new since its a future problem.
Ever confirmed: true

Comment 16

19 years ago
Changing assignment. This might be a duplicate of bug 52948
Component: HTML Form Controls → Style System

Comment 17

19 years ago
Forgot to change the owner :) Sorry for the spam
Assignee: rods → pierre
QA Contact: bsharma → chrisd
ksosez@softhome.net - Why did you reassign this bug?  It is a bug (or perhaps 
feature request for CSS3 support) in the form controls component.  I think it 
doesn't have much to do with the style system -- it's more the event system and 
the form controls being able to handle CSS properties.

Comment 20

19 years ago
This bug shouldn't have been moved: back to rods/HTML Form Controls...
Assignee: pierre → rods
Component: Style System → HTML Form Controls
QA Contact: chrisd → bsharma

Comment 21

18 years ago
leaving as is for now

Comment 22

18 years ago
QA Contact Update
QA Contact: bsharma → vladimire


17 years ago
Priority: P3 → --

Comment 23

17 years ago
Adding qawanted; could use a minimized testcase.
Keywords: qawanted

Comment 24

17 years ago
Created attachment 92568 [details]
:hover and :active test on forms and form element

reduced test case for this bug... looks much like first exemple


15 years ago
Keywords: testcase
QA Contact: vladimire → ian
Summary: [CSS3] :active does not work within forms → :active doesn't work in forms


15 years ago
Depends on: 120834


15 years ago
Assignee: rods → nobody
OS: Windows 98 → All
QA Contact: ian → core.layout.form-controls
Hardware: PC → All


15 years ago
QA Contact: core.layout.form-controls → ian
Summary: :active doesn't work in forms → :active doesn't work in forms (nor should it; :checked should).
QA Contact: ian → core.layout.form-controls
Summary: :active doesn't work in forms (nor should it; :checked should). → :checked should work on selected <option> elements (?)
Created attachment 145442 [details]
Actual testcase for :checked
Attachment #92568 - Attachment is obsolete: true
It looks like :checked works fine.  You can't set the color and background,
because the selection painting code overwrites those (as it does for any
content, really).  But the selector matches and is updated dynamically as things
are selected/deselected....

Comment 27

15 years ago
Ian, should this be marked WFM?
(And perhaps tracking the changing 'background'/'color' thing in another bug.)
QA Contact: core.layout.form-controls → ian

Comment 28

15 years ago
*** Bug 52574 has been marked as a duplicate of this bug. ***

Comment 29

15 years ago
Boris outlined in  bug 52574 that it could probably be fixed by removing '!
important' in 'forms.css' from the following lines:

# 226 option:checked {
# 227   background-color: Highlight ! important;
# 228   color: HighlightText ! important;
# 229 }
Summary: :checked should work on selected <option> elements (?) → :checked should work on selected OPTION elements
well if the testcase had the same font-size I'd be _very_ happier....O well.

I have a patch forthcoming that works on this testcase, will test on a few
random sites to ensure it does not break them
Created attachment 160002 [details] [diff] [review]

This follow's anne and bz's assumption on how to fix, tested on two random
sites with multiple select options, worked as expected, tested in our testcase
on this bug.
Attachment #160002 - Flags: superreview?(dbaron)
Attachment #160002 - Flags: review?(dbaron)
Comment on attachment 160002 [details] [diff] [review]

sr=dbaron, but I'm not sure why this belongs on this bug (which seems to be

I'm also not convinced that allowing this to be author-stylable is a good
Attachment #160002 - Flags: superreview?(dbaron)
Attachment #160002 - Flags: superreview+
Attachment #160002 - Flags: review?(dbaron)
Attachment #160002 - Flags: review?(bzbarsky)
The biggest problem with making this author-stylable is that rules like
"option.foo" will style all options uniformly, making it impossible to tell
which ones are checked.  Given that, I am rather wary of taking this patch; if
people think we should take it I would like to see some argument as to why
(perhaps combined with some analysis of what existing pages do?)

Other than that, David is right and this bug is fixed (which is what I said in
comment 26), so marking so.

Note that bug 52574 was mis-dupped here (though that one is fixed too; the patch
attached here is for a bug different from this one and from bug 52574 altogether).
Last Resolved: 19 years ago15 years ago
Resolution: --- → FIXED
For those who look back here:
my initial patch here got its own bug thanks to anne, I'll re-post the patch
later on (tomorrow or monday likely) [bug 262675]
Comment on attachment 160002 [details] [diff] [review]

Marking r- per comments.
Attachment #160002 - Flags: review?(bzbarsky) → review-
Attachment #160002 - Attachment is obsolete: true
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.