[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Understanding why <tag></tag> is the way it is (wa

Subject: Re: Understanding why <tag></tag> is the way it is (was Re: IE Client side transformation issue)
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 03 Aug 2007 07:30:53 -0400
Re:  Understanding why <tag></tag> is the way it is (wa
At 2007-08-03 10:21 +0100, Andrew Welch wrote:

On 8/3/07, M. David Peterson <m.david@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx 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

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.