- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 4 Sep 2007 14:32:55 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: public-html <public-html@w3.org>
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