Alazanto

Embedded Formatting for Mozilla

Filed Under: MT Carbon, Journal.

Thus far, the most glaring problem with the XML/XSLT driven weblog has been in how formatting (like paragraphs or images) embedded in the XML documents would cause Mozilla to display the HTML tags rather than rendering the HTML.

As I explained earlier, disable-output-escaping is a method to render HTML tags embedded in XML documents. In order to do this, simply wrap your XML data (that contains embedded HTML) in the CDATA tags:

<xml-tag><![CDATA[<b>hello</b>]]></xml-tag>

What does this do? This is a very good question, and I’m not extremely sure. :) In essence, this pair of tags tell the XML processor to keep its hands off everything contained within.

When you call this tag into the XSL document, every character is displayed as plain text, rather than, say, excecutable code. So, the following XSL…

<xsl:value-of select=\"xml-tag\"/>

…will give you the following output, rather than the word “hello” in bold:

<b>hello</b>

When you add the disable-output-escaping attribute to the XSL tag…

<xsl:value-of select=\"xml-tag\" disable-output-escaping=\"yes\"/>

…Internet Explorer 6, along with many server-side XML/XSL processors will serialize the data, preparing it to be rendered by a browser’s HTML engine. Any markup or other code is then processed, so the above snippet of XML would actually render as the word hello in bold face.

The Mozilla engineers (seemingly) decided not to support this feature because of W3C recommendations. Here is what Peter Van der Beken had to say:

The W3C spec is very clear: “An XSLT processor will only be able to disable output escaping if it controls how the result tree is output”. The Transformiix module integrated in Mozilla only generates a tree, it does not and will never output (serialize) the result tree to [an] XML document (nevertheless subsequently reparse that to a tree).

In a previous entry, I explained that the Mozilla team was planning upon supporting this attribute as the MSXML processor does. This statement is not correct. The stand-alone version of Transformiix will behave as IE6 does, but the Mozilla module will not for the reasons stated above.

Earlier, I was using the disable-output-escaping attribute in my XSL in order provide text formatting embedded within individual blog entries and comments (thank you for the original tip, ForgetFoo). However, because Mozilla, a major client-side XML/XSL processors, would not display the pages as desired, I was looking for work-arounds.

Carey Evans was kind enough to step forward for some really helpful advice on how to get embedded formatting to render in Mozilla.

He was even able to do a rather lengthly summary of the workaround. You can find that summary here:

Click to Go to Carey’s Summary

I will try my best to explain his hypothesis in my own terms…

I notice that when I write HTML tags, CSS style definitions or JavaScripts in an XSLT document, that code tends to render via the DOM. However, when the same sort of code is carried over via an XML document, it does not render, and without the CDATA tags, will not even show up as raw code.

The easiest way to get Mozilla to render code carried over from the XML document is to instruct the XSLT document not to carry the code over directly from the XML document, but to write that code itself. When an XSLT document writes its own code, it renders correctly in Mozilla’s DOM. Go Figure…

So, how does one go about doing this? Luckily, the XSL spec includes a tag that does just this.

In a normal situation you would retrive data from an XML document like this:

<xsl:value-of select=\"xml-tag\"/>

If there exists code embedded in the XML data, and you want that code to render, the XSL document cannot call the data directly. Instead, it must copy that data and re-write it. This enables the DOM to recognize the code. So, simply change the XSL to this:

<xsl:copy-of select=\"xml-tag\"/>

Now everything should work in Mozilla!

Actually, I have open requests this time around:

  • Paragraph breaks within both entries and comments render differently than one would see in the blog’s (X)HTML counterpart. When using the “mezzoblue” demonstration, this glitch is painfully evident. Am I doing something wrong - or is it mozilla? (this issue has been resolved)

Please note that this method has been implemented into the MT Carbon Weblog. You can also download the source here… (note to self, create a pretty icon for download links)

Published: 4 years, 10 months ago

Keywords