[Bug 5803] HTML5 serialization is not compatible with XSLT

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5803


Jirka Kosek <jirka@kosek.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




--- Comment #6 from Jirka Kosek <jirka@kosek.cz>  2008-06-26 06:57:49 ---
(In reply to comment #5)
> You can already use XSLT with HTML5 if you really want to, using either:
> 
>    <xsl:text disable-output-escaping="yes">&lt;!DOCTYPE ...&gt;</xsl:text>

I have explained earlier why this is not generally working solution.

> 
> ...or (suffering excess output and a parse error):
> 
>    <xsl:output method="html" doctype-public=""/>

I don't see generating of invalid markup as a good solution.

> 
> ...or by just outputting XHTML instead of HTML, 

Why should be users in this particular case dictated whether to use XML or HTML
serialization? With the same logic applied, we can, for example, allow SVG and
MathML only in XML serialization, and get rid with many problems related to
usign SVG/MathML in HTML serialization.

> or by outputting to a DOM
> instead of text/html.

Todays tools (web-servers and web-browser) can transfer text/html over HTTP but
not DOM. So using DOM is not option here.

> This is a limitation of XSLT. There's no reason why we should be bending over
> backwards here when XSLT could much more easily be changed to support
> outputting short DOCTYPEs. (Even more so since those are valid XML too.)

No, more easily can be changed HTML5. HTML5 specification is work in progress,
while both XSTL 1.0 and XSLT 2.0 are finished specs which are widely deployed.
So cost of changing them is magnitude higher then allowing one optional string
in HTML5 spec.

Moreover, it is HTML5 which is introducing changes to HTML syntax.

> Also, note that there are much harder problems to deal with in the HTML syntax
> than just the DOCTYPE. For instance, the complications around comments in CDATA
> blocks. If XSLT can deal with those, it can certainly deal with outputting
> shorter DOCTYPEs.

CDATA is completely different thing. There is no reason for outputting CDATA
from XSLT transformation as all problematic characters are automatically
escaped during serialization. So this is no showstopper for XSLT. But without
minor change that I propose it will not be possible to emit HTML5 by XSLT.

Please accept my proposal or clearly state that HTML5 is intentionally designed
not to be compatible with XSLT.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 26 June 2008 06:58:25 UTC