Re: [xsl] Following XSL causing strange HTML errors

Subject: Re: [xsl] Following XSL causing strange HTML errors
From: Abel Online <>
Date: Tue, 29 Aug 2006 00:31:36 +0200
Hi Steve,

Not sure if this is helping you, it's just a thought: when you declare <xsl:output type="xml" /> or xhtml, the output *must* be well-formed XML. But when you declare the xsl:output type as "text" or "html", the output does not necessarily need to be well-formed XML. For "text", it is unlikely so, for "html", you may find that some tags that need not to be closed by the html specification (note: I do not mean the xhtml spec!), like <br>, <img>, <link> are not closed by the output from the processor (these are empty elements, but will miss the closing slash).

The real output may depend on the processor. The type "xhtml" is only available for XSLT 2 processors. To get well-formed xhtml with an XSLT 1 processor, you should use output type "xml".

If you did not specify an xsl:output element, the default output is XML. Unless the very first thing to be serialized happens to be an HTML element, in which case HTML is assumed.

The tag <xmp> is not a tag defined as an empty tag in the HTML spefication. This means, that when it is empty, it should be output as <xmp></xmp> (like in your case). The empty <div> should be output as <div></div>. What I understand from your story is that this does not happen, but that you actually get an output as follows:

<div><xmp></div> ... rest of document ...

Meaning: no closing <xmp>. Is this correct?

I think it will be vital to know what your <xsl:output> looks like. Because from what I read from the W3C specs, the <xmp> tag is long gone. It was obsolete by the time HTML 3.2 came to light (see:, which was in 1996. HTML 4, 4.01 ( and XHTML 1.0 and 1.1 do not mention it at all anymore.

Another very important thing about the <xmp> element is that it allows the content to be like what we now call a CDATA section. That means that a browser will render the following:

<div><xmp>Some content with < brackets > and <tags> <br> etc >>> </xmp></div>

as if the part between <xmp> and </xmp> were plain text, showing all the brackets as well and not rendering it. The specification for XSLT does not say how processors should handle the version attribute of the <xsl:output> element, but I can imagine, that even if you provide it with the version="2.0" (the only version of html that supported the <xmp> tag fully), it will not be rendered correctly. Most likely it will be treated as an unknown html element and I don't know what will happen then (is that an error, or can the processor decide on what to do with it?).

My best advice after this (sorry for the long story): replace all <xmp> with <pre> and you should be fine (pre is defined as the successor to both <plaintext> and <xmp>). If you really need the <xmp> tag, you may try to use <xsl:element>, perhaps that works better, but I wouldn't count on it ....



Abel Braaksma

Steve wrote:

<div id="typeDiv">
        <xsl:when test="1=1">

Something about the above code is causing an elusive problem with the
HTML in my document. Removing the code removes the behavoir. The above
code, as far as I can tell, should have absolutely no output (although
it may have whitespace, someone else could tell me).

if I place <xmp> inside the div, encapsulating the XSL, a quite
strange thing happens. The code for the close-div tag appears, as well
as the rest of the document after the div as though the XMP tag were
not closed.

What on earth is going on and is the culprit XSL?


Current Thread