Closed
Bug 4050
Opened 26 years ago
Closed 25 years ago
Both <option label> AND <option> content are displayed
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: dbaron, Assigned: rods)
References
()
Details
(Keywords: css3, html4, testcase, Whiteboard: [nsbeta2+][6/15])
Attachments
(3 files)
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);
}
}
}
Reporter | ||
Comment 1•26 years ago
|
||
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.
Updated•26 years ago
|
Assignee: vidur → pollmann
Comment 2•26 years ago
|
||
This ones for you, Eric. Let me know if you need any help.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
Target Milestone: M7
Updated•26 years ago
|
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
Comment 4•26 years ago
|
||
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!
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6
Comment 5•26 years ago
|
||
Doh! The test should be (nsnull == aBefore), not !-. I'll make a case for this
to go into M6.
Updated•26 years ago
|
Assignee: vidur → pollmann
Status: ASSIGNED → NEW
Comment 6•26 years ago
|
||
Checked in a fix so that Add() doesn't crash anymore. Back to you, Eric, to get
the rest of the test to work.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 7•26 years ago
|
||
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.
Updated•26 years ago
|
Priority: P2 → P3
Summary: CRASH: HTMLSelectElement add method not working → Option label attribute not used
Target Milestone: M6 → M7
Comment 8•26 years ago
|
||
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.
Reporter | ||
Comment 9•26 years ago
|
||
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.
Updated•26 years ago
|
Summary: Option label attribute not used → Option label attribute not used: GFX Selects
Comment 10•26 years ago
|
||
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.
Reporter | ||
Comment 11•26 years ago
|
||
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...
Comment 12•26 years ago
|
||
*** Bug 3325 has been marked as a duplicate of this bug. ***
Comment 13•26 years ago
|
||
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."
Comment 14•26 years ago
|
||
Redistributing bugs...
Comment 15•26 years ago
|
||
Updated•26 years ago
|
Whiteboard: [TESTCASE] option label attribute not implemented
Comment 16•26 years ago
|
||
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.
Comment 17•25 years ago
|
||
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 | ||
Updated•25 years ago
|
Assignee: pollmann → rods
Status: ASSIGNED → NEW
Assignee | ||
Comment 18•25 years ago
|
||
I am resigning this to me, I have a fix for it.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 19•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 20•25 years ago
|
||
Forgot to mark fix - if this isn't then attach a SIMPLE test case.
Updated•25 years ago
|
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]
Comment 21•25 years ago
|
||
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
Assignee | ||
Comment 22•25 years ago
|
||
Yes, you are right, it needs to be reopened.
Comment 23•25 years ago
|
||
Clearing FIXED resolution due to reopen.
Assignee | ||
Comment 24•25 years ago
|
||
Changing to M12
Assignee | ||
Updated•25 years ago
|
Target Milestone: M11 → M12
Assignee | ||
Comment 25•25 years ago
|
||
Changing to M12
Updated•25 years ago
|
Summary: Both <option label> AND <option> content are displayed → {css3} Both <option label> AND <option> content are displayed
Comment 26•25 years ago
|
||
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?
Assignee | ||
Comment 27•25 years ago
|
||
*** Bug 16745 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12 → M14
Assignee | ||
Comment 28•25 years ago
|
||
changed to M14
Assignee | ||
Comment 29•25 years ago
|
||
moving to M15
Comment 30•25 years ago
|
||
Assignee | ||
Comment 31•25 years ago
|
||
*** Bug 24130 has been marked as a duplicate of this bug. ***
Comment 32•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Assignee | ||
Comment 33•25 years ago
|
||
*** Bug 26216 has been marked as a duplicate of this bug. ***
Updated•25 years ago
|
Summary: {css3} Both <option label> AND <option> content are displayed → Both <option label> AND <option> content are displayed
Whiteboard: [TESTCASE]
Assignee | ||
Comment 35•25 years ago
|
||
changing milestone to M17 and component to form controls
Component: DOM Level 1 → HTML Form Controls
Target Milestone: M16 → M17
Comment 37•25 years ago
|
||
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?
Comment 38•25 years ago
|
||
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
Comment 39•25 years ago
|
||
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.
Assignee | ||
Comment 40•25 years ago
|
||
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
Assignee | ||
Comment 41•25 years ago
|
||
Assignee | ||
Comment 42•25 years ago
|
||
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.
Reporter | ||
Comment 43•25 years ago
|
||
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.
Comment 44•25 years ago
|
||
> 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.
Comment 45•25 years ago
|
||
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
Assignee | ||
Comment 46•25 years ago
|
||
I can turn off the part that makes label work with a simple change to html.css
Reporter | ||
Comment 47•25 years ago
|
||
I think that should be done until you can make LABEL and OPTGROUP work
correctly.
Comment 48•25 years ago
|
||
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
Comment 49•25 years ago
|
||
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.
Comment 50•25 years ago
|
||
*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...
Comment 51•25 years ago
|
||
OK, rods, it's unanimous: please go forward with your proposed change. Thx!
Assignee | ||
Comment 52•25 years ago
|
||
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.
Comment 53•25 years ago
|
||
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!
Assignee | ||
Updated•25 years ago
|
Target Milestone: M20 → M16
Assignee | ||
Comment 55•25 years ago
|
||
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 56•25 years ago
|
||
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.
Description
•