Re: [xsl] outputting &nbsp to HTML (not so final answer)

Subject: Re: [xsl] outputting &nbsp to HTML (not so final answer)
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Mon, 17 Dec 2001 18:37:14 +0000
Hi Aniceto,

> In this case I can't use <xsl:output encoding="US-ASCII" /> due to
> other important problems and many times this "<td>&nbsp;</td>" is
> not the only way I have to use non-breaking space. Web design is
> forcing me to use &nbsp;&nbsp;&nbsp;&nbsp;... (the only way in htm
> to have some " " concatenated) so I still need the "&nbsp;" and the
> only solution I fint is the so hated <xsl:text
> disable-output-escaping="yes">&#38;nbsp;</xsl:text>

Of course you can insert a series of non-breaking space characters (or
character references, depending on your encoding) into your file


It means exactly the same thing to Netscape (four non-breaking
spaces). It is only when you look at the result document source code
that it appears to be different.

> is this
> Note: disable-output-escaping="yes" can be used to generate
> non-well-formed documents, and thus should be used with caution,
> since non-well-formed output may generate errors in certain
> circumstances. For example, transformNodeToObject to an XML document
> requires that the result be well-formed and thus may not complete if
> disable-output-escaping has affected the well-formedness of the
> document. Consider disable-output-escaping="yes" an advanced feature
> to be used only when the potential dangers are understood.
> why some are screaming when thay see a disable-output-escaping="yes"?

Partly, yes. In general, there are three good reasons not to use

  - it makes your stylesheets hard to maintain (compare a stylesheet
    generating HTML with the text output method and
    disable-output-escaping with one generating HTML in the normal

  - it's very easy to accidentally create a not-well-formed result

  - some XSLT processors don't support disable-output-escaping, in
    some circumstances, particularly when the result is never

The other reason people "scream" when they see a
disable-output-escaping is because it's often used as a get-out by
people who don't yet understand how to use XSLT properly. For example,
newcomers may use disable-output-escaping to add a start tag in one
template and an end tag in another template.

It is very hard to tell when someone is using disable-output-escaping,
knowing all the risks involved, because they have positively decided
that it is the best option, as opposed to when someone is using it
because they could find no other way to achieve their objective.

In a later email you wrote:
> Yes Eric, padding style can be a solution, using a transparent
> 1x1pix gif with certain width is another one but I still need the
> "&nbsp;" in the html code (designers esoteric reasons).

I assume that the 'designers esoteric reason', is that they (the
designers) want to be able to edit the results of your transformation
and to see the characters '&nbsp;' instead of '&#160;' when they do
so. If so, this is a reasonable case for the disable-output-escaping
option being used rather than the more standard and less hazardous

If you decide that you must output '&nbsp;' then I'd recommend that
you use the idea of an nbsp entity definition within the stylesheet,
but make it insert the xsl:text element, with suitable disabling of
output escaping, as follows:

<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp
  '<xsl:text disable-output-escaping="yes">&amp;nbsp;</xsl:text>'>

That way, when you use &nbsp; in your stylesheet:


Then it will look like &nbsp; in your result.

Later, when you stop working with designers who are so fussy, or they
move on to more sophisticated authoring tools, or you run the
stylesheet with a processor that understands to use entity references
to serialize non-breaking spaces when generating HTML, you can easily
change the stylesheet so that it doesn't use disable-output-escaping
by changing the entity definition to:

<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp '&#160;'>



Jeni Tennison

 XSL-List info and archive:

Current Thread