At 11:01 AM 1/29/2004, David wrote:
> I actually read all the posts you directed me to.
But apparently missed the part of the FAQ that explictly warns that
using disable-output-escaping="yes" is really a non-portable
hack that is only to be used as a last resort.
There are many contexts were an XSLT engine is allowed to (and will)
ignore d-o-e, in which case your output will render as & n b s p ;
rather than as a space.
If you are producing html then most xslt systems if using the html
output method will output character 160 as nbsp anyway, so I do wonder
why you were forcing the xml output method, as your output appears
destined for an html browser.
To add to this -- if you were to take a few hours or days to troll through
the archives of this list, you'd see this issue coming up so often that you
could assume us old hands have long ago internalized what Chris helpfully
pointed out ... that you want a &_nbsp; in your output so your table cells
show up. Yes, there are legitimate reasons for wanting a non-breaking space.
But for that purpose what you want isn't actually the &_nbsp; entity, it's
the *character represented by that entity*. If you try an HTML table with
the &_nbsp; entity and then try the same table with the actual character --
which Scott was *already getting* in his output before he resorted to d-o-e
-- you'd see that it works just fine. As it must, given what a
non-breaking-space is to begin with.
(This is why Mike raises the possibility that the real reason you want an
&_nbsp; is a pointy-haired-boss, that is, a non-technical reason. It's hard
to think of a technical reason for wanting an entity reference, instead of
what it refers to, in your output. Why would I want an entity &_capitalA;
instead of just an "A"?)
(Note also that there are sometimes legitimate reasons for wanting this
substitution -- maybe you are creating documents that will be edited by
hand in a text editor and you want your writers to have the entities. This
is why we ask for reasons: it's not just to be catty. But no such reason,
plausible or otherwise, has been given here.)
It seems unfortunate to deploy code that replaces this character with an
entity reference that does nothing but get replaced in the display by the
character we went to so much trouble to replace with it. Especially when
that code is non-portable, liable to break in the next tool you try, and
violates the spirit of XSLT, if not actually its letter: after all, the
d-o-e solution amounts to nothing but a request to the serializer
downstream, which is to say it's not really an XSLT solution at all, but
nigh unto post-processing.
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
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
======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list