- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 18 Dec 2008 20:34:51 +0100
Elliotte Harold wrote: > ... > Since XSLT 1.0 can generate well-formed XHTML without any problems, > there really is no need for this at all. Documents generated by XSLT > that need to be conforming should simply be XHTML. > ... Now if you can persuade Microsoft to implement XHTML, that might fly. > Furthermore, it is false that XSLT cannot generate an HTML 5 conforming > DOCTYPE in HTML mode. As proof I present this stylesheet: > > <?xml version="1.0"?> > <xsl:stylesheet version="1.0" > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> > > <xsl:output indent="yes" method="html"/> > > <xsl:template match="/"> > <xsl:text disable-output-escaping='yes'><!DOCTYPE HTML></xsl:text> > <html> > </html> > </xsl:template> > > </xsl:stylesheet> > > > and the following output: > > $ xsltproc test.xsl http://www.cafeconleche.org/ > <!DOCTYPE HTML><html></html> Doesn't work with Firefox' builtin XSLT engine which ignores d-o-e (and is allowed to do so). > ... > Most importantly, does it really make sense to add ever more cruft not > the spec to support every legacy tool and language out there? What if we > discover that K&R C won't do Unicode? or that some old versions of Java > require tags to be upper cased? A spec like this should not be making > special allowances for the languages that may be used to generate it. > > This time I will request a specific action: delete this section > completely. It has no place in the spec. > ... I totally disagree. The spec also fails to mention that there are more use cases than XSLT; several HTML serialization methods share this restriction with XSLT's HTML output mode. Thus, the spec should continue to allow this, but pick a more correct name. BR, Julian
Received on Thursday, 18 December 2008 11:34:51 UTC