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

RE: Relation between core DOM and HTML DOM

From: Miles Sabin <msabin@cromwellmedia.co.uk>
Date: Tue, 13 Oct 1998 17:16:15 +0100
Message-ID: <c=US%a=_%p=Cromwell_Media%l=ODIN-981013161615Z-21595@odin.cromwellmedia.co.uk>
To: "'Don Park'" <donpark@quake.net>, "'DOM list'" <www-dom@w3.org>
Don Park wrote,

> >Fine, but were in the REC does it say 'if you mix core and HTML
> >elements all bets are off?'. After all, a class implementing
> >HTMLElement also implements Node, so,
> >
> >  someCoreNode.appendChild(someHTMLElement)
> >
> >is perfectly well formed.
> 
> 
> Miles,
> 
> REC does NOT say "if you mix core and HTML elements all bets 
> are off".  You are right that this is a "quality of implementation"
> issue.

I'm afraid that doesn't help very much. There's nothing in the REC
which excludes the mixed core/HTML scenarios that I outlined, so
other things being equal, it seems as though a conforming
implementation should support that behaviour (it certainly seems to
fit with the hand-holding stance that level 1 has taken). At the
very least, the REC should be ammended to say that this issue is
implementation defined (which is not, IMO, the same as its being
a quality of implementation issue).

Better still, a minor rewording of a couple of clauses could tie up
these loose ends. We could stipulate,

1. A class which implements an HTMLXXX interface can only be inserted
   in a document which implements HTMLDocument.

2. Classes implementing HTMLDocument should override 
   Document.createElement() etc. so as to create an instance of an
   HTML class where appropriate. Eg.,

     HTMLDocument doc = new BasicHTMLDocument();
     Element html = doc.createElement("HTML");

     if(html instanceof HTMLHtmlElement)
       // guaranteed to be true

     Element nonHtml = doc.createElement("FOO");

     if(nonHtml instanceof HTMLElement)
       // guaranteed to be false because FOO is
       // not an HTML 4.0 tag.

This has two welcome side-effects. First, we could then use
Document.createElement() etc. as a factory method for
HTMLXXX elements ... something which is desparately needed.

And second it would be significantly simpler for implementers
to deal with the case-sensitivity issues that crop up in the
HTML DOM: getElementsByName() could delegate to an
implementation level BasicHTMLElement.isNamed() method which
could be overridden on an element by element basis to ensure
the correct semantics.

There's nothing to stop *me* from doing things this way, but
that doesn't help on the portability front.

Cheers,


Miles

-- 
Miles Sabin                          Cromwell Media
Internet Systems Architect           5/6 Glenthorne Mews
+44 (0)181 410 2230                  London, W6 0LJ
msabin@cromwellmedia.co.uk           England
Received on Tuesday, 13 October 1998 12:21:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:45 GMT