7833 - root element in an XHTML document is not an HTMLDocument

Status: VERIFIED INVALID

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

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The root element in an XHTML document served as text/xml is not an
HTMLDocument.  It doesn't expose document.getElementById, so I get a javascript
error on line 25 (of the current form of the document).  I think when the root
element is <{http://www.w3.org/TR/REC-html40}html> (or other HTML namespaces),
then the document object should be an HTMLDocument.  Do you agree?

I don't know if this is an example of a more general problem where HTML elements
within XML are not exposing the HTML DOM.  It may be.

Tested on:  Linux, June 4

Comment 1

[vidur (gone)]

There is a pretty active debate in the DOM WG about XHTML and whether XHTML
documents (and their containing elements) should expose the HTML DOM. Since
there are differences between Level 1 HTML DOM assumptions and a couple of
features of XHTML (casing of element names and attribute names; less
importantly, optional TBODY elements), applying the existing HTML DOM to XHTML
isn't a given. Finally, there is the issue of a priori determining (prior to
parse time) whether a document is a HTML, vanilla XML or XHTML document -
something that we'd like, given our current architecture; also something that
other companies have expressed a desire for.

This is also complicated by the fact that we haven't yet decided to what extent
the version of Gecko that will go into 5.0 will actually support XHTML. The HTML
inclusion that we currently allow in XML (and yes, the elements included do
support the HTML DOM) is relatively ad-hoc.

I'm not going to close this bug, but addressing it completely can't happen until
the DOM WG comes to some conclusion and we decide what our level of XHTML
support will be.

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think the case issues could be solved by treating XHTML as XML in terms of the
core DOM, but still supporting the HTML DOM as well.  Not supporting the HTML
DOM would cause serious problems with things such as forms, etc.

The tbody thing annoys me...

Comment 3

[Nisheeth Ranjan]

Taking XML related bugs off of Vidur's plate.

Comment 4

[Nisheeth Ranjan]

Accepting bug...

Comment 5

[Paul Gartside]

document.getElementById is in DOM2 for xml (page 380 of the relevant w3c spec).

Are there plans to implement it soon(ish)?

I have been trying to write some dynamic mathml pages, and it is very difficult

as things are.

Comment 6

[vidur (gone)]

We hope to bring our core interfaces up to DOM Level 2 compliance fairly soon. 
It's definitely the case that XHTML documents served as text/xml are not 
expected to implement the HTML DOM, so the bug should probably be closed. Note 
that we do (or rather will when we support the XHTML namespace) create HTML 
content for all XHTML elements and will have to deal with the mild 
incompatibilities between HTML and XML content:
1) HTML content returns the tagName in cannonicalized upper case. In the XHTML 
case, it should preserve case.
2) HTML content doesn't store attributes that have a namespace other than none 
or the HTML namespace. In the XHTML case, it should deal with all attributes and 
preserve the namespace.

Comment 7

[Nisheeth Ranjan]

Moving bugs out by one milestone...

Comment 8

[Nisheeth Ranjan]

Scheduling for M17...

Comment 9

[Nisheeth Ranjan]

1) from Vidur's comments timestamped "2000-02-29 11:05" is covered by bug 9076.

This bug as it is currently stated is no longer valid.  I'm closing it out and 
filing a new one (bug 41983) to track the second issue in Vidur's comments.

Comment 10

[Jan Carpenter]

Mass update of qa contact

Comment 11

[Jan Carpenter]

verified