35246 - :checked should work on selected OPTION elements

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[bnb]

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

[Sean Richardson]

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.

Comment 2

[bnb]

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

[Sean Richardson]

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?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There is a proposed solution for this in a working draft of CSS3:

http://www.w3.org/TR/css3-userint#pseudo-checked

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

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

[bnb]

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

[Nicholas Cull]

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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[rods (gone)]

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.

Comment 9

[rods (gone)]

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

Comment 10

[rods (gone)]

marking as later because it deals with CSS3 issues

Comment 11

[Sean Richardson]

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

Comment 12

[rods (gone)]

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

Comment 13

[bsharma]

Updating QA contact.

Comment 14

[Blake Ross]

reopening and marking Future...

Comment 15

[Keyser Sose]

Marking as new since its a future problem.

Comment 16

[Keyser Sose]

Changing assignment. This might be a duplicate of bug 52948

Comment 17

[Keyser Sose]

Forgot to change the owner :) Sorry for the spam

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

[e-mail] - 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 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And this has nothing to do with bug 52948.

Comment 20

[Pierre Saslawsky]

This bug shouldn't have been moved: back to rods/HTML Form Controls...

Comment 21

[rods (gone)]

leaving as is for now

Comment 22

[Vladimir Ermakov]

QA Contact Update

Comment 23

[Greg K.]

Adding qawanted; could use a minimized testcase.

Comment 24

[Johan Buret]

Attachment: :hover and :active test on forms and form element

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

Comment 25

[Boris Zbarsky [:bzbarsky]]

Attachment: Actual testcase for :checked

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

[Anne (:annevk)]

Ian, should this be marked WFM?
(And perhaps tracking the changing 'background'/'color' thing in another bug.)

Comment 28

[Anne (:annevk)]

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

Comment 29

[Anne (:annevk)]

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 }

Comment 30

[Justin Wood (:Callek)]

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

Comment 31

[Justin Wood (:Callek)]

Attachment: Fix

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.

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 160002 [details] [diff] [review]
Fix

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

I'm also not convinced that allowing this to be author-stylable is a good
thing.

Comment 33

[Boris Zbarsky [: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).

Comment 34

[Justin Wood (:Callek)]

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 35

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 160002 [details] [diff] [review]
Fix

Marking r- per comments.