Closed Bug 4050 Opened 26 years ago Closed 24 years ago

Both <option label> AND <option> content are displayed

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
Other
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: dbaron, Assigned: rods)

References

(
URL
)

Details

(Keywords: css3, html4, testcase, Whiteboard: [nsbeta2+][6/15])

Attachments

(3 files)

simplified test case (as attachment, for convenience)
(deleted), text/html
Details
Testcase including nested OPTGROUP and OPTION LABEL
(deleted), text/html
Details
simple example
(deleted), text/html
Details
I think the add() and remove() methods of HTMLSelectElement aren't working. I'm not sure I'm doing everything right, but it seems they should be working. I'm more confident about the remove() problems than the add() problems. The code is currently at the above URL, but I'm pasting it here too in case it changes. The debugging code (some of which is commented out with //D) shows that everything else is working fine (mainly that I have the right select element and the option element is being created). The problems are in RemoveAll() and AddIfUnique(). FILE altsel_nglay_dom.html: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC- html40/strict.dtd"> <HTML> <HEAD> <TITLE>Alternate Stylesheet Selector Demonstration</TITLE> <LINK REL="stylesheet" HREF="http://www.w3.org/StyleSheets/Core/Ultramarine" TITLE="Ultramarine" TYPE="text/css"> <LINK rel="alternate stylesheet" HREF="http://www.w3.org/StyleSheets/Core/Steely" TITLE="Steely" TYPE="text/css"> <LINK rel="alternate stylesheet" HREF="http://www.w3.org/StyleSheets/Core/Oldstyle" TITLE="Oldstyle" TYPE="text/css"> <META http-equiv="Content-Script-Type" content="text/javascript"> <SCRIPT SRC="altsel_dom.js" TYPE="text/javascript"></SCRIPT> </HEAD> <BODY onLoad="UpdateSSList(document.getElementById('ssSelector'))"> <!-- can document be omitted here? --> <h1>Alternate Stylesheet Selector Demo</h1> <DIV> <FORM METHOD="GET" ACTION="dummy.cgi"> Selected stylesheet: <SELECT ID="ssSelector" onChange="selectStyleSheet(this)"> <OPTION SELECTED>This stylesheet selector requires JavaScript.</OPTION> </SELECT> <INPUT TYPE="button" onClick="UpdateSSList(document.getElementById ('ssSelector'))" value="Update"> <!-- can document be omitted here ? --> </FORM> </DIV> </BODY> </HTML> FILE altsel_dom.js: // copyright (c) 1999 L. David Baron // based on original by Chris Wilson function writeout (selector ) { //debug function var j; for (j=0; j<selector.length; j++) { window.alert("selectedIndex is " + selector.selectedIndex); window.alert("Option " + j + " has text=" + selector.options[j].text + ", value=" + selector.options[j].value + ", label=" + selector.options[j].label); } } function strISSContains ( str, word ) { // case-insensitive search for word as one of the space separated values // within str. // If word contains spaces, you won't get a match var list, i; list = str.toLowerCase().split(" "); word = word.toLowerCase(); for ( i = 0 ; i < list.length ; i++ ) { // D window.alert("comparing " + word + " with " + list [i]); // D if (word == list[i]) return 1; } return 0; } function selectStyleSheet( selector ) { var i; var title = selector.options[ selector.selectedIndex ].value; linkElements = document.getElementsByTagName("LINK"); for ( i = 0; i < linkElements.length; i++ ) { if ( strISSContains(linkElements.title, "stylesheet")) { if ( linkElements[ i ].title == title ) { linkElements[ i ].disabled = false; } else if ( linkElements[ i ].title != "" ) { linkElements[ i ].disabled = true; } } } } function UpdateSSList( selector ) { function RemoveAll () { var j; for (j=0; j < selector.length; j++ ) { writeout(selector); window.alert("Removing option " + j); selector.remove(j); writeout(selector); } } function AddIfUnique( ssLink ) { var i, opt; for ( i = 0; i < selector.length; i++ ) { if ( selector.options[i].text == ssLink.title ) return; } //D window.alert("adding " + ssLink.title); opt = document.createElement("OPTION"); // must be uppercase // opt.text = ssLink.title; // THIS (opt.text) IS READONLY opt.label = ssLink.title; opt.value = ssLink.title; // could use document.createTextNode and opt.appendChild ?? //D window.alert("ssLink.title=" + ssLink.title); //D window.alert("opt.label=" + opt.label); writeout(selector); // selector.add( opt , selector.options[ selector.length - 1] ); selector.add( opt , selector.lastChild ); if ( ! ssLink.disabled ) // only one unique title may be enabled selector.selectedIndex = opt.index; } function AddNone() { var opt; opt = document.createElement("OPTION"); // must be uppercase opt.text = "--NONE--"; selector.add( opt , null ); selector.selectedIndex = 0; } var j, linkElements; // XXX NEEDED selector.options.length = 0; // nonstandard RemoveAll(); AddNone(); linkElements = document.getElementsByTagName("LINK"); for ( j = 0; j < linkElements.length; j++ ) { // nonstandard ... if ( ( linkElements[ j ].title != "" ) && (strISSContains(linkElements [j].rel, "stylesheet")) ) { AddIfUnique( linkElements[j] ); //D window.alert("adding " + linkElements[j].title); } } }
QA Contact: 4015 → 4078
Further test case at http://www.fas.harvard.edu/~dbaron/tests/nglayout/select This test page and the one above show the problems described in 3950, so you can only hit the buttons once.
Assignee: vidur → pollmann
This ones for you, Eric. Let me know if you need any help.
Status: NEW → ASSIGNED
Target Milestone: M7
See bug 4479
Assignee: pollmann → vidur
Status: ASSIGNED → NEW
Priority: P3 → P2
Summary: HTMLSelectElement add and remove methods not working → CRASH: HTMLSelectElement add method not working
Target Milestone: M7
This page is a crasher. In nsHTMLSelectElement::Add ya' check to see if aBefore is null. If it is null, it is then immediately dereferenced it to get at it's parent, which of course causes a crash. :) Can you take a look since it's your baby? Thanks!
Status: NEW → ASSIGNED
Target Milestone: M6
Doh! The test should be (nsnull == aBefore), not !-. I'll make a case for this to go into M6.
Assignee: vidur → pollmann
Status: ASSIGNED → NEW
Checked in a fix so that Add() doesn't crash anymore. Back to you, Eric, to get the rest of the test to work.
Status: NEW → ASSIGNED
I change the demo slightly so that is uses: opt = new Option(ssLink.title, ssLink.title) instead of: opt=document.createElement("OPTION"); opt.label=ssLink.title; opt.value=ssLink.title; And it seems to work okay (aside from bug 3322 making it look broken) I'm looking into why setting value with opt.value = xxx doesn't seem to work.
Priority: P2 → P3
Summary: CRASH: HTMLSelectElement add method not working → Option label attribute not used
Target Milestone: M6 → M7
Did I say opt.value? I meant opt.label. We're not checking the label attribute when adding an option to the widget, just the text. I'll mark this M7.
I think you should only support label if you support OPTGROUPS. Do you support OPTGROUPS? (Or something like that...) Note that the script may be wrong. It was my first attempt at doing anything with the DOM. I now know the correct way to change/create the content of the Option element, which is probably the better way to do this.
Summary: Option label attribute not used → Option label attribute not used: GFX Selects
Optgroups are currently supported (using indention) in GFX rendered selects, but not native selects. This could change. I agree with what you said. The example in the spec makes this more clear - using label while not supporting optgroups might lead to incorrect rendering of selects with optgroups in them. However, the argument above is weakened by the definition of the label attribute of an option, which makes no provision for whether to change the rendering if the option is in an optgroup or not: 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.
I think the assumption in that statement is that one is supporting OPTGROUPs. This was added to HTML 4.0 so that HTML 4.0 browsers will use the shorter labels, since they support OPTGROUPs. The spec didn't explain what to do about partial support. At least that's the way I see it...
*** Bug 3325 has been marked as a duplicate of this bug. ***
Another test case from 4050: <form action="mailto:Kligor.T@gee.whiz.com"> <select> <option label="Apple">Apfel <option label="Pear">Birne <option label="Quince">Quitte </select> </form> "I would expect the user agent / browser to display the English words, but instead you just get the German translations."
Redistributing bugs...
Whiteboard: [TESTCASE] option label attribute not implemented
Overview Description: if you have <OPTION label="xxx">yyy, yyy is displayed in the pull-down, not xxx. If yyy is empty, consequently nothing is displayed in the pull-down. Steps to Reproduce: 1) Load the attachment (id=813) 2) you see a pull down menu with three entries Actual Results: the three entries are X, Y and Z Expected Results: the three entries should be A, B, and C, as these are the label attributes of the <OPTION> tags. Build Date & Platform Bug Found: M7 & 1999071108 build (Win32) Additional information: label attribute is completely ignored. <OPTION label="xxx"></OPTION> is rendered as empty entry.
FWIW, I would tend to go with the train of thought that says that when we support OPTGROUP (i.e., with GFX widgets) then we should use the label attribute for the caption, and when we don't (i.e., native widgets) then we should use the content of the OPTION elements. There is an OPTGROUP test case here: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/optgroup.shtml Note that if we are in drop-down mode, we should always use the long form (content of the OPTION element) as the content of the combo box's edit box. See the example in the spec: http://www.w3.org/TR/REC-html40/images/optgroup_exmpl.gif The reasoning behind this is that the content of the OPTION element contains the equivalent of the label of the OPTGROUP _and_ the label of the OPTION.
Assignee: pollmann → rods
Status: ASSIGNED → NEW
I am resigning this to me, I have a fix for it.
Status: NEW → ASSIGNED
Fixed - Using generated content. If someone uses both a label and the content you get both and they are appended - So I am leaving this open. We need some CSS 3 functionality to fix this.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Forgot to mark fix - if this isn't then attach a SIMPLE test case.
Status: RESOLVED → REOPENED
Summary: Option label attribute not used: GFX Selects → Both <option label> AND <option> content are displayed
Whiteboard: [TESTCASE] option label attribute not implemented → [TESTCASE]
rods: You yourself said that you were going to leave this bug open because it was not fixed -- we are currently showing both the 'label' attribute and the <option> element content. We cannot ship as currently implemented. Reopening. Here is a simple test case: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/optgroup-simple.html
Yes, you are right, it needs to be reopened.
Resolution: FIXED → ---
Target Milestone: M10 → M11
Clearing FIXED resolution due to reopen.
Changing to M12
Target Milestone: M11 → M12
Changing to M12
Summary: Both <option label> AND <option> content are displayed → {css3} Both <option label> AND <option> content are displayed
Since we are pending on CSS3 functionality (namely, 'content' everywhere) I am marking this {css3}. However, we need to set a dependency. Is there an RFE covering CSS3's proposed extension to the 'content' property?
*** Bug 16745 has been marked as a duplicate of this bug. ***
Target Milestone: M12 → M14
changed to M14
QA Contact: phillip → gerardok
moving to M15
Keywords: css3
*** Bug 24130 has been marked as a duplicate of this bug. ***
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
*** Bug 26216 has been marked as a duplicate of this bug. ***
Summary: {css3} Both <option label> AND <option> content are displayed → Both <option label> AND <option> content are displayed
Whiteboard: [TESTCASE]
mass-move to M16
Target Milestone: M15 → M16
changing milestone to M17 and component to form controls
Component: DOM Level 1 → HTML Form Controls
Target Milestone: M16 → M17
moving to M20
Target Milestone: M17 → M20
Please correct me if I misunderstand: the net net is that if we don't fix this bug, in effect, the LABEL attribute on OPTGROUP won't be supported for FCS, and content developers will have to put what they want displayed into the content of the tag. Obviously, this would be unfortunate. However, if content developers had alternate text they would *prefer* to be displayed, they could go ahead and put that in the LABEL. Moz/N6 FCS would ignore the LABEL attribute value. But when this bug was fixed in a subsequent point release, that problem would disappear. Ian, could you explain why you marked this css3 rather than html4?
We HAVE to fix this if we support OPTGROUPs. The "label" attribute and the OPTGROUP element go hand in hand; support for one but not the other would be a serious pain in the neck for content developers. And it is marked HTML4: that's what the bug 7954 dependency is. Adding html4 keyword (which didn't exist last time I visited this bug).
Keywords: html4
I don't understand ekrock's comment, but it's really pretty simple. Take markup like: <optgroup label="Netscape"> <option label="4.x">Netscape 4.x</option> <option label="3.x">Netscape 3.x</option> </optgroup> Browsers which don't recognize the optgroup element and label attribute would just use the contents of the option tags. The list box would read: Netscape 4.x Netscape 3.x Browsers that understand optgroup and the label attribute could render the list box more nicely as: -Netscape- 4.x 3.x Both would be fine. But what Mozilla is doing now, rendering both the label attribute -and- the option tag contents, is right out: -Netscape- 4.xNetscape 4.x 3.xNetscape 3.x The net effect if we don't fix this is that properly written pages will look just plain wrong. Not fixing this isn't reasonable. If for some reason this is too complicated, then perhaps Mozilla could ignore the label attribute entirely, and degrade gracefully to the first example above.
non, no, no. This bug is for whenyou have an option specified as: <OPTION label="mylabel" value="myvalue">mycontent</option> The option would display as: "mylabelmyoption" The issue is, we use generated content for displaying the contents of the label attr when it exists. The problem with this bug is when an author specifies BOTH the label and some content (between the the start/end tags) both are displayed. Why HTML 4.x specifies a label for options is beyond me because it is redudant. I keep pushing this bug off because it is really really hard to fix and the pay-off is sooooooo small. Label
Status: REOPENED → ASSIGNED
Attached file simple example (deleted) —
Note the additional issue that line layout is not measuring the generated content plus the original content correctly. This used to work. That is why the horizontal scrollbar is appearing.
The easy way to fix it is to remove the generated content bit that shows the label, and not support label at all. That's better than doing what you currently do, since it won't break pages.
> Why HTML 4.x specifies a label for options is beyond me because it is redudant. The HTML 4 specification reads "When rendering a menu choice, user agents should use the value of the label attribute of the OPTION element as the choice. If this attribute is not specified, user agents should use the contents of the OPTION element." It seems to me that the intention is for user agents that support earlier versions of HTML continue to display the contents of the OPTION element, while HTML 4.0 compliant user agents (which presumably render OPTGROUP) can display a less verbose label="..." attribute instead.
OK, thanks to all for explaining to me the meaning of this bug. Clearly displaying both the label and the content is wrong (and worse, makes it difficult for content developers to use label at all in their content so long as browsers with this bug exist in the market--this is a classic example of a situation where the presence of a bug in a given browser would render that standard feature virtually unusable for everyone). For FCS, we must clearly do one of the following: 1) (preferable) per the spec, use label if it exists, and content if there is no label 2) (if we don't have the development cycles to do #1) not support label and document this as a known bug in the release notes; given engineering's LOE assessment of this as "really really hard," this is likely what we'll have to accept Nominating nsbeta2 6/1-. If it doesn't make nsbeta2, it's nsbeta3 stop ship.
Keywords: nsbeta2
I can turn off the part that makes label work with a simple change to html.css
I think that should be done until you can make LABEL and OPTGROUP work correctly.
If you turn off LABEL support you really should turn off OPTGROUP support as well. Otherwise the forms end up looking only a little less silly than now: -Netscape- (optgroup but not label) Netscape 4.x Netscape 3.x ...instead of: -Netscape- (optgroup and label) 4.x 3.x ...or just: Netscape 4.x (neither optgroup nor label) Netscape 3.x
For once, I disagree 100% with Ian. ;-> Here's why: it's true that in an ideal world it would look like this: -Netscape- (optgroup with concise label) 4.x 3.x ... but it seems that we're not going to get label in, so that's out. Then the question is: "Given that, how can we provide the closest adherence to the intended functionality and enable web designers to use as much of the intended functionality as possible?" It's true that having -Netscape- (for example) as the optgroup divider and also having the same non-abbreviated text in the option is less than ideal, but at least it allows the content developer to (if he or she wishes) structure long option lists into logical groups. Maybe the text of those groups doesn't look quite as concise as we'd wish, but at least the logical and visual grouping is preserved, and web designers can (if they wish) even put the LABELs they'd really like into the content, so that when this bug is fixed, it will work precisely as desired on newer versions. -Netscape- (optgroup but not label) Netscape 4.x Netscape 3.x If we restrict designers to using neither label nor optgroups, we've denied them both the concise labels *and* (unnecessarily) the ability to create visiual, logical groupings, and have limited the first release to flat, unstructured lists, holding back the increasing structuring of content on the web. Netscape 4.x (neither optgroup nor label) Netscape 3.x My take: (1) it sounds like full support for option label is too hard for FCS, alas, but (2) we can easily ignore the option label and display the content only, so we should do that, and (3) we can preserve the ability (which is already working in the code) to structure the lists into groups.
*ponder* Actually, yes, you're right (Eric). Providing the grouping of OPTGROUP is worth the minor inconveniance of redundancy in the labelling. So as David said, we should, for now, remove the bit in html.css which displays the label. We can revisit this post FCS. That makes it a very easy fix, BTW, and therefore easy to land by nsbeta2...
OK, rods, it's unanimous: please go forward with your proposed change. Thx!
I don't understand. I can turn off labels for options and leave labels on for optgroups and everything should be fine. It just that labels won't work for options.
Right, please do exactly that, rods. I've opened bug 40545, marked FUTURE, to track the known bug this will create of LABELs not being implemented for OPTIONs. Thanks!
Putting on [nsbeta2+][6/15] radar.
Whiteboard: [nsbeta2+][6/15]
Target Milestone: M20 → M16
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
VERIFIED on Win2K. This has indeed been fixed for a while now.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: