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

On Sep 4, 2007, at 12:18 PM, Simon Pieters wrote:

> 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.

Mixing multiple HTML snippets makes it problematic to access  
document.forms by index, but that's probably a bad idea anyway since  
it will break in the face of adding forms to a plain HTML document.  
But certainly document.execCommand is something you'd want to work in  
HTML snippets in an SVG document, and there's no reason it should  
break, regardless of how many HTML snippets you embed. Indicentally, I  
wouldn't consider this a case of embedding two HTML documents in an  
SVG document, but rather a single compound document using elements  
from multiple namespaces.

>> 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.

That creates two problems. First, you need to surround HTML embedded  
in another markup language with an <html> element, which should  
otherwise be unnecessary. Indeed, it's probably not even a good idea  
since it's hard to define a good meaning for multiple <head> sections.

> 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.

I don't think making this forms[0] case work when you paste multiple  
HTML snippets into SVG is important enough to call for duplicating  
every interface that's on HTMLDocument on HTMLHtmlElement with  
different behavior. In particular, you added an id here, why not just  
add it to the form:

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


>> 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 see your point, and I would guess it wasn't the intent of the spec  
to interfere with such cases. But still, if a UA supports HTML, SVG,  
XHTML and generic XML, (and, say, MathML) it is a good thing if we can  
present the same set of document interfaces.

There's all sorts of interfaces besides Document that if supported at  
all should be implemented by all typical rendered documents. I found  
the following in various W3C specifications: DocumentStyle,  
DocumentCSS, DocumentEvents, EventTarget, DocumentRange,  
DocumentTraversal, DocumentView, XPathEvaluator, DocumentXBL,  
Selector, DocumentWindow. Fundamentally, it seems to me that  
interfaces like HTMLDocument and SVGDocument can and should be in the  
same category, at least so long as the document can contain HTML or  
SVG elements with their usual special behavior.

I guess the rule of thumb I would use is that if your  
WidgetConfigDocument supports XPathEvaluator and DocumentCSS and the  
like, it should probably support HTMLDocument as well.

Furthermore, besides the huge number of interfaces expected on  
documents, we also have the issue of the global namespace, where SVG  
and HTML at least are defining properties and methods. In that case,  
it clearly seems like the only sane thing to do is to provide all  
global namespace APIs always. It would be very confusing if Window  
objects changed their API based on the document they currently happen  
to contain.

>> 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.

Maybe there should be an InteractiveElement interface or something  
that HTML, SVG and other markup languages intended to be rendered  
could share (MathML? SMIIL?). Maybe there's a similar useful subset  
for Document.

Regards,
Maciej

Received on Tuesday, 4 September 2007 21:33:07 UTC