- From: Miles Sabin <msabin@cromwellmedia.co.uk>
- Date: Tue, 13 Oct 1998 17:16:15 +0100
- 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 UTC