W3C home > Mailing lists > Public > public-html@w3.org > September 2007

XSLT and HTML5 (was: Re: Prevalence of ill-formed XHTML)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 6 Sep 2007 15:36:01 +0300
Message-Id: <2B93D232-9949-4C54-A76E-7E8F7B45F2AB@iki.fi>
Cc: public-html WG <public-html@w3.org>
To: Kornel Lesinski <kornel@geekhood.net>

On Sep 2, 2007, at 17:37, Kornel Lesinski wrote:

> On Sat, 01 Sep 2007 21:24:31 +0100, Robert Burns <rob@robburns.com>  
> wrote:
>> I'm not sure what you're saying here. If you change your XSLT to a  
>> different output mode won't it output a pure HTML serialization  
>> (with no xml-isms)?
> It won't output XHTML as HTML. It's completly counter-intuitive,  
> but that's what the spec requires:
> "The html output method should not output an element differently  
> from the xml output method unless the expanded-name of the element  
> has a null namespace URI;"
> http://www.w3.org/TR/xslt#section-HTML-Output-Method

I agree that the XSLT spec is counter-intuitive here. The better way  
is to always have the transformations work on elements in the http:// 
www.w3.org/1999/xhtml namespace and deal with the lack of namespace  
syntax in the text/html serialization in the serializer.

Doing it this way addresses pretty much all the issues raised about  
using the text/html serialization of HTML5 together with XSLT. With  
the current crop of XSLT processors this entails taking out SAX as  
opposed to bytes from the XSLT processor and plugging in an HTML5  
serializer. I suggest considering the "html" output method of XSLT  
obsolete as of HTML5.

I've written a sample app called XSLT4HTML5 that supports both HTML5  
and XML as both input and output with XSLT and expects  
transformations always to work on an namespaced XML infoset. The  
sample app comes with the Validator.nu HTML parser:

Henri Sivonen
Received on Thursday, 6 September 2007 12:36:16 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:21 UTC