Re: About the DOM Level 2 HTML specification

Marco wrote:

> I'm relatively new to DOM, so perhaps I'm saying the obvious or I'm 
> missing the point...
> 
> After reading the latest DOM Level 2 HTML specification, it seems to me 
> that
> the focus of DOM is to manipulate existing documents but not to create 
> new ones from scratch.
> 
> My goal is to create programmatically (x)html documents without worring 
> about
> well-formness using classes that abstract the various elements instead of
> writing out raw tags, so I turned to DOM and its implementations (for 
> example,
> the one included in Apache's Xerces).
> 
> Here are some limitations I found:
> - HTMLDOMImplementation::createHTMLDocument creates only a bare html 
> document:
>   no way to create a xhtml document or to specify a DTD. OK, I can turn 
> to the
>   superclass (DOMImplementation), but I loose the HTMLDocument as resulting
>   document (it's "only" a Document).


DOMImplementation.createDocument() is free to create a "XHTML document" 
if you pass in the appropriate doctype and namespace URI for the root 
element.


> - in HTMLDocument there are convenient methods to access some of the
>   document's elements, but surprisingly lacks a method to easily access the
>   HEAD element (that is created by 
> HTMLDOMImplementation::createHTMLDocument)
>   the way you can access the BODY element.


Accessing the head element is not something that's done nearly as often 
as accessing the "body" element (see below), therefore there's no quick 
accessor for that. Use document.getElementsByTagName('head').item(0).


> - somewhere (probably in HTMLDocument) there should be methods to create
>   instances of specific elements (for example, a createHTMLParagraphElement
>   method). While a workaround exists via the method 
> Document::createElement,
>   the specification does not mandate (and I don't see how can it do it) 
> that
>   the new element must be of the right type (at least Xerces is smart 
> enough
>   to return a proper specific instance instead of a generic Element). Also,
>   this has the drawback that you must specifiy the HTML tag, thus losing
>   abstraction


Using document.createElement(_tag_name_) (or document.createElementNS()) 
is not a workaround, that's how you create HTML elements in a HTML 
document, that's how it's always been, and this method is much more 
flexible and extendable than providing factory methods for every single 
HTML element. Doing that would just not be practical.


> - methods that return instances of specific elements (as
>   HTMLDocument::getBody) should have a specific return type: in the example
>   HTMLDocument::getBody should return a HTMLBodyElement, not just a
>   HTMLElement.
> 


If you read the definition of document.body you'll see that it is not 
always a HTMLBodyElement, if the document is a frameset document, 
document.body will return a HTMLFramesetElement, thus the type of the 
'body' attribute must be one of the common inherited interfaces, 
HTMLElement is the obvious type.


> Clearly, you can work around these and other limitations, but you loose
> flexibility and abstraction. Actually I'm using my own set of classes 


I don't understand where you loose flexibility or abstraction here.


> but this
> is obviously not the best solution, since it's (almost) always better to 
> reuse
> classes already written (when available).
> 
> Marco
> 


-- 
jst

Received on Friday, 7 December 2001 16:10:59 UTC