242808 - Document.getElementsByName() enumerates Elements that don't have a name attribut acording to W3C HTML specification

Status: RESOLVED INVALID

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

Description

[Dietmar 'dhgm' Meier]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; T312461; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.5) Gecko/20031007

Document.getElementsByName expects one parameter that is described by W3C as 
follows:

| Parameters
|   elementName of type DOMString
|     The name attribute value for an element.

If an element does not have a name attribute according to HTML specification, 
there should be no name attribute value for that element, and the element 
should not match and be returned in the resulting collection of 
getElementsByName().

In the example given at [1], MSIE alerts "1". MSIE's getElementsByName() method 
does not return the TD element having a non-standard name attribute. Mozilla 
alerts "2". Mozilla's getElementsByName() method does return both the INPUT 
element and the TD element, but should behave like MSIE does.

[1] http://www.innoline-systemtechnik.de/dhgm/getelementsbyname/test.html

Reproducible: Always
Steps to Reproduce:
Open the example document at http://www.innoline-
systemtechnik.de/dhgm/getelementsbyname/test.html
Actual Results:  
Mozilla alerts "2".

Expected Results:  
Alert "1".

Comment 1

[Boris Zbarsky [:bzbarsky]]

> If an element does not have a name attribute according to HTML specification, 
> there should be no name attribute value for that element

That's not true from the DOM's point of view.  From the DOM's point of view, if
there is a name attribute, it doesn't matter whether the attribute is valid.  So
all that matters is whether the attribute is in the DOM.

In IE, what happens if you call getAttribute("name") on the <td>?

Comment 2

[Dietmar 'dhgm' Meier]

> In IE, what happens if you call getAttribute("name") on the <td>?

In difference to getElementsByName(), getAttribute() is DOM Core, not DOM HTML, 
so it should not care about HTML DTD. As you can imagine, getAttribute("name") 
on that td element returns the same in MSIE and in Mozilla.

Comment 3

[Boris Zbarsky [:bzbarsky]]

None of the DOM cares anything about any DTD.  Once you have a DOM, it's just a
DOM, no matter where it came from.  So IE's behavior is inconsistent, plain and
simple.

If you have a valid HTML document, you'll get exactly what you expect.  If you
have an invalid one, HTML error handling is undefined, and the DOM clearly says
that you should get everything that has the "name" attribute set.

So this is yet another IE quirk not worth copying (just like the fact that
getElementById('x') will get an element with name="x" in IE).

Comment 4

[Anne (:annevk)]

So HTML5 does specify IEs behavior as closely as possible (according to Hixie) and at Opera we're wondering on how to move forward.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I still don't think we should introduce the complexity of IE's behavior here.  The fact that I've never seen a real site broken by this difference suggests to me that this is just a non-issue in the real world and hence we should do the simple sane thing.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't feel strongly either way here. I do like the simplicity of our behaviour, but I think the spec might disagree with us. Unfortunately w3c uses the term 'attribute' both for markup attributes and idl attributes and I don't really know how to differentiate between them. I think they use the term 'content attribute' when they refer to markup-attributes which would indicate that that's not what they do here.

However saying just 'name value' if that does indeed refer to idl attributes is a bit unclear. Which interface or interfaces do they mean? Any? Including non html-dom ones? I think if a spec really wanted to refer to the idl-name then it would need to provide a list of interfaces that should be honored. So I think a resonable argument can be made for the spec being unclear here.

However IMHO a much better solution would be to just do what we do. Like bz says, it doesn't seem to hurt and it makes things a lot simpler.

Comment 7

[lists.bugzilla]

The spec for this function seems have to changed. The latest version of the DOM L2 HTML spec (http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-71555259) says:

With [HTML 4.01] documents, this method returns the (possibly empty) collection of elements whose name value is given by elementName. In [XHTML 1.0] documents, this methods only return the (possibly empty) collection of form controls with matching name. This method is case sensitive.

According to this, the current behavior is wrong for XHTML documents.

Comment 8

[Boris Zbarsky [:bzbarsky]]

I think the spec should get changed; the difference between XHTML and HTML is gratuitous, unnecessary, and would cause author confusion if implemented.