Closed
Bug 35246
Opened 24 years ago
Closed 20 years ago
:checked should work on selected OPTION elements
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: bnb, Unassigned)
References
Details
(Keywords: css3, testcase)
Attachments
(1 file, 2 obsolete files)
296 bytes,
text/html
|
Details |
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•24 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.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
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•24 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: 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...
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•24 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•24 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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 10•24 years ago
|
||
marking as later because it deals with CSS3 issues
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → LATER
Summary: CSS :active does not work within forms → [CSS3] :active does not work within forms
Comment 11•24 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•24 years ago
|
||
It's relative in that the discussion was about showing an option selected.
Comment 14•24 years ago
|
||
reopening and marking Future...
Status: RESOLVED → UNCONFIRMED
Resolution: LATER → ---
Target Milestone: --- → Future
Comment 15•24 years ago
|
||
Marking as new since its a future problem.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 16•24 years ago
|
||
Changing assignment. This might be a duplicate of bug 52948
Component: HTML Form Controls → Style System
Comment 17•24 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.
And this has nothing to do with bug 52948.
Comment 20•24 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
Updated•23 years ago
|
Priority: P3 → --
Comment 24•22 years ago
|
||
reduced test case for this bug... looks much like first exemple
Updated•21 years ago
|
Keywords: testcase
QA Contact: vladimire → ian
Summary: [CSS3] :active does not work within forms → :active doesn't work in forms
Updated•21 years ago
|
Assignee: rods → nobody
Status: ASSIGNED → NEW
OS: Windows 98 → All
QA Contact: ian → core.layout.form-controls
Hardware: PC → All
Updated•21 years ago
|
QA Contact: core.layout.form-controls → ian
Updated•21 years ago
|
Summary: :active doesn't work in forms → :active doesn't work in forms (nor should it; :checked should).
Updated•20 years ago
|
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 (?)
Comment 25•20 years ago
|
||
Attachment #92568 -
Attachment is obsolete: true
Comment 26•20 years ago
|
||
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•20 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•20 years ago
|
||
*** Bug 52574 has been marked as a duplicate of this bug. ***
Comment 29•20 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
Comment 30•20 years ago
|
||
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•20 years ago
|
||
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.
Updated•20 years ago
|
Attachment #160002 -
Flags: superreview?(dbaron)
Attachment #160002 -
Flags: review?(dbaron)
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.
Attachment #160002 -
Flags: superreview?(dbaron)
Attachment #160002 -
Flags: superreview+
Attachment #160002 -
Flags: review?(dbaron)
Attachment #160002 -
Flags: review?(bzbarsky)
Comment 33•20 years ago
|
||
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).
Status: NEW → RESOLVED
Closed: 24 years ago → 20 years ago
Resolution: --- → FIXED
Comment 34•20 years ago
|
||
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•20 years ago
|
||
Comment on attachment 160002 [details] [diff] [review] Fix Marking r- per comments.
Attachment #160002 -
Flags: review?(bzbarsky) → review-
Updated•13 years ago
|
Resolution: FIXED → WORKSFORME
Updated•13 years ago
|
Attachment #160002 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•