Re: [xsl] xml:space preserve on element converted to html textarea encoding issue

Subject: Re: [xsl] xml:space preserve on element converted to html textarea encoding issue
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 07 Jun 2011 12:50:08 -0400

On 6/7/2011 12:29 PM, Karl Stubsjoen wrote:
So I converted writing the textarea out using CDATA sections and still
the tag is collapsed!  I was certain that this would not be the case,
so that is a little confusing.

It's collapsed for the same reason as just discussed in the other thread, which Phil started, about whitespace handling.

Enclosing content in a CDATA marked section has zero impact on how whitespace is treated. Never has, never should.

So then I thought maybe I can sneak
the&nbsp; into the output in my closing textarea like this:

<xsl:text disable-output-escaping="yes"><![CDATA[&nbsp;</textarea>]]></xsl:text>

And this does work.

But only until it breaks:

1. Running the transformation through a process that does not immediately serialize it (such as in a pipeline or in Firefox or other processors that don't respect d-o-e
2. Processing the result in an XML-conformant tool without a declaration for the nbsp entity

etc. etc.

This shouldn't be regarded as a solution. At best, it is a brittle and fallible stopgap.

Although, the non-breaking space character isn't
really what I want either, I really need<textarea></textarea>  with no
white space and the tag not collapsed.

... and that's what you were getting. As explained, the problem wasn't with your transformation or its results, but with the downstream processor (your viewing application).

So the dilemna with the encoding is this:  the master stylsheet is
generating either an FO or HTML.  I've been writing everything out to
FO as UTF-8, so now I would need to switch between the two, but can
not, not without calling two different templates, one to produce HTML
and the other to produce FO.  As is, the system calling the stylesheet
is passing a param specifiying either of the two output types.

I did test US-ACII encoding and that works great two.  So given the
nature of my system (1 stylesheet) am I stuck writing out the textarea
the long way as I have?

Why not use US-ASCII on both sides?


Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.      
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

Current Thread