W3C home > Mailing lists > Public > public-webapi@w3.org > August 2007

Re: Implementing HTMLDocument on all Documents (detailed review of the DOM)

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Tue, 21 Aug 2007 09:48:01 -0700
To: Stewart Brodie <stewart.brodie@antplc.com>
Cc: public-webapi@w3.org
Message-ID: <OFE25D28D6.076AE7CA-ON8825733E.005AA8FF-8825733E.005C4971@us.ibm.com>

I agree with Stewart that it would be a mistake to put innerHTML and other
such things on the Element interface. The Core XML DOM also supports XML
data files and should not include features that are specific to user
interface languages such as HTML.

I am not sure what the motivation is for generalizing some of the HTML DOM
features beyond HTML, but I will point out that when SVG is used as a
standalone document, it duplicates some of the same attributes and DOM
fields from HTML. It has 'id', 'class' and 'style' attributes with the same
semantics as HTML and SVGDocument shares 'title', 'referrer', 'domain', and
'URL'. At least 3 major browsers (Firefox, Safari and Opera) implement SVG
within the same codebase that implements HTML, so they might benefit if DOM
refactoring is done with both HTML and SVG in mind.


             Stewart Brodie                                                
             ntplc.com>                                                 To 
             Sent by:                  public-webapi@w3.org                
             public-webapi-req                                          cc 
                                       Re: Implementing HTMLDocument on    
             08/21/2007 09:24          all Documents (detailed review of   
             AM                        the DOM)                            

"Simon Pieters" <simonp@opera.com> wrote:

> On Tue, 21 Aug 2007 17:23:47 +0200, Joćo Eiras <joao.eiras@gmail.com>
> wrote:
> >> Does this make sense on Element? I mean, the class attribute and it's
> >> semantics are HTML/XHTML specific.
> >
> >
> > The same goes for innerHTML. I agree there could be a generic property
> > to access the markup directly, but innerHTML's name is out of context.
> innerHTML is actually not specific to HTML, despite its unfortunate name.
> In an XML context, innerHTML, on getting, returns a serialized string of
> the node's children, in XML syntax. On setting it parses the assigned
> string as XML and replaces the node's children with the parsed XML.


I assumed that what the document means is that if you have an XML document
and you have elements that are in the HTML namespace in that document, then
they should implement the HTMLElement interface, and thus have an innerHTML
property?   And nodes that are not in the HTML namespace do not have such a

If the suggestion is really that XML documents with XML elements in them
have an innerHTML properties on all the elements, then that's just awful
abuse of the name.  It'd be better to add an innerContent property to
Element that does the right thing, before people start using it.

I'd be in favour of moving most of those other properties from HTMLDocument
to Document that were listed earlier in the thread, though - at least it
would fix the rather anomalous 'domain' property (which ends up being
read-only on HTMLDocument and write-only on Document - or was it vice
It's certainly confusing)

Stewart Brodie
Software Engineer
ANT Software Limited

(image/gif attachment: graycol.gif)

(image/gif attachment: pic23684.gif)

(image/gif attachment: ecblank.gif)

Received on Tuesday, 21 August 2007 16:49:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:57 UTC