Re: [xsl] Using xsl:output in browsers, was: Re [xsl] XHTML html validation

[Abel Braaksma <abel.online@xxxxxxxxx>]

Houghton,Andrew wrote:
> One additional point I would make about IE6.  If you use 
> xsl:output with an method="xml" attribute, then also add 
> an omit-xml-declaration="yes" attribute.  IE6 has a known
> bug where it has problems with an XML declaration for an
> XHTML document.  According to the XML specification the
> XML declaration *can be* omitted for an XML document.  I 
> believe this issue was fixed in IE7.
>   

I fear there is a little misunderstanding here about what 'output' 
actually is. Output in XSLT parlor is about how some internal 
representation of a result tree is serialized into some physical 
representation of the same. Some parts cannot be represented in this 
internal representation, which are, among others, the doctype, the xml 
declaration and the encoding. All this does not matter internally.

When doing transformations in browsers, serializing is not possible (not 
directly from XSLT that is). However, apparently the browser vendors 
have decided to act differently on the chosen output method, even though 
they may as well skip it. The results of this were in my previous mail.

When doing any kind of transformation brower-side, the meaning of 
omit-xml-declaration is oblivious. However, when you do some XML 
transformation server side (or offside), and you return the resulting 
serialized XML to the browser, Andrew's statement above is correct.
> > For all browsers: when you use a user defined output method, 
> > you receive an error. When you do not specify an output 
> > method, it is XML (as it should). If you specify an encoding: 
> > don't. All browsers support UTF-8 internally, there is no use 
> > whatsoever to limit your resulting characters, possibly 
> > resulting in erroneous or unexpected behavior.
> >     
>
> Not quite sure this statement is true based on my experience with
> IE6 and IE7.  I have never received an error when specifying an
> xsl:output statement with IE6 or IE7, however IE6 and IE7 do expect
> the output of the transform to be UTF-16, otherwise you may have 
> issues with diacritics.  Something I recently helped a colleague 
> work through while he was developing a cross browser XSLT.
>   

I'm sorry, but this is simply not true. The browsers, including IE 
versions, do not 'expect' any encoding. They keep the resulting tree as 
a DOM object, which is, in the case of IE6, stored internally in UCS-2 
(the predecessor of UTF-16). But this is only interesting when you want 
to use characters above U+FFFF. I'm not entirely certain, but I believe 
this was fixed since Windows XP (IE uses the underlying windows system 
for handling strings).


> I agree with Abel, you should only be using UTF-8 or UTF-16 for
> output documents.  Not sure why people still insist on using
> ISO-8859* or Windows-* character sets when UTF-8 and UTF-16 are 
> required support for all XML parsers and they are widely supported
> by many other tools.

The only difference you may encounter, is that when you do serialize the 
resulting DOM object using JavaScript as a string, that you see more 
entity references. However, the containing page encoding will supersede 
any encoding you choose inside XSLT. And when dealing with the strings 
(without printing them in some textbox), they of course do not contain 
entities but sequences of unicode codepoints.

In short: the encoding attribute is ignored.

-- Abel Braaksma