Re: DOM 2 HTML

Chris Mannall writes:

> Apologies if any/all of these questions have already been answered... I've
> looked through the past four months in the archives and was unable to find
> answers.
> 
> 1) Why was the DOM 2 HTML module taken back to Working Draft status, and has
> remained that way since December? I just wondered because I can't see
> anything fundamentally wrong with it... it doesn't "do" much but I wouldn't
> have thought that was a reason to abandon it.

Sorry for the delay in answering.  These things are only "old" for 
members of the working group who have privately discussed them 
extensively.  They are otherwisequite legitimate questions.  You 
certainly noticed that a Level 2 HTML DOM draft was being prepared.  
There were obviously some problems which prevented it from being moved 
forward.  Speaking personally, I expect that public drafts will be 
released fairly soon that better show you where the working group is headed.

The HTML DOM level 1 and level 2 specifications are, IMO, not as useful 
or strong as they should be precisely because they lack tested 
conforming implementations.  For example, places in the major browser 
implementations were discovered where the wrong data types were being 
returned by functions (integer versus string) in implementations that 
had been counted as proof that the spec was usable and interoperable.  
Returning the wrong data types in Javascript makes the API seem 
portable, but then fail to be portable when users use the results in 
expressions with operators in them.

The level 1 specification is still in force, although there are no 
official test suites.  Test suites are an important new part of the DOM 
WG's focus, working together with NIST.  It is my intention, insofar as 
I reasonably can, to make certain that a better HTML DOM specification 
is released with a better understanding of the conformance of existing 
browsers.

> 2) Are there any plans to provide an XHTML DOM module? As the HTML DOM specs
> say, they aren't ideally suited for XHTML. It sames strange to me that there
> is an HTML module "for convenience" but nothing for XHTML. Making it easier
> to manipulate HTML documents while trying to persuade people to adopt XHTML
> seems to be working at crossed-purposes somewhat. On the same thread... if
> someone wanted to implement an XHTML DOM, would they be expected to limit it
> to the XML/Core/Stylesheets etc DOMs or go through the HTML module and pick
> the bits that apply/work with XHTML documents?

I work for Netscape.  If you try the current Netscape or Mozilla 
implementations of XHTML, they use the existing HTML DOM APIs when 
loading XHTML.  I understand that IE may take/have taken a similar 
approach, but I have not verified this personally.  There are a few 
rules that a writer of an XHTML DOM would have to follow, especially 
related to case sensitivity, because the tag names loaded through an XML 
system will be different.  So if a user wants an XHTML document, he 
needs to look for lower case tag names instead of upper case as the HTML 
guaranteed.  If a user wants an XHTML document that can be parsed as 
HTML by older browsers, then he has to rely on case-insensetive string 
comparisons.  I suspect that most DOM scripts don't look at tags, 
attributes, or their case at all.

There are other places where usage will have to change somewhat for 
XHTML to deal properly with casing, namespaces, and other issues that 
might be slightly different.  Previously, the specification reflected 
the working group's strong feeling that there were strong enough 
incompatibilities that it was illogical to try to map XHTML into the 
existing APIs.  But now that XHTML is being implemented, and there is no 
new XHTML API forthcoming, many have rethought that position, including, 
most obviously, browser vendors who have chosen to support XHTML by 
loading it into an HTML DOM, with a list of caveats for authors of XHTML 
who want to use the HTML DOM (it would be nice to have a list of 
caveats, although they are obvious to some).

By monitoring future DOM Level 3 public drafts, you should be able to 
notice the direction of the DOM WG, everyone obviously having noticed 
what is happening in the browsers.  But I cannot really let my public 
comments on W3C drafts get ahead of actual published drafts.

> 3) Why do interfaces such as HTMLDOMImplementation inherit from
> DOMImplementation? Wouldn't it be 'cleaner' to have them as separate
> interfaces that are expected to be implemented by
> DOMImplementation -classes- that support the relevant module? For example, a
> DOMImplementation class (not interface) for an implementation that supports
> the 'standard' DOM, the HTML DOM, and the MathML DOM, would need to inherit
> from DOMImplementation, HTMLDOMImplementation (which itself inherits from
> DOMImplementation) and MathMLDOMImplementation (which again inherits from
> DOMImplementation). This is, at best, messy, and can cause implementation
> difficulties. I personally would have preferred for the
> HTMLDOMImplementation and MathMLDOMImplementation interfaces to -not-
> inherit, but instead be considered as optional "extra" interfaces that
> provide the add-on functionality. Was there a reason for the choice?
> 
> Again, apologies if these are old topics.

"Cleaner" depends a lot upon the philosophy of the implementor and the 
object model.  This was originally a level 1 decision, I believe, to 
inherit specialized DOMs from the core.

The guidelines the DOM specs usually live by today (correct me where I err):

Avoid diamond inheritance of interfaces.

Use interface inheritance where practical to flatten things out where 
there is a specialized version of an object interface.  This usually 
means whenever you specialize.  It would seem quite disconcerting to 
some to have an HTMLElement and have it notbe an Element, or have an 
HTMLLinkElement, and not have it be an HTMLElement.

Optional interfaces (which seem clearly distinct from specialized 
interfaces) should not inherit, because of the multiplicity of 
combinations and possibility of imposing diamond inheritance for the 
next layer of specialized interfaces because how could the optional 
interfaces be properly incorporated into the inheritance chain.

Inheriting a specialized DOM from a base DOM does not cause the same 
problems as optional interfaces, because specialized DOMs are generally 
orthogonal with respect to each other so a specialized DOM would not be 
expect to inherit from multiple other specialized DOMs that did not 
already inherit from each other.

In a very worst case, interfaces might have to be adapted for bindings 
where there was some insurmountable problem from deriving HTMLDOM* from 
DOM*, but I haven't seen the case yet where this was needed.  New 
versions of interfaces is a whole different subject from specialization 
and I believe the spec acknowledges that bindings might need to split 
off interfaces containing new methods if the bindings do not permit 
extensions to interfaces without breaking compatibility.

I hope this response is helpful and appropriate,

Ray Whitmer
rayw@netscape.com

Received on Friday, 25 May 2001 12:58:07 UTC