Closed
Bug 202835
Opened 22 years ago
Closed 22 years ago
Mozilla's handling of undefined value attributes of option tags has changed
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: dhgutteridge, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
I've noticed that somewhere between the Mozilla 1.0.2 release and the latest
stable few (Mozilla 1.2 and 1.3), the way undefined value attributes of option
tags are represented when accessed via JavaScript/the DOM has changed. With any
other browser I've tried (various versions of Konqueror, Opera, Netscape, IE) if
an option tag in a select form doesn't have a value attribute defined, when it's
referenced via JavaScript (" document.formname.selectfieldname[i].value ") it's
treated as a null value. However, these latest releases of Mozilla instead
return the same value that the tag encloses ("
document.formname.selectfieldname[i].text "). I realize that this is the
defined behavior when a form is *submitted*, but why the change from previous
versions, and why do this when it would appear to be contrary to how every other
browser handles it? I'm not sure if this is a bug, or is intended to be a
feature? Anyway, not a big deal (for me), but I noticed it because the change
made some code on a site I'm affiliated with work incorrectly under Mozilla
(until we fixed it by specifically defining " value='' "). I apologize if this
is a documented feature or a bug that's already reported but I couldn't find
anything on it.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Here's something to use to compare Mozilla versus other browsers (or older
versions of itself):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Option tag blank value attribute test</title>
<script language="JavaScript">
<!--
function showProperties()
{
for(var i = 0; i < document.display.Selection.length; i++)
{
alert("The text property of the form is: \'" +
document.display.Selection[i].text + "\'");
alert("The value property of the form is: \'" +
document.display.Selection[i].value + "\'");
}
}
-->
</script>
</head>
<body onLoad="showProperties();">
<h1>Blank Test</h1>
<form name="display" action="javascript:{}" method="post" id="display"
target="_self">
<table border="0">
<tbody>
<tr>
<td>
<select style="WIDTH: 200px" multiple size="12" name="Selection">
<option>
</option>
<option>
No ID -- Why? Because it's here for show only...
</option>
</select>
</td>
</tr>
</tbody>
</table>
</form>
</body>
</html>
|
||
Comment 1•22 years ago
|
||
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-70901257 says:
value of type DOMString
The current form control value. See the value attribute definition in HTML
4.01.
Which is:
value = cdata [CS]
This attribute specifies the initial value of the control. If this attribute
is not set, the initial value is set to the contents of the OPTION element.
I suspect that's why the change was made...
Note that IE's handling of .value in DOM is generally just broken...
|
||
Comment 2•22 years ago
|
||
Yep, we were aiming at compatibility with the spec, and trying to rationalize
select .value (which should contain what will be submitted) with option ,value
(which therefore should do the same). If you want to check whether the value
attribute is there, you ought to be able to do getAttribute('value') instead,
which will actually just get the value attribute rather than the DOM .value.
See bug 162368. We'll try and keep things this way to be compatible with the
DOM until we see some sites that are having big problems with it (this is the
first problem reported so far, not bad).
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•