[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
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. 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. 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|