Last Comment Bug 40545 - (option-label) LABELs don't work for OPTIONs (<option label> in selects)
(option-label)
: LABELs don't work for OPTIONs (<option label> in selects)
Status: NEW
[p-ie/win][p-safari][p-opera] relnote...
: dev-doc-needed, html4, html5, testcase
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: -- normal with 34 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://www.robinlionheart.com/stds/ht...
: 46111 46799 84094 409948 545114 555493 626629 634964 839395 1174460 (view as bug list)
Depends on: 215083
Blocks: html4.01 robin's 104166
  Show dependency treegraph
 
Reported: 2000-05-24 23:22 PDT by ekrock's old account (dead)
Modified: 2016-06-18 16:02 PDT (History)
45 users (show)
roc: blocking1.9.1-
roc: wanted1.9.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Workaround for this problem, using CSS. (2.50 KB, text/html)
2001-10-26 08:18 PDT, Sascha Claus
no flags Details
Testcase (124 bytes, text/html)
2002-08-19 15:01 PDT, John Keiser (jkeiser)
no flags Details
HTML Example of how the label attribute is ignored even when the option element has no contents. (1.80 KB, text/html)
2004-11-03 10:50 PST, Matthew Raymond
no flags Details

Description ekrock's old account (dead) 2000-05-24 23:22:52 PDT
For FCS, LABELs on OPTIONs will be silently ignored. Opening as tracking bug for 
this issue, marking FUTURE, html4, and relnote.
Comment 1 ekrock's old account (dead) 2000-05-24 23:23:44 PDT
See bug 4050 for background explanation.
Comment 2 Hixie (not reading bugmail) 2000-07-21 14:44:26 PDT

*** This bug has been marked as a duplicate of 46111 ***
Comment 3 Hixie (not reading bugmail) 2000-07-21 14:46:02 PDT
*** Bug 46111 has been marked as a duplicate of this bug. ***
Comment 4 Hixie (not reading bugmail) 2000-07-21 14:46:29 PDT
Reopening. I dupped the bugs the wrong way. Terribly sorry for the spam.
Comment 5 Hixie (not reading bugmail) 2000-07-28 11:22:17 PDT
*** Bug 46799 has been marked as a duplicate of this bug. ***
Comment 6 Hixie (not reading bugmail) 2000-07-28 11:24:42 PDT
Just to make this easier to find in searches:

   <select>
   <optgroup>
   <option label="Short Label"> Long Label </option>
   The label attribute is not shown in option elements.

Hopefully we'll get less dups now. ;-)
Comment 7 bsharma 2000-09-26 17:49:40 PDT
Updating QA contact.
Comment 8 ekrock's old account (dead) 2001-01-24 03:07:32 PST
Nom. for nsbeta1 consideration. It would be nice to get this implemented and
enable the use of LABELs by developers in their content.
Comment 9 Vladimir Ermakov 2001-03-06 16:55:05 PST
QA Contact Update
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2001-06-05 04:20:48 PDT
*** Bug 84094 has been marked as a duplicate of this bug. ***
Comment 11 Skewer 2001-06-06 11:42:34 PDT
Here's the W3C HTML 4.01 recommendation that reqires this:

http://www.w3.org/TR/html401/interact/forms.html#h-17.6

label = text [CS]
This attribute allows authors to specify a shorter label for an option than the
content of the OPTION element. When specified, user agents should use the value
of this attribute rather than the content of the OPTION element as the option label.

This really only makes sense within an OPTGROUP, but the recommendation states
that the label value should always be used.

The testcase from bug 84094 demonstrates the way the LABEL property might be
used and the consequences of not supporting it:

Attachment 37117 [details] (I wonder if this makes a link like bug 84094 does...)
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=37117
Comment 12 Skewer 2001-07-01 15:10:37 PDT
M0.9 definitely won't happen. Changing keyword to next available milestone.
Comment 13 Sascha Claus 2001-10-26 08:18:09 PDT
Workaround for this problem, using CSS.

The content of the label attribute is displayed via ":before" pseudo-class and
the content of <option> is invisible.
See attachment.
(stolen from image handling at <http://www.subotnik.net/stylesheets/lynx.css>)
Comment 14 Sascha Claus 2001-10-26 08:18:28 PDT
Created attachment 55236 [details]
Workaround for this problem, using CSS.
Comment 15 Nicolás Lichtmaier 2002-07-30 18:08:54 PDT
I'll try to fix this, I've reading code and I think I know exactly what yo do,
but I want to propose something:

Why not using the long text when the combo is not in "dropped down" state.
Rationale: When the combo is collapsed, the optgroups aren't ther and there's no
context for the selection. Example:

Broser: Netscape
          4.x
        ##6.x############
        Explorer
          4.x
          5.x
          6.x

... when collapsed would look like this:

Browser:  6.x

I propose using the long text, so we show:

Browser: Netscape 6.x
Comment 16 John Keiser (jkeiser) 2002-08-19 15:01:31 PDT
Created attachment 95912 [details]
Testcase

I don't think we should show a different label on a thing for an optgroup.  The
spec says use label to show the option, we should use label to show the option.


Let's take the possibility of doing "optgroupname - label" as the label
elsewhere :)
Comment 17 Anne (:annevk) 2004-08-28 14:05:19 PDT
Once bug 215083 is fixed this can be supported with an easy change in forms.css:

  option[label]{
    content:attr(label);
  }
Comment 18 Tom Pike 2004-11-03 08:29:28 PST
(In reply to comment #16)
> Let's take the possibility of doing "optgroupname - label" as the label
> elsewhere :)

The suggestion was not to use "optgroupname - label" as the label, but to use
the "Long label" (as per comment #6) when the combo is not "dropped-down", but
use the "Short label" in the drop-down itself.

This is exactly like the behaviour suggested in
http://www.w3.org/TR/REC-html40/interact/forms.html#idx-menu-4

It can be noted that neither Opera nor Internet Explorer support label= on
<option> elements either.
Comment 19 Brian Lalonde 2004-11-03 10:03:05 PST
MacIE gets it right. http://webcoder.info/reference/dereliction.html
Comment 20 Matthew Raymond 2004-11-03 10:50:57 PST
Created attachment 164427 [details]
HTML Example of how the label attribute is ignored even when the option element has no contents.

Apparently, Mozilla ignores the label attribute even when the option element
has no content. Mozilla 1.7.2, IE 6.0 and Opera 7.51 all render option elements
with labels but no content as blank lines.
Comment 21 Brian Lalonde 2006-01-31 20:48:02 PST
IE7 beta 2 has fixed this. 

2000-05-24? Is this really NEW?

Also, the URL should be http://www.robinlionheart.com/stds/html4/forms#optgroup .
Comment 22 Hanspeter Niederstrasser 2006-02-01 17:42:33 PST
If IE7beta indeed has this, I'm asking for blocking for 1.8.1 for feature parity since Safari and Konq also have it as well.
Comment 23 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-04-18 10:17:37 PDT
Clearing blocking: we wouldn't hold 1.8.1 for this, but we would certainly consider a good patch for it.
Comment 24 Robin Lionheart 2006-11-25 18:21:22 PST
IE/Win 7.0 final supports them.

Adding whiteboard parity tags for IE/Win and for Safari (per comment #22).
Comment 25 Gérard Talbot 2007-09-04 20:29:36 PDT
Opera 9.50a1 build 9500 supports label for option. Adding whiteboard parity tag for Opera and voting for this bug :)
Comment 26 Kir Kolyshkin 2007-12-27 03:58:13 PST
*** Bug 409948 has been marked as a duplicate of this bug. ***
Comment 27 Gérard Talbot 2008-04-12 19:31:36 PDT
Another testcase:

http://www.mozilla.org/newlayout/samples/test8.html

and search for "Option Label Test" at the bottom-end of the page

Adding testcase keyword
Comment 28 Mike Beltzner [:beltzner, not reading bugmail] 2008-05-16 00:05:54 PDT
We didn't relnote this in Firefox 2, and we're not going to start with Firefox 3. Removing keyword.
Comment 29 Mariusz Pękala 2009-10-22 08:13:57 PDT
This bug has just hit me in Firefox 3.5.2.
(Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20091019 Gentoo Firefox/3.5.2)

I need some encouragement. Is this bug so hard to fix, that I should not even try to fix it? I have never messed with Firefox sources so far, that's why I'm asking.
Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2009-10-22 08:38:32 PDT
I depends on how you go about fixing it.  If you take the approach from comment 17, then it might be a good bit of work (e.g. having to fix bug 215083 first).  If you do something special to <option> you might be able to get away with less work, maybe.  Depends on how much performance matters and how careful you need to be about dynamic changes to labels.

I suspect that this can be fixed with some xbl applied to option[label], though the performance is likely to be suboptimal.  The benefit of that, of course, is that that approach doesn't even need any browser changes: it can be part of the website, at least as an experiment.
Comment 31 Robert Longson 2010-02-09 07:12:22 PST
*** Bug 545114 has been marked as a duplicate of this bug. ***
Comment 32 zug_treno 2010-03-31 08:04:10 PDT
*** Bug 555493 has been marked as a duplicate of this bug. ***
Comment 33 Robert Longson 2011-01-18 06:56:56 PST
*** Bug 626629 has been marked as a duplicate of this bug. ***
Comment 34 Boris Zbarsky [:bz] (still a bit busy) 2011-02-17 11:01:10 PST
*** Bug 634964 has been marked as a duplicate of this bug. ***
Comment 35 Martin Suchan 2011-05-12 01:52:52 PDT Comment hidden (spam)
Comment 36 j.j. 2011-11-21 23:30:59 PST Comment hidden (spam)
Comment 37 roadt 2011-12-16 19:02:36 PST Comment hidden (spam)
Comment 38 Martin Suchan 2012-08-21 07:11:17 PDT Comment hidden (spam)
Comment 39 j.j. 2012-08-26 01:56:40 PDT Comment hidden (spam)
Comment 40 Boris Zbarsky [:bz] (still a bit busy) 2013-02-08 01:45:09 PST
*** Bug 839395 has been marked as a duplicate of this bug. ***
Comment 41 Giovanni Sferro [:agi] 2015-06-14 13:21:26 PDT
*** Bug 1174460 has been marked as a duplicate of this bug. ***
Comment 42 Tom Soon 2015-06-14 19:01:00 PDT
This comment is for those who assigned this bug to be ignored or duplicated. I do appreciate your attention. 

I just like to make sure that the position of ignoring label attribute for OPTION object is still valid in HTML5 from the Firefox development perspective. All other browsers, Safari, Chrome, IE11, Opera, do support this label option. Firefox is the only one not supporting it. 

What is the right way to show the label of OPTION in the selection list of a SELECT object? Could you please provide us a solution to address the problem?
Comment 43 Tom Soon 2015-06-18 09:52:49 PDT
I've posted similar comments and questions for Bug 1174460, just like to re-enter the comments here to call more attention about the fix of this bug:

1. Why folks here consider the CSS tweak in Bug 215083 as the fix of missing support for the label attribute of OPTION in the past 15 years? CSS is supposed to be a specification facility for the presentation of the elements in a webpage. Choosing a specific content from the data structures behind a webpage is a behavior which should be a totally different concept in programming. Thus, the fix of this bug should not depend on a CSS enhancement. 

2. In debugging Bug 1174460, I found no issue in Javascript, meaning Javascript execution behind Firefox supports both label and value attributes for OPTION, at least that's what presented in the Firefox debugger. However, Firefox doesn't display the selected item and doesn't present the labels in the pull-down menu correctly as all other major browsers do. I agree fixing problems in OPTION is necessary. However, just by reasoning, SELECT many also require some attention as well. I'd like to call your attention about whether or not just assigning the fix to Bug 40545, which focuses on fixing the label support issue for OPTION, will suffice the needed fixes for the display problems of SELECT. Given the principle of one Bug report for one bug, should there be another Bug report addressing the SELECT object which is the origin of the reported problems?

Also I thank whoever changed the status on this bug to new so it is open for contributors to work on it again. Many folks discussed about this bug for so many years. It seems to be a very basic feature that Firefox should have had since day one. Many folks like me are very eager to see the SELECT bug is addressed as soon as possible.

Many thanks,
Comment 44 Patrick Dark 2015-06-19 19:04:38 PDT
(In reply to Tom Soon from comment #43)
> 1. Why folks here consider the CSS tweak in Bug 215083 as the fix of missing
> support for the label attribute of OPTION in the past 15 years? CSS is
> supposed to be a specification facility for the presentation of the elements
> in a webpage. Choosing a specific content from the data structures behind a
> webpage is a behavior which should be a totally different concept in
> programming. Thus, the fix of this bug should not depend on a CSS
> enhancement.

The CSS3 |content| property is a valid fix for this bug. The |label| attribute is supposed to, essentially, represent an equivalent, abbreviated version of |option| elements' content for use with an |optgroup| element's label. This isn't evident from the WHATWG HTML spec, which doesn't provide a single example of usage, but there are examples in the HTML 4.01 spec that demonstrate how the feature is supposed to be used: "http://www.w3.org/TR/html401/interact/forms.html#adef-label-OPTION". Given how narrow the use case demonstrated in those examples is, it's no surprise that Mozilla has managed to get away without fixing this bug for so long.

That said, bug 215083 is technically invalid right now given that the current, development draft of the CSS3 Generated and Replaced Content spec is labeled "Not Ready for Implementation". See "http://dev.w3.org/csswg/css-content-3/". It'd probably be easier to implement a direct fix for this bug anyway.

(In reply to Tom Soon from comment #42)
> What is the right way to show the label of OPTION in the selection list of a
> SELECT object? Could you please provide us a solution to address the problem?

Assuming usage as described in the HTML 4.01 spec, your best bet would be to use JavaScript to replace the |textContent| of |option| elements with the respective |label| attribute values until the form is ready for submission, at which point you'd change the |textContent| back to ensure that the server gets the correct, longform option values. If you're using |value| attributes, you don't even need to bother changing the |textContent| back. In the unlikely event that JavaScript is disabled, the longform |option| element text will be used, resulting in no semantic loss.

Aside from the extra code and effort, the only downside I can see to this workaround is that your site could look messed up if JavaScript is disabled and your layout relies on the |option| elements having the abbreviated (read: short in width) |label| attribute text to display properly.
Comment 45 Gérard Talbot 2015-06-20 09:35:58 PDT
(In reply to Tom Soon from comment #42)
> All other browsers, Safari, Chrome, IE11, Opera, do support
> this label option.

This is not entirely true. Chrome 43 and Chrome 45 fail the "Option Label Test" at the bottom-end of the page

http://www.mozilla.org/newlayout/samples/test8.html


----------


(In reply to Patrick Garies from comment #44)

> The CSS3 |content| property is a valid fix for this bug. The |label|
> attribute is supposed to, essentially, represent an equivalent, abbreviated
> version of |option| elements' content for use with an |optgroup| element's
> label. 

The label attribute for an <option> element does not require an <optgroup> element's label. The <option> attribute label and the <optgroup> attribute label are independent from each other; those 2 labels are not interdependent.

See the "Option Label Test" at the bottom-end of the page

http://www.mozilla.org/newlayout/samples/test8.html

or see comment #6 in this bug report.

> This isn't evident from the WHATWG HTML spec, which doesn't provide a
> single example of usage, 

I agree: it isn't evident.

> but there are examples in the HTML 4.01 spec that
> demonstrate how the feature is supposed to be used:
> "http://www.w3.org/TR/html401/interact/forms.html#adef-label-OPTION". 

The ComOS example in HTML 4.01 spec has a small error in it:

<OPTION selected label="none" value="none">None</OPTION>

should render 

none and not None. Also, such label is an inappropriate way of using the label attribute.
Comment 46 Patrick Dark 2015-06-20 12:15:19 PDT
(In reply to Gérard Talbot from comment #45)
> (In reply to Tom Soon from comment #42)
> > All other browsers, Safari, Chrome, IE11, Opera, do support
> > this label option.
> 
> This is not entirely true. Chrome 43 and Chrome 45 fail the "Option Label
> Test" at the bottom-end of the page
> 
> http://www.mozilla.org/newlayout/samples/test8.html

I was going to attach a testcase for that to this bug. Then I noted that that failure appears to only occur in Chrome's (Chrome 43's) quirks mode (due to a missing |DOCTYPE| declaration), so it doesn't seem necessary.

(In reply to Gérard Talbot from comment #45)
> (In reply to Patrick Garies from comment #44)
> 
> > The CSS3 |content| property is a valid fix for this bug. The |label|
> > attribute is supposed to, essentially, represent an equivalent, abbreviated
> > version of |option| elements' content for use with an |optgroup| element's
> > label. 
> 
> The label attribute for an <option> element does not require an <optgroup>
> element's label. The <option> attribute label and the <optgroup> attribute
> label are independent from each other; those 2 labels are not interdependent.

You're right. There is also the use case for simply wanting to submit the longer version of an |option| element's value (i.e., the |textContent|) instead of the shortened |label| attribute-equivalent presented to users and this doesn't require an |optgroup| element.

That usage seems like it'd be even more unusual than the |optgroup| scenario though; who shows a user a shortened version of text, then wants a longer version of the same text submitted to the server? There's no utility over using the |value| attribute unless one thinks alternative viewers like search engines or maybe speech synthesizers are going to use the longform information. The |optgroup| scenario at least allows use of redundant display values with different meanings — as shown in the HTML 4.01 examples linked in comment 44 — with utility relevant to the average (sighted) user. That's why I left mention of the second scenario out.

My point was that this is a presentational feature, making a CSS enhancement a valid fix, and that people spamming this bug with "please fix" might not even need the fix because they're incorrectly using |<option label="x"/>| as a substitute for |<option>x</option>| or |<option label="x">y</option>| as a substitute for |<option value="y">x</option>|.

(In reply to Gérard Talbot from comment #45)
> > This isn't evident from the WHATWG HTML spec, which doesn't provide a
> > single example of usage, 
> 
> I agree: it isn't evident.

I'll try to get around to submitting a bug report on the HTML spec asking them to incorporate the HTML 4.01 examples and describe how this attribute should be used.

Frankly, I think the design of this feature is poor and should be changed, but I doubt anyone can be convinced considering what little relevance this feature has. It'd make more sense if the |label| attribute were implemented with another name like |abbr| as is used in the HTML 4.01 spec for tables so that authors can tell that it's not just a redundant mechanism for specifying an |option| element's display value. See "http://www.w3.org/TR/html401/struct/tables.html#adef-abbr". But, I digress…

(In reply to Gérard Talbot from comment #45)
> The ComOS example in HTML 4.01 spec has a small error in it:
> 
> <OPTION selected label="none" value="none">None</OPTION>
> 
> should render 
> 
> none and not None. Also, such label is an inappropriate way of using the
> label attribute.

Good catch.
Comment 47 Gérard Talbot 2015-06-20 17:06:57 PDT
(In reply to Patrick Garies from comment #46)

> who shows a user a shortened version of text, then wants a longer
> version of the same text submitted to the server? 

Maybe the webpage author does not want the select to be unneedlessly too wide?

Eg.

<p>Your preferred browser: <select name="prefBrowser" size="1">
    <option>Choose</option>
    <option label="IE10">Internet Explorer 10</option>
    <option label="IE11" value="Internet Explorer 11"></option>
    <option>Firefox</option>
  </select>
</p>

We are in an era where a lot of acronyms and abbreviations are used and understood on the web.

> My point was that this is a presentational feature, making a CSS enhancement
> a valid fix, and that people spamming this bug with "please fix" might not
> even need the fix because they're incorrectly using |<option label="x"/>| as
> a substitute for |<option>x</option>| or |<option label="x">y</option>| as a
> substitute for |<option value="y">x</option>|.

I agree with you. A lot of people may be (or could be) incorrectly using the label attribute once it gets implemented.

> I'll try to get around to submitting a bug report on the HTML spec asking
> them to incorporate the HTML 4.01 examples and describe how this attribute
> should be used.

A good realistical example (with appropriate usage of label) is needed.

> Frankly, I think the design of this feature is poor and should be changed,
> but I doubt anyone can be convinced considering what little relevance this
> feature has. It'd make more sense if the |label| attribute were implemented
> with another name like |abbr| as is used in the HTML 4.01 spec for tables so
> that authors can tell that it's not just a redundant mechanism for
> specifying an |option| element's display value. See
> "http://www.w3.org/TR/html401/struct/tables.html#adef-abbr". But, I digress…

I agree with you: abbr would be more semantic, more significant.
Comment 48 Brian Lalonde 2015-06-21 10:54:40 PDT
Keep in mind option values often do not match their displayed text, as when a numeric key is used.

Is clarification really needed, if judgements of usage correctness and a more suitable attribute name are already being made here?

A good example can be found at http://www.robinlionheart.com/stds/html4/forms.html#optgroup , and should probably just be added to the standard as is.

It's pretty clear that the only point to creating a second way to specify label text (which overrides the old way) was to support a transitional period during which support for optgroup was being implemented. There's no other reason to allow two ways to specify the same thing (though there's an argument to be made for the long version being displayed when a non-multiple select is collapsed/closed/folded, outside the context of a displayed optgroup label). This would have allowed older browsers to render the full text in a flat list, while newer ones could provide a hierarchy without so much redundancy. It was a good migration plan, poorly communicated in the spec, but single-handedly and  irredeemably screwed up by Mozilla crossing the chasm in two leaps.
Comment 49 Gérard Talbot 2016-06-18 16:02:05 PDT
Referring to comment 45

[...]mozilla.org/newlayout/samples/test8.html

is now at

http://www-archive.mozilla.org/newlayout/samples/test8.html

Chrome 51 and 53 still fail the "Option Label Test" at the bottom-end of the page

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