edge issues with DOM, text/html, and xml serializations [was Re: handling fallback content for still images]

On Jul 9, 2007, at 4:41 AM, James Graham wrote:

> Sorry, I'm really confused.
>
> It would be really helpful if you could summarize the issues that  
> you are trying to address in this thread; I really seem to be lost  
> amongst the various discussions and subthreads.

The most recent part of this thread was a discussion about how  
conversions and authoring should be handled relative to the edge-case  
differences with the HTML5 DOM, HTML5's text/html serialization and  
HTML5's XML serialization. This thread forked from the discussion of  
the need to deal with the fact that an XML serialization could  
potentially include <img>fallback</img>, and what we should do about  
that errant code.

It then turned toward non-errant edge-case issues of implied <tbody>,  
and implied <colgroup>. (and perhaps even implied <body> and <head>,  
but perhaps not of practical concern). Overall, I'd say the thread  
has turned toward discussing what (if anything) the draft should say  
(or does say) about these issues. It isn't about hat we need a magic  
bullet that solves these issues. Rather about how we should deal with  
them (if we should deal with them at all).

In the course of the conversation it was raised that Opera and soon  
Safari would add anonymous tbody to their XML processing (though I  
think a more accurate term would be that they will be treating the  
tbody as implied for CSS purposes since my understanding of an  
anonymous element is that it has no name/type).

Again, I don't think the spec has anything to say on this (though  
perhaps I missed it). So we've been discussing it to figure out if it  
should say something  about this. This is not our way of saying we  
don't appreciate the hard work that the WhatWG has put into this. Its  
an impressive document by any measure. However, I can't imagine any  
document that couldn't use some improvement.

> It would be really useful if, any time you want to talk about the  
> parsing-behavior of current UAs, you could post the source of some  
> example input and DOM produced from that input.

Several posts in this discussion included source samples and  
discussed the results. Many of us have DOM viewers built into our  
browsers.

> The Live DOM Viewer should make this easy for the non-XML case.

Does that mean the live DOM viewer does not work with XML? That's  
disappointing, I was going to try to put some examples together using  
that. No one's tried to port it over?

> It would also be helpful if you could compare this behavior with  
> that in the current spec; the html5lib parsetree viewer provides a  
> simple[1] way to do this.

Where do we find the html5lib parsetree viewer?

> Sorry to anyone who is following this thread (or anyone who simply  
> doesn't care about this topic) for the extra email. I hope at least  
> someone else will find the clarification helpful.

No problem, anyone can ignore threads they're not interested in.  
However, I've changed the subject on this so that at least it  
reflects the evolved status of the thread. If anyone wants to make it  
a new thread as well, feel free.

Take care,
Rob

Received on Monday, 9 July 2007 09:57:08 UTC