- 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