At 2007-08-03 10:21 +0100, Andrew Welch wrote:
On 8/3/07, M. David Peterson <m(_dot_)david(_at_)xmlhacker(_dot_)com> wrote:
> NOTE: While this may seem off-topic for XSL-List, I would argue that based
> on the various problems associated with the rendering of HTML via an XSLT
> transform and <tag></tag> and <tag/> this is really and important topic
> closely related to XSLT from several different perspectives.
The key thing to remember here is the problems are caused by the
browser parsing the XML with an SGML browser, which is why
<b/>abc
...is rendered as bold in a browser.
In my tests this only renders bold in IE, not in Firefox or Opera
which render it just fine.
I tripped over this in the real world when I was decorating a <div>
area that may have been left empty in the input XML, thus the XSLT
processor validly put out an empty element using the abbreviated
syntax. On IE the formatting for the <div> bled to the end of the page.
The XSLT workaround I tell my students is to place another construct
in the field, and in the production job I ended up using an empty
comment, which produces the following when the input is empty:
<b><!----></b>
... or the following when the input is non-empty:
<b><!---->abc</b>
A while back I used to ask frequently why we couldn't have a switch to
tell the serializer to output <b/> as <b></b> and the general response
was "why?"...
I don't think standards writing should be geared around
malfunctioning tools. A lot of that is attempting to be done these days.
In the end though it was my problem, and the solution was to ensure
the final transform in the chain used the HTML output method (and then
the XHTML output method came along and the problem went away).
The XHTML output method only came with XSLT 2.0 ... in XSLT 1.0 you
are obliged to use the XML output method to get XHTML (which is still
XHTML but without the compatibility guidelines).
So in summary, the answer is to parse HTML with an SGML parser, and
XML with an XML parser and be aware which one the browser is using to
parse what you've given it.
(It think it was DC that enlightened me here)
But in the production job where I experienced this the output was
going to 10,000 desktops with unknown browsers.
Having to code around the browser bug was bad enough ... influencing
the writing of standard specifications around browser bugs is going too far.
I hope this helps.
. . . . . . . . . . . Ken
--
Upcoming public training: XSLT/XSL-FO Sep 10, UBL/code lists Oct 1
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds: publicly-available developer resources and training
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07 http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--