Re: Detecting XHTML

David,

Thanks for that. In an XML context, this would be handled with an XSLT
transformation post validation but prior to rendering. In the case where you
have the full DOM, this is a relatively trivial transformation (not simple,
but certainly doable). The challenge I would see would be in the case of
progressive rendering, though again I think Dr. Kay's work there in
streaming XSLT for 3.0 could prove very useful - you could take in the HTML
and when a <table> element is encountered, could process it's <tr> children
within separate templates.

Not saying that this is the best approach, just thinking about how you would
do it in from an XML standpoint.

Kurt Cagle
XML Architect
*Lockheed / US National Archives ERA Project*



On Tue, Jan 4, 2011 at 6:06 PM, David Carlisle <davidc@nag.co.uk> wrote:

> On 04/01/2011 22:39, Kurt Cagle wrote:
>
>> I'm guessing that the tbody example et al. is particularly significant
>> in the progressive rendering case?
>>
>>
> not necessarily, for example you can style a table by applying a css rule
> to tbody and it should work in text/html whether or not the tbody is
> explicit in the markup. If you changed the html parser so that
> <table><tr><td>aaa</td></tr></table>
> parsed as it does for xhtml, then any number of things would break as the
> tbody element would no longer be in the dom so not usable from css or
> script.
>
> tbody isn't the only example, as Henri has pointed out in a parallel
> thread, the html rules around force-closing the p element will similarly
> cause even well formed xml documents to have radically different parse trees
> when parsed as HTML. I may have disagreed with Henri over some edge cases
> with new (to html) elements where I think there could have been less
> differences, but I even I wouldn't suggest changing the parsing here to be
> xml-like.
>
>
> David
>
>
>