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

On Tue, 21 Aug 2007 23:12:17 +0200, Maciej Stachowiak <mjs@apple.com>  
wrote:

> For an XHTML+SVG compound document by inclusion, you really want both  
> the SVGDocument and HTMLDocument interfaces to be available, regardless  
> of the MIME type or root element namespace. Otherwise you can't reuse  
> scripts between an XHTML document that embeds SVG and an SVG document  
> that embeds HTML.

I'm not sure you can actually reuse scripts anyway, because a script in an  
HTML document will think that there are no other "HTML documents" in the  
same document, so e.g. an SVG document that embeds two HTML documents will  
likely break the scripts anyway.

e.g., take the following example:

   <svg:svg ...>
    <svg:foreignObject>
     <html>
      <form><input/></form>
     </html>
    </svg:foreignObject>
    <svg:foreignObject>
     <html>
      <form><input/></form>
      <script>document.forms[0][0].value="foobar";</script>
     </html>
    </svg:foreignObject>
   </svg:svg>

The second "HTML document" will modify the input from the first "HTML  
document" which is different from if it was standalone or if the order was  
swapped.

> Even more significantly, some HTMLDocument/SVGDocument interfaces  
> include important APIs that do things which can't be achieved any other  
> way.
>
> For instance, under your proposal document.execCommand and  
> document.selection would be unavailable when SVG is the root, making it  
> impossible to do HTML editing in XHTML embedded in SVG.
>
> How would your proposal address this?

Here's an idea:

Copy HTML-specific members of HTMLDocument to HTMLHtmlElement.

This way you will only have to rewrite the pointers to the document to  
pointers to a particular element when you take an existing HTML document  
and embed it in a compound document, e.g. the above example could look  
like this:

   <svg:svg ...>
    <svg:foreignObject>
     <html>
      <form><input/></form>
     </html>
    </svg:foreignObject>
    <svg:foreignObject>
     <html id="test">
      <form><input/></form>
      <script>document.getElementById("test").forms[0][0].value="foobar";</script>
     </html>
    </svg:foreignObject>
   </svg:svg>

Now the second "HTML document" works the same regardless of where it  
appears or what is surrounding it.

> It also seems to me that the conflicts are few at present, and could be  
> avoided in the relevant working groups in the future, in a way that is  
> lower cost than pushing everything into Document.

But the W3C aren't the only ones who might extend the Document interface.  
e.g. if Safari or Opera wanted to let their widgets access their config  
files and let those have a WidgetConfigDocument interface with useful  
stuff specific to widget config files, it would have to be mixed with HTML  
and SVG specific stuff and furthermore the WidgetConfigDocument interface  
would be implemented on all other Documents.

It also potentially hinders implementation of HTML5 if the UA already has  
interfaces for other types of documents that would conflict with each  
other or with HTMLDocument.

> I do agree that adding some interfaces to Element could be helpful, but  
> having GUI-oriented operations like focus() and click() may be seen as  
> inappropriate in DOM Core.

Ok.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 4 September 2007 19:18:36 UTC