31671 - getElementsByTagName should find nodes by their local name in XML documents, ignoring namespaces and prefixes

Status: RESOLVED DUPLICATE of bug 492933

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

Description

[Joe Hewitt]

Please see the test case following this description.

Problem #1 - 

When checking the .nodeName of a node with a namespace (<some:thing>), the 
namespace prefix is returned ("some").  Shouldn't this actually return the full 
name, "some:thing" ?

Also, the DOM Level 2 Node attributes "prefix", "localName", and "namespaceURI" 
have not yet been implemented, which would help with this problem.  

Problem #2 -
document.getElementsByTagName can only search on the prefix of a namespaced 
node ("some").  It should be able to search by the full name, e.g. 
document.getElementsByTagName("some:thing"), or at least the local name.  The 
W3C spec doesn't specify how this should work, unfortunately.

Also, the DOM Level 2 Document method "getElementsByTagNameNS" has not yet been 
implemented, which would help with this problem.

Comment 1

[Joe Hewitt]

Attachment: demonstration of bug

Comment 2

[Johnny Stenback (:jst)]

Joe, don't get me wrong here but this is an invalid bug, what you're trying to
is to use namespaces in an HTML document and that is not, nor will it be (except
possibly in XHTML) supported. Most likely the html parser sees the tag
<some:thing> and breaks the tag name at the ':' since colon is not a valid
characted in a HTML tag name ("thing" is most likely interpreted as an
attribute).

I'm working on implementing the DOM Level 2 in mozilla, getElementsByTagNameNS()
will be implemented.

If you like you could test the same sample as an XML file and see how that
works.

Comment 3

[Joe Hewitt]

Ok, you are correct about the reason why this bug was invalid within an HTML 
document.  However, trying this in XML introduces some new problems.  

First of all, I tried using the XHTML recommendation URI for the html 
namespace, and this failed... but then I discovered bug #7834, so I realize 
this is being looked at.

So, I created an XML document, gave it the HTML 4.0 URI, and put everything in 
the html namespace.  The document displays correctly. However, when I attempt 
to use document.getElementById, I get an error, and apparently discovered that 
there is no such function implemented on the Document node, nor is it 
implemented on any Element node.  

Also, in this .xml document, nodeName getElementsByTagName work differently 
than in an .html file.  Now they return the localName instead of the prefix. 

Why has getElementById disappeared in this context, and why do nodeName and 
getElementsByTagName treat namespaces differently?  See the new attached test 
case for demonstration.

Comment 4

[Joe Hewitt]

Attachment: second demonstration

Comment 5

[Johnny Stenback (:jst)]

Joe, you're correct in everything you say here. Both nodeName and
getElementsByTagNAme() are buggy in XML documents, if you want to file bugs on
them then please do so. As for getElementById(), if you look at the DOM Level 1
spec you'll see that getElementById() is defined in the HTMLDocument interface
and not in the Document interface and thus it's not defined in and Level 1 DOM
XML document. DOM Level 2 did move getElementsById() to the core Document
interface and I'm working on doing that in mozilla, there are problems in doing
this move since there's currently no information in the XML content model as to
what attribute is the ID attribute, we need to get this info from expat...

Thanks for all your input Joe. (PS. I'll land Vidurs fix for bug 7834 rsn)

Comment 6

[Fabian Guisset]

VERIFIED invalid

Comment 7

[Hallvord R. M. Steen [:hallvors]]

document.getElementsByTagName('foo') should now find <ns:foo xmlns:ns="http://example.com/ns"> according to https://dom.spec.whatwg.org/#concept-getElementsByTagName - not so invalid anymore, then :)

Comment 10

[Hallvord R. M. Steen [:hallvors]]

Attachment: 31671.htm - proper test case, passes in Chrome

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Please create new bugs if new specs require implementation changes. Reopening ancient bugs feels odd.

Comment 12

[Hallvord R. M. Steen [:hallvors]]

Olli: will do for the future. But do you want to close this again and open a new bug?

Mike: was that needinfo just to make me respond to Olli? Not sure why you NI'd me..

Comment 13

[Mike Taylor [:miketaylr]]

> Mike: was that needinfo just to make me respond to Olli? Not sure why you NI'd me..

Yeah I'm not sure either. I think I had a question, but deleted it and forgot to clear ni.

^_^