Re: The future of XML related technologies in Mozilla

On Tue, 31 Oct 2006, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > In DOM5 HTML, every Document supports HTMLDocument.
> 
> "Good luck".  ;)
> 
> As in, I don't see that shipping in Gecko in the next 2 years... (not 
> going to happen in 1.9, almost certainly, and the next version is 
> probably 2 years away at least).

I don't imagine the spec will be finished in 2 years either. But in any 
case my impression was that the whole discussion was very much a long term 
thing.

(In any case, that's not a prerequisite for doing this -- while we wait 
for the Documents to be changed to the HTML5 way, if we ever do that, we 
can still go ahead and put innerHTML on XMLDocument.)


> > > In addition to which, for serialization purposes this is all 
> > > patently insufficient without jumping through a _lot_ of hoops (one 
> > > of the hoops being that innerHTML doesn't serialize the node in 
> > > question, so the only way to do the equivalent of outerHTML is to 
> > > import the subtree into a brand-new HTMLDocument, etc).  Especially 
> > > if, God forbid, you were to want to serialize SVG or MathML or some 
> > > such.
> > 
> > Could you elaborate on this? I don't follow.
> 
> You can't use innerHTML on non-HTML nodes.  Assuming that you wanted the 
> part about SVG/MathML elaborated.  Or did you want something else?

I don't understand why innerHTML wouldn't work on non-HTML nodes.

 
> > > I also fully expect people to demand configurable serialization at 
> > > some point.
> > 
> > The answer "no" is probably good enough for now, though. Eventually, 
> > we can add configuration attributes for the really desired options
> 
> My point is that there's no good way to add such with the innerHTML 
> solution.

Sure, just throw some things into document.domConfig.


> > but frankly I don't see the point -- once an author has an XML string, 
> > he can fix it to whatever he wants himself, e.g. on the server side.
> 
> You mean reparse it and reserialize it?  That's what it would come down 
> to... Plus, why force a round trip to the server?  That's generally a 
> bad idea, imo.

I can't really comment, since I don't understand the use case in the first 
place. I was assuming that the data would be sent to the server anyway.


> > HTML5 has this all documented now. Let me know if you spot any errors. 
> > I know of a few that have been reported to the WHATWG list, and that 
> > I'll be fixing in due course, but please report any you see.
> 
> Given the size of the HTML5 spec and my time constraints, I personally 
> am not likely to get a chance to read the whole thing before I finish my 
> PhD work (so spring 2008).

That makes sense. In any case, HTML5 documents how innerHTML works on 
documents and elements in HTML and XML (regardless of whether they are 
HTML elements or not, in theory, though currently on elements it's on 
HTMLElement, not Element, so I guess you can't get to it for other 
namespaces yet), both for setting and getting. The parsing in particular 
is defined in detail.

There are issues remaining for sure, but I don't see why the approach 
wouldn't work on the long term.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'