W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Re: Relation between core DOM and HTML DOM

From: <keshlam@us.ibm.com>
Date: Wed, 14 Oct 1998 16:37:51 -0400
To: www-dom@w3.org
Message-ID: <8525669D.006BEC78.00@us.ibm.com>
> In particular, it might be true in a given implementation that
> *every* class that implements Element also implements HTMLElement.


All that the DOM guarantees is that when you createElement it _will_ return
a Node that implements Element. If it happens to also implement
HTMLElement, as it will in an HTML document, that's fine; the important
thing is that all its behavior when accessed as an Element matches that of
the Element spec.

Here's a worst-case example: It's possible (though ugly!) to ignore the
normal class hierarchy entirely and implement all the Node interfaces in a
single class. In this case, instanceof might report the Node as everything
from an Attribute to a CDATASection, as well as the Element that it's
currently configured as. A properly written DOM application should work as
well with this as it would with a more normal OO-structured version. (One
would hope that if you tried to call getSpecified against one of these
"unified" nodes which is currently functioning as an Element, some
diagnostically useful error message would be presented... but that's a
quality-of-implementation detail.)

For that matter, there aren't all that many languages that have really
usable runtime type ID -- Java's support for instanceof is unusual -- and
certainly a DOM implementation written in a non-OO language won't allow you
to ask the question that way.  If you want to check the type of a Node and
care about portability, getNodeType() is the right answer.

Admittedly, that doesn't distinguish an HTMLElement from an Element. But I
think the solution is to either know which type of Document you generated
(ask the DocumentImplementation?), or to use only the Element API and trust
that if there's a behavioral shift you'll have been handed an Element that
is somehow set up to Do The Right Thing.

(I still want to know who coined the quote "Object-oriented programming
makes good programmers better... and bad programmers obvious.")
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.
Received on Thursday, 15 October 1998 15:02:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:04 UTC