Open Bug 79107 Opened 19 years ago Updated 9 months ago

Styles assigned to OPTION elements aren't used for pull-down SELECT lists (comboboxes)

Categories

(Core :: Layout: Form Controls, defect, minor)

All
Windows
defect
Not set
minor

Tracking

()

REOPENED
Future

People

(Reporter: SkewerMZ, Unassigned)

References

()

Details

(Keywords: testcase, Whiteboard: [Chrome supports on Windows])

Attachments

(4 files)

Procedure: Go to the URL (I might make a testcase later) and go down to the
color listbox (also happens on the gender listbox). Select one of the items that
has a style applied to it.

Expected: When the listbox is collapsed, the style for the OPTION element should
still be visible.

Actual: When the listbox is collapsed, the style for the SELECT is used and the
style for the OPTION is ignored. I can't find anything in the CSS spec about
this, but in theory the style for the OPTION should always take priority. Can
anyone confirm W3C's position on this one way or the other? I will also note
that IE5.5 behaves as expected.

Build: 20010505 Win98
Keywords: css1
Adding a simplified testcase, URL no longer needed. Adding appropriate keyword.
Keywords: qawanted
This may get fixed by the XBL form controls.
Assignee: pierre → rods
Status: UNCONFIRMED → NEW
Component: Style System → HTML Form Controls
Ever confirmed: true
Keywords: qawanted
QA Contact: ian → vladimire
Status: NEW → ASSIGNED
Target Milestone: --- → Future
There seems to be another component to this bug:

In build 2001060804 on Win2k (SP2), there seems to be some space between 
options. Let's assume that all the options are colored yellow.  What you should 
see when you drop the list down is a solid yellow background in the area behind 
all the options. However, between certain options, there is a break in the 
background letting the parent element's (select) background shine through.

I'm attaching a testcase for that shortly...

Jake
I'm seeing the described behavior at or below 90% zoom in 2001060804 Win98. You
may want to start another bug for this, it's a separate issue.
Reported bug 85051 for behavior I recently commented on in this bug.

Jake
*** Bug 90090 has been marked as a duplicate of this bug. ***
See also bug 56451.
*** Bug 56451 has been marked as a duplicate of this bug. ***
Reconfirmed using FizzillaCFM/2002070913. Setting All/All.
OS: Windows 98 → All
Hardware: PC → All
Keywords: html4
Whiteboard: [CSS1-5.3.7][HTML4-17.6]
*** Bug 180728 has been marked as a duplicate of this bug. ***
*** Bug 153307 has been marked as a duplicate of this bug. ***
*** Bug 165093 has been marked as a duplicate of this bug. ***
*** Bug 186379 has been marked as a duplicate of this bug. ***
I think jkeiser wanted this, based on one of the dups.
Assignee: rods → jkeiser
Status: ASSIGNED → NEW
*** Bug 193318 has been marked as a duplicate of this bug. ***
Just confirming still exists in 1.3b

(I'm running through my list of bugs against 1.3b and making notes)
*** Bug 201194 has been marked as a duplicate of this bug. ***
So... When the <select> is collapsed, you are seeing the <select> not the
<option>.  This becomes pretty obvious if you drop the list down -- then you see
the <select> _and_ the <option>

As in, I don't know whether per spec this is a bug at all.

Not to say that we may not want to "fix" it in the name of compat.
*** Bug 213305 has been marked as a duplicate of this bug. ***
*** Bug 232747 has been marked as a duplicate of this bug. ***
*** Bug 235820 has been marked as a duplicate of this bug. ***
*** Bug 238981 has been marked as a duplicate of this bug. ***
*** Bug 246656 has been marked as a duplicate of this bug. ***
*** Bug 248628 has been marked as a duplicate of this bug. ***
*** Bug 255040 has been marked as a duplicate of this bug. ***
Bug 255040 (reported by trevor@baka.com and marked as a duplicate of this one)
brings attention to the fact that (at least to some extent) it is possible to
work around the problem using JavaScript. This was useful for me, so here’s a
small example to illustrate how it can be done, keeping the use of a style-sheet:
http://paginas.fe.up.pt/~tga/issue_20040625/
Relevant files in the directory are index.htm, main.css and javascripts.js.
Please note that a style must be defined for the default colour as well;
otherwise, any default-coloured option would adopt the colour of the last
selected option. Also, for some reason, using this work around, the border style
of the select element seems to get stuck at “inset”; there’s no way to override
it – maybe this is another bug.
> Also, for some reason, using this work around, the border style
> of the select element seems to get stuck at “inset”; there’s no way to override
> it – maybe this is another bug.

It is another bug and it has been reported :-) Sadly, the 4 pixel bevel border
appears now fixed and this appears to be a feature not a bug "in the name of
compat" :-( 
Yes, I guess you mean Bug 187691. If indeed there's no specification on how to
handle the border style, then it seems acceptable to simply ignore the style and
set the border to a default. What I find confusing is that the border is set to
_different defaults in different situations_: when no style is set or only the
border style is (tentatively) set, the border defaults to solid; when both the
border and the background-color styles are (tentatively) set, the border
defaults to inset (and the background is set as expected). This test-case
illustrates that behaviour:
http://paginas.fe.up.pt/~tga/issue_20040817/

By the way, the JavaScript work-around in my previous post is not fully
successful: it works if one uses the mouse; it doesn't work if you tab to the
control and then use the arrow keys to move through the options. This seems to
indicate that the onchange script runs only when the change is triggered by the
mouse... This is probably another issue, probably already reported . Will try to
figure out some other way to achieve coloured selects, as I really need
something of the sort, preferably working with Mozilla.
Telmo, onchange only fires with the mouse, hitting enter key, or leaving the
SELECT. This is because some site use the onchange to autmatically send the user
to a website.  If onchange fired with a simple down arrow users could not
navigate these websites see www.comics.com.
Thanks Jesiah, that makes all sense.
*** Bug 265083 has been marked as a duplicate of this bug. ***
*** Bug 271160 has been marked as a duplicate of this bug. ***
*** Bug 278994 has been marked as a duplicate of this bug. ***
re: c#20 for what its worth IE does at least paint the <option> background
in-place of the <select> background when it is specified.

for another testcase see the URL (you may need to copy/paste that into the
url-bar of your browser)

In this testcase when Foo is selected and select is "closed" the background
should shine green not red, and when bar is selected, background should shine
red still
Hello. I was going to file a new bug, but I think I have found this one, which
could correct the behaviour I have found when is fixed. I will add a new testcase.

BTW: the URL of this bug has an errata (transparant, instead of transparent).
Comment on attachment 37774 [details]
testcase showing <select> background shining through between some <option> elements

This testcase seems to be obsolete now.  There is no space between options on
latest Mozilla trunk on Linux.	I even tried with various font scalings.
Samuel, I think you are correct about that attachment. [WFM: Firefox 1.0.4 in
SUSE Linux 9.3 (Gecko/20050511).]
Samuel,

Space between options was a side issue which ended up being reported as another
bug.  It has been fixed for a long time now.  So you are missing the point if
that by working for you, you think that this bug is WFM.

Also, the testcase in the URL field misses the point.  The idea is that if the
background color either hasn't been set or has been set explicitly to
transparent, then the color of the first option ought to show through (whether
the spec defines this or not, that's the core argument here).

So, this would be more appropriate...

data:text/html,<select style="background-color:transparent;"><option
style="background-color:green;">foo</option><option
style="background-color:transparent;">bar</option></select>


There are a couple goofy things going on here:

1.  The green color of the first option isn't showing through the unselected box
(for instance, on initial page load before any action is taken on the box), even
though the select's color is transparent.

2.  When the select box is dropped down, the non-explicitly colored option is
gray.  That's clearly a bug.  And when one removes the background-color setting
on the select, the formerly gray option becomes white, as it should have been
when the select was set to transparent.

So, this bug is nowhere near addressed.  And even if it is decided that the
specs don't define behavior clearly enough here to make it worth making a change
in select/option coloring behavior, #2 above still needs to be addressed because
of the inconsistent behavior in coloring of option elements depending on the the
coloring of the select element.


Jake
*** Bug 300109 has been marked as a duplicate of this bug. ***
I am having a similar issue with this bug, but in a different context.  I can't submit my example because bugzilla crashes.  It's pretty small, so let me include it here:

<body>

<style>
select{background-color:#DF7;width:100%;}
.op{background-color:#FFF}
</style>

<select id="page" name="page" style="width:100px">
<option value=""></option>
<option value="names" class="op">Names</option>
<option value="phone" class="op">Phone</option>
<option value="logout">OK</option>
</select>

<select id="page" name="page" style="width:100px">
<option value=""></option>
<option value="names" class="op">Names</option>
<option value="phone" class="op">Phone</option>
<option value="logout">THIS IS TOO LONG</option>
</select>

 </body>
Just a note:  point #2 in comment #41 no longer seems to be an issue.  Point #1 is still an issue.

Jake
*** Bug 354850 has been marked as a duplicate of this bug. ***
(In reply to comment #20)
> I don't know whether per spec this is a bug at all.
> Not to say that we may not want to "fix" it in the name of compat.

I read very carefully [HTML4-17.6] and [CSS1-5.3.7] and I fail to see where or how the spec indicate that, by default, styles assigned to OPTION elements should "bubble up" or be transferred to collapsed select lists. 

DOM inspector show that the default background-color of select is background-color: rgb(255, 255, 255);
and not 
background-color: transparent;

On the Windows platform, colors affecting selected items are theme-predefined and also user-customizable via:

Start/Control Panel/Display/Appearance tab/Advanced button/Item:/Selected items/

I.e.: Color 1 will choose the background color of selected items. 
Also, os color scheme will affect background-color and text color of selected items.

For web authors, CSS 3 selectors module offer via the dynamic pseudo-class ::checked property capability to style the option element.
"The :checked pseudo-class initially applies to such elements that have the HTML4 selected and checked attributes"
http://www.w3.org/TR/css3-selectors/#checked

I'm removing html4 and css1 keywords and adding compat keyword.
Keywords: css1, html4compat
Whiteboard: [CSS1-5.3.7][HTML4-17.6]
Another testcase for this bug:

http://www.gtalbot.org/BugzillaSection/Bug79107.html

Expected results: transparent

Actual results in Seamonkey 1.5.a rv:1.9a1 build 2006093009 and in Firefox 1.5.0.7 rv:1.8.0.7 build 20060909: rgb(255, 255, 255)

Note that Opera 9.02 succeeds and gets the expected results; MSIE 7 RC1 build 5700.6 fails and returns #ffffff
(In reply to comment #46)
> (In reply to comment #20)
> > I don't know whether per spec this is a bug at all.
> > Not to say that we may not want to "fix" it in the name of compat.
> 
> I read very carefully [HTML4-17.6] and [CSS1-5.3.7] and I fail to see where or
> how the spec indicate that, by default, styles assigned to OPTION elements
> should "bubble up" or be transferred to collapsed select lists. 
> 

That's one interpretation, the one that the bug reporters here are assuming is that the SELECT element contains OPTION elements. The selected item *is* an OPTION element, and therefore should look exactly the same when selected in the SELECT as it does in the drop-down-list.

Your interpretation appears to suggest, instead, that the SELECT element contains the Text and Value copied from the selected OPTION, much like when you select a windows combobox or intellisense input to copy the selected text into the input.


I, too, prefer the first definition of behaviour and would like to see styles applied to OPTION elements apply when the same option is selected in a single-line SELECT
> That's one interpretation, the one that the bug reporters here are assuming is
> that the SELECT element contains OPTION elements. The selected item *is* an
> OPTION element, and therefore should look exactly the same when selected in the
> SELECT as it does in the drop-down-list.

The current Mozilla behavior is not in violation of any known or implicit HTML 4.01 guidelines/recommendation whatsoever or any CSS1 guidelines/recommendations. So, this is not an HTML 4 issue at all and it is not a CSS1 issue either. It's just a compatibility issue with what other browsers do (behavior) and/or with what is the default background-color (computed style) for select in other browsers. That's it.
 
> Your interpretation appears to suggest, 

Please do not interpret any further than what I am saying. There is nothing in the HTML 4 and CSS1 specifications that say or indicate how a <select> should behave once a item is selected or that says that default background-color of a select should be transparent.
*** Bug 363107 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 415875
So is anybody working on this bug?

Considering the number of duplicates (22 right now) that has been detected it should be fixed just to avoid more unnecessary bug reports.
Nils, do you realise that this bug has been open for the best part of 6 and a half years now...? :'(
Read the entire thread. It's got itself into a stalemate as no one can decide exactly what the spec is / means. In this case I think the aesthetics of the situation should prevail, oh and also 'cos every other browser on the planet applies the style in a sensible manner.
To reply to Gérard Talbot's comment from October 2006;

The current behaviour is not in violation of any specification, but only in the sense of "if they didn't put it in the spec then what we do is not wrong" - an engineering principle beloved by many programmers because it gets them out of trying to do "the right thing". 

The current implementation, although "not wrong", is certainly unsatisfactory by the standards of enough people that this bug has been reported 22 times and remains open after nearly 6.5 years.

The issues at hand:
1. Whether or not either the current or proposed behaviour implements all relevant spec
2. Whether or not either the current or proposed behaviour violates any relevant spec
3. What other browsers do (cross-compat)
4. Given the freedom to do what we want within spec, what users or developers expect
5. How much effort is involved in offering such enhanced functionality

Gérard has established - in no uncertain terms - that the current behaviour satisfies both 1 and 2. 

The proposed behaviour (of OPTION styles 'bubbling up' to SELECT style on option change) may or may not adhere to 1 and 2. It is not entirely clear from this thread. But I suspect that it does not, as it would break all kinds of things. Thus, that is not the correct fix.

Other browsers appear to treat SELECT as a container with an OPTION in it, and I suspect that this is the 'expected' behaviour from a user's natural point of view as well: it is common sense that SELECTs contain OPTIONs, and 1 OPTION is visible at all times. That's implicit (not explicit) in the HTML spec. To me and to others in this thread, 3 and 4 suggest we need change.

As for 5: if memory serves - as visual grep is failing to do - the part of the code which was responsible for this bug is or was once due for a rewrite, and that's why this was left dangling. It's been so many years that I could be imagining this though.

The astute follower of this thread will notice that some of the test cases now work much more closely as you'd expect they should (some of the early comments are now irrelevant). There are still cases where Gecko does not do what you would reasonably expect, though, such as this one:

<select>
<option style="font-size: 10px">test</option>
<option style="font-size: 20px">test</option>
<option style="font-size: 30px">test</option>
</select>

It is CLEARLY a bug that SOME of the Option styles are inherited by the SELECT when others are not.

I suspect that another 2, possibly 3 rounds of argument - and as many years - are probably required before this bug is resolved.

Alternatively, HTML5 may make this behaviour explicit. We shall see... see you all again in 2011.
John Keiser is assigned to this bug.

Nils, if you want a workaround, you can set dynamically the background-color of the select to the background-color of the selected option with javascript. This works for me and has been working for Telmo Amaral ... with just 2 lines of code:

objSelect.style.backgroundColor = objSelect.options[objSelect.selectedIndex].style.backgroundColor;
objSelect.style.color = objSelect.options[objSelect.selectedIndex].style.color;

Example:
http://www.gtalbot.org/DHTMLSection/AdvancedCSSButtons.html

"The only person who has any obligation to fix the bugs you want fixed is you."
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

The key in this bug is to support background-color: transparent for the select like hoju and others said, so that when the select is collapsed, the background-color of the selected option shines through. Opera 9.25, Opera 9.50, Konqueror 3.5.8 implement this and pass this testcase:

http://www.gtalbot.org/BugzillaSection/Bug79107.html

Adding [parity-opera]
Whiteboard: [parity-opera]
> 3. What other browsers do (cross-compat)

IE 6, IE 7 have a bug (reported for over a year now) with this:
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/BackgroundColorSelect.html
If the select is green, then it should not says that it's white (#fffff) but transparent.
Opera 9.25, Opera 9.50, Konqueror 3.5.8 behaviors, respective implementations is what, I believe, Mozilla should follow, should implement.

> 4. Given the freedom to do what we want within spec, what users or developers
expect

Implement background-color: transparent for the select (in particular when it is collapsed) as explained in comment #41 and #44. I assume we all agree, we all converge on this. I'll resummarize and point to a new URL, unless I hear loud objections. The current URL is not even working and not correct either.

> (...) remains open after nearly 6.5 years.
> 5. How much effort is involved in offering such enhanced functionality

"The only person who has any obligation to fix the bugs you want fixed is you."
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Ben, submit a patch and this bug will get resolved+fixed soon.
(In reply to comment #57)
> > 3. What other browsers do (cross-compat)
> 
> IE 6, IE 7 have a bug (reported for over a year now) with this:
> http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/BackgroundColorSelect.html
> If the select is green, then it should not says that it's white (#fffff) but
> transparent.
> Opera 9.25, Opera 9.50, Konqueror 3.5.8 behaviors, respective implementations
> is what, I believe, Mozilla should follow, should implement.

Perhaps I'm being particularly dense, but I do not understand:
A. why transparent is more correct than white
B. how this is relevant to (what I consider to be) the focus/spirit of this bug report

To explain further:
A. _If_ SELECT is a box (in the box-model sense), and for display purposes it contains a single OPTION, then the parent (SELECT) style is irrelevant when the displayed child has explicit styling that overrides it, because it is in front. Thus, when 'green' is selected, you should see a green background on the OPTION which is itself within the SELECT (who's background is now obscured.) The computed style of the select box itself would remain at whatever it was set before, from the point of view of CSS and JS. In this case, why should 'transparent' be prefered to 'white' for the SELECT when it is hidden under the selected OPTION anyway?

B. The main point of the bug in my eyes is that when you select an option, only the inner text of the option is copied to the select for display; but one would expect the entire styled box content to be copied for display. Worse, the SELECT appears to be prepared to contain the OPTION in a fully styled way, for example it is the correct size to contain the largest OPTION available, even though this never happens.

Therfore, I do not believe that the solution to the bug can possibly be as narrow in scope as you say it is.

> > 4. Given the freedom to do what we want within spec, what users or developers
> expect
> 
> Implement background-color: transparent for the select (in particular when it
> is collapsed) as explained in comment #41 and #44. I assume we all agree, we
> all converge on this. I'll resummarize and point to a new URL, unless I hear
> loud objections. The current URL is not even working and not correct either.
 
Please do.

> > (...) remains open after nearly 6.5 years.
> > 5. How much effort is involved in offering such enhanced functionality
> 
> "The only person who has any obligation to fix the bugs you want fixed is you."
> https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
> Ben, submit a patch and this bug will get resolved+fixed soon.

Whilst I appreciate the spirit of this (and I am certainly not one to _demand_ something for nothing :) - I, unfortunately, do not have the required skills to implement this myself. I contribute to other open source projects, but my C skills are pretty weak. 

My interest lies in trying to help with the clarity of this bug. I suspect that it has been open for so long because it is poorly understood, and I still think that it is poorly understood despite what you said in your last comment.

(In reply to comment #56)
> John Keiser is assigned to this bug.
> 
> Nils, if you want a workaround, you can set dynamically the background-color of
> the select to the background-color of the selected option with javascript. This
> works for me and has been working for Telmo Amaral ... with just 2 lines of
> code:

It's no problem doing it in JavaScript by itself, but the general feeling is that it is unnecessary work to be able to be consistent over different browsers to obtain the expected effect.

And - yes I did check the comments, and the opinion I have is that there will be more bug reports against this behavior in the future, so only that would be a reason to solve it.
Duplicate of this bug: 478628
Duplicate of this bug: 294423
Attached file Workaround
Here's a JavaScript work-around that attempts to apply all styles for the selected option element to its parent select element. The script is unobtrusive; using it requires just adding a simple:

<script type="text/javascript" src="listboxcolors.js"></script>

... to your HTML. The script is based (in part) on some examples provided earlier.

Also, developing this script lead me to a new bug: Bug 494507
Duplicate of this bug: 397468
QA Contact: vladimire → layout.form-controls
Summary: Styles assigned to OPTION elements aren't used for pull-down SELECT lists → Styles assigned to OPTION elements aren't used for pull-down SELECT lists (comboboxes)
Duplicate of this bug: 529940
Duplicate of this bug: 729938
blocking-b2g: 2.2r? → ---
Chrome, Safari and Opera do not implement this. In fact they don't seem to support styling of the options even when the dropdown is expanded. Seems like we should just wontfix this.
Assignee: john → nobody
Status: NEW → RESOLVED
Closed: 2 years ago
Keywords: compat
Resolution: --- → WONTFIX
Whiteboard: [parity-opera]
@Jonathan Watt: 

Chrome does show colored option elements in Selectboxes ... no idea where you got your informations.
Status: RESOLVED → REOPENED
Depends on: content-select
Resolution: WONTFIX → ---
I tested the attached testcases...on Mac. And in this case I apparently assumed that Chrome would be consistant about this across platforms. It is not. The testcases seem to work in Chrome on Windows.
OS: All → Windows
Whiteboard: [Chrome supports on Windows]
Duplicate of this bug: 1452579
and in chrome on linux
Duplicate of this bug: 1471238

This seems to work in Firefox 64.0.2 on Windows, but not 64.0 on Linux. Works in Edge and Chrome in Windows, and Chrome in Linux. Test codepen: https://codepen.io/Pointy/pen/YBqjxq

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