Closed Bug 4050 Opened 25 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)
182 bytes, text/html
Details
Testcase including nested OPTGROUP and OPTION LABEL
2.08 KB, text/html
Details
simple example
330 bytes, 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 — 

    
    

    
  
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: