Closed Bug 108480 Opened 23 years ago Closed 19 years ago

if '<input type="text">', elt.getAttribute("value") == null;

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: jrgmorrison, Unassigned)

References

Details

Attachments

(3 files)

testcase for the default value of an input type=text
511 bytes, text/html
Details
testcase take 2; IE returns 'null' for 'foobar', but '' for 'value' on a text field
760 bytes, text/html
Details
This matter needs to be reopened and addressed in combination with bugs 97058, 111992, 173255, and 173244.
14.95 KB, text/html
Details 
Noticed this while looking at bug 108198 (with or without patch
http://bugzilla.mozilla.org/attachment.cgi?id=56520).

An HTMLInputElement like this '<input type="text">', which has no value set 
for the value attribute, will return 'null' instead of the empty string when 
asked for the attributes value. e.g., 

<html>
<body>
<script>
function showState() {
    var w = document.forms[0].output;
    alert("attribute `value' = `"  + w.getAttribute('value') +
          "'; property `value' = `" + w.value + "'");
}
</script>
<p>Notice that an empty <code>&lt;input type="text"&gt;</code> returns
'null' instead of the empty string.</p>
<form>
  <input onclick="showState();" type="button" 
         value="show property and attribute values">
  <input type="text" name="output">
</form>
</body>
</html>
This is as designed, getAttribute('foo') will return null if there's no
attribute 'foo'. This violates the DOM spec, but it was decided to make mozilla
work this way for compatibility with IE (and it kinda makes sense too).

WONTFIX.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
I don't have any great emotional attachment to this bug, but IE 5.5 returns 
the empty string for the 'value' attribute of <input type=text>. It returns
'null' for any attribute that doesn't have a special DOM 0 meaning.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Well, IE's behavior is so inconsistent that it's not even funny, we won't go
there. WONTFIX.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
*** Bug 120681 has been marked as a duplicate of this bug. ***
If you set up a default value like this:
'<input type="text" value="foo" name="comment">'
whatever you will input there :
comment.getAttribute('value') returns "foo" 
whereas comment.value returns the actual value 

This confusing behaviour doesn't match neither  MS-IE's nor DOM specifications

I don't know if I should reopen this case... 

This does match the DOM spec.
*** Bug 157312 has been marked as a duplicate of this bug. ***
*** Bug 173270 has been marked as a duplicate of this bug. ***
The argument is rather involved, so I created an attachment to reduce clutter
in the Additional Comments area.
> Separating "presentation value" or "anonymous content" from the DOM is not a
> legitimate option.

Let's take the example of comment 7. I'll quote the DOM Level 1 HTML rec about
the value attribute (see
http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/level-one-html.html#ID-49531485):

value of type DOMString
When the type attribute of the element has the value "Text", "File" or
"Password", this represents the current contents of the corresponding form
control, in an interactive user agent. Changing this attribute changes the
contents of the form control, but does not change the value of the HTML value
attribute of the element.

Calling getAttribute on an Element will return the HTML value attribute.
control.value == control.getAttribute("value") will only be true if the control
still has its initial value.

> But the specification flatly contradicts this statement about the purpose of
> mutation events: “DOMSubtreeModified [...] is a general event for notification
> of all changes to the document. It can be used instead of the more specific
> events listed below [emphasis added].”

See above. A change in the presentational value of a form control does not
change the structure of the document even though it will change some of the
attributes of the corresponding DOM object (like the value attribute). None of
the mutation events apply to those attributes.

I suggest you either formulate your arguments in much shorter form, or take this
to the netscape.public.mozilla.dom newsgroup.
I take Peter Van der Beken's (comment 12) point and apologize for the longwinded
exposition.  Glad I made it an attachment, at least.
*** Bug 215698 has been marked as a duplicate of this bug. ***
I think this should be reopened, for compatibility with IE. For attributes that 
are not set but are real attributes, which is the case most likely to be hit by 
authors, IE does the right thing (empty string). Opera does too. I think we 
should just follow the specs here unless this really affects major sites.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: jst → general
Status: REOPENED → NEW
QA Contact: stummala → ian
Ian, IE gets this "right" because it thinks the attributes are actually _set_
(they appear in the attributes list, and hasAttribute returns true, last I
checked).  We really don't want to be duplicating the IE behavior here.

I'm not sure what you consider "real attributes" in a DOM Core context, which is
what we're dealing with here, by the way.
By "real attributes" I meant ones that IE recognises (e.g. "title") as opposed
to those that it doesn't (e.g. "gabooligoo").

I'm not saying we should do what IE does for everything here, just that for
getAttribute we should do what the spec says (return ""). That is to say, I
don't buy the we-nned-to-be-wrong-for-IE-compatibility line here, since IE
basically does this in the majority case.
Ian, when we were returning "" we ended up in infinite loops on a bunch of pages
that use "custom attributes" and expected null to be returned if the attr wasn't
set.

So the problem is that the "minority case" is used just as often as the
"majority case" -- a lot of scripting uses custom attributes and most scripts
don't really care about the actual attributes that are set on the nodes in the HTML.
Ah, ok. Fair enough. I guess we can fix this in post, then. (By which I mean,
change the spec in WHATWG Web Apps.)
(WONTFIX based on comments)
Status: NEW → RESOLVED
Closed: 23 years ago → 19 years ago
Resolution: --- → WONTFIX
Component: DOM: HTML → DOM: Core & HTML
QA Contact: ian → general
Now INVALID per Web DOM Core.
Assignee: general → nobody
Resolution: WONTFIX → INVALID
I find it hard to believe that the bug mentioned in comment "7" is still there after all this time.
Whether or not its part of the "Spec", it just doesn't make any sense to me, and just makes Firefox look broken.
Google Chrome, when faced with the same code returns the correct and expected results, returning the new "value" Attribute entered by the user, rather than the old one in the underlying code.
> I find it hard to believe that the bug mentioned in comment "7" is still there after all
> this time.

Er... why?  It's how every modern browser behaves, because the spec clearly requires it.

> Google Chrome, when faced with the same code returns the correct and expected results,
> returning the new "value" 

No, it doesn't.  Here's a trivial testcase for you to try in Chrome:

  Type something in this input and then click outside it:
  <input type="text" value="foo" onchange="alert(this.getAttribute('value'))">
 
when I do that, Chrome alerts "foo" no matter what I typed.

Whatever difference in behavior you're seeing between Chrome and Firefox is not this bug, because they have identical behavior on the testcases here.

Please do file a separate bug on your issue, attach the exact HTML that's showing the problem for you, and cc me on the new bug?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: