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

Re: several messages

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 03 Sep 2008 14:37:22 +0200
Message-ID: <48BE8502.5070704@lachy.id.au>
To: Jirka Kosek <jirka@kosek.cz>
Cc: HTMLWG <public-html@w3.org>

Jirka Kosek wrote:
> I'm member of W3C XSL WG. If you will follow some previous discussion
> about this topic
> http://lists.w3.org/Archives/Public/public-html/2008Jul/0078.html
> you will see that there are actually two issues to solve.
> One is to allow producing subset of HTML5 using XSLT 1.0, which is
> frozen and widely deployed spec.
> The second issue, is development of completely new output method for
> HTML5 in future versions of XSLT. This output method has to accommodate
> changes made in HTML5 from HTML4 including for example:
> - extended list of void elements
> - change of namespace, HTML4 documents were not in namespace
> - proper serialization of vocabularies that have or will have special
> standing in HTML5, like MathML or SVG

So what you're saying is that addressing the DOCTYPE issue does very 
little to solve the problem of making XSLT 1.0 output HTML5.  In which 
case, I really don't understand why we're speacial casing it at all. 
Clearly, all of those other problems are going to need to be addressed 
by the XSLT WG anyway, so just fix the DOCTYPE issue there too.

> Once are those issues related to serialization of HTML5 somehow frozen 
> or at least enough stable I'm going to propose new output method in XSL 
> WG. However I'm not sure if such method will find its way into real W3C 
> Recommendation unless HTML5 is at least Proposed Recommendation.

What's stopping you from at least beginning work on XSLT 3.0 now?

> So, if 2015 XSLT 3.0 will be commonly used with output method
> appropriate for HTML5 we can drop "XSLT-compat", until then we should
> keep it.

I really think we should drop it now.  As has already been pointed out, 
there are workarounds available to output <!DOCTYPE html> using XSLT 1.0 
using disabled output esacping, and even if that optional feature isn't 
supported by some particular implementation, then adding a small utility 
into the tool chain that takes DOCTYPE-less output from the XSLT and 
prepends the "<!DOCTYPE html>" string is trivial.

I don't think it's fair that HTML5 should bend over backwards to cater 
for XSLT any more than other authoring tools, especially when, as you 
pointed out, the DOCTYPE is only a very minor issue compared with 
supporting all the other new features of HTML5.  Just accept the fact 
that XSLT 1.0 is not designed for outputting HTML5 and is limited to 
outputting a mostly HTML4 compatible subset of it, and get one with 
defining the new output method that solves all the issues together.

Also, I think the idea of this WG defining a new output method for XSLT 
is absurd.  Let the XSLT WG take on the responsibility of maintaining 
their own standard, instead of shifting it all onto us.

Lachlan Hunt - Opera Software
Received on Wednesday, 3 September 2008 12:38:02 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC