DOM WG response to the XHTML Last Call

This is the formal response to the XHTML Last Call from the DOM WG.
I apologise for the fact that it is somewhat late. It took us some
time to realise what the real problems are, and to come up with
suggestions.

regards,

Lauren Wood, Chair, W3C DOM WG.

The DOM WG has been discussing the XHTML specification for some time
now, to determine how it will work with the current HTML Level 1
DOM. We have a number of concerns which we are now bringing to your
attention. 

XHTML documents which are served as HTML pages will be
indistinguishable from HTML documents, and thus DOM implementations
which receive such documents will use the Level 1 HTML DOM, and the
Level 1 Core DOM which assumes HTML, to process these pages.  If we
assume that all users who wish to access the Level 1 HTML DOM will
serve their XHTML pages as HTML (using the MIME type or whatever
mechanism works for this), then the fact that DOM implementations
will not be able to tell the difference between XHTML pages and HTML
pages means there will not be any compatibility problems with the
Level 1 HTML DOM. If, however, as seems likely, some users of XHTML
pages will wish to access Level 1 HTML DOM functionality for pages
served as XML, there will be compatibility issues which should be
made clear. If users of XHTML documents served as XML do not wish to
use any of the functions defined in the HTML DOM, then the document
can be treated completely as an XML document.

The easiest of the issues to rectify is the problem that, although
XHTML is meant to be solely recasting HTML 4.0 as XML, the <tbody>
element is no longer required in the DTD. This relaxation of the
HTML 4.0 content model will break usage of the object model for
tables in the HTML DOM, as the object model requires that the
<tbody> element be present.  We request that the <tbody> element be
made required in the XHTML DTD, as it is for HTML 4.0.

There are various compatibility problems which remain. In general,
XHTML pages served as HTML pages will be indistinguishable to an
HTML DOM implementation from HTML pages, and thus will go through
the HTML DOM code. XHTML pages served as XML will be treated as XML
(e.g., with case-sensitivity of element types). The only way to tell
(in the absence of a special XHTML MIME type) if a generic XML
document is XHTML is to rely on the presence in the document of a
particular namespace URI or doctype. 

The dichotomy between handling the page as MIME type HTML or MIME
type XML will cause the various compatibility problems, since the
results of DOM Core functions depend on knowledge of whether the
document is HTML or XML. Case sensitivity is one of these, since the
HTML DOM requires that element names be returned to the script
writer in upper case (e.g. if the script writer asks for the tagName
of an element, it will be
upper case), while an XHTML document served as XML will have the
element names returned in lower case, since lower case has been
specified in the XHTML DTD. There will be other problems with
processing instructions (not known in HTML) and CDATA sections. The
latter are particularly important, since DOM users will typically be
using the SCRIPT element, which for XML documents in general will
contain a CDATA section. Although it may be possible to come up with
guidelines which allow script writers in some circumstances to write
pages which can use the HTML DOM on XHTML pages served as XML, there
will often be cases where the differences between HTML and XML make
processing of XHTML pages using the HTML DOM infeasible. 

We request that the XHTML specification include a discussion of the
problems with using the HTML DOM in the compatibility guidelines.
This note can serve as a starter for that discussion. 

It would be possible to define an XHTML DOM for use with XHTML
served as XML, but it's not obvious what gain this would bring for
the time it would cost; doing a DOM for the modularised version of
XHTML will bring more benefits.

Members of the DOM WG also expressed concern that there is little
(if any) implementation experience yet, particularly with respect to
how DOM scripts could be used with XHTML documents. We would like to
see some discussion of implementation experience and user
experience, particularly since it seems to us that users of XHTML
risk losing much or all of the benefits of the HTML DOM unless they
serve their pages as HTML, which does rather negate the point of
defining XHTML as an application of XML.

Received on Friday, 4 June 1999 13:17:45 UTC