We were looking at it monday morning with Jeremy, and we have ben unable to get to the point where you were (took us roughly 2 hours round and round the configs)...
Took me 30 minutes to patch up the Garbage serializers, and another hour to put it into a nice block, making sure it built and so on...
The problem was that when we fixed something somewhere (on some browser) it broke on another, and so on and so forth... With the Garbage serializer that doesn't happen, and we can go on with the development.
The pragmatic programmer :) What I have indeed *not* done was testing it in every browser. You seemed to focus on the validness, so I have looked only for this.
And it's scary that in our welcome XSLT we specify a META tag with a charset and content type... Means that (probably) someone found that bug beforehands and patched it with the XSLT...
But isn't this only due to insufficient browser capabilities? IMO it's ok if an
XHTML does not add the meta tag. Only those stupid browsers that ignore the xml
declaration!
????????? I'm talking about this tag found in the XSLT for the home page of our distro (welcome.xslt):
<meta http-equiv="Content-Type" content="text/xhtml; charset=UTF-8"/>
Yes, I know. And I refered to the comment written above it. What I meant was if the encoding is given through the XML declaration there is no further need for the meta tag. But the spec states that both xml declaration and meta tag must be included while the xml declaration takes precedence (http://www.w3.org/TR/xhtml1/#C_9).
If I change the serializer configuration (for example, change encoding to ISO-8859-1, I don't like UTF-8) that tag will be copied across to the output, and the browser will panic.
That <meta> tag MUST be written by the HTML serializer (or XHTML serializer), and must NOT be encoded in an XSLT in a pipeline, as pipelines use char(s) and not byte(s).
Of course, the possible araised problems are obvious.
Why they're not fixed in there? Because I'm not smart enough to look into XALAN itself, and (IMVHO) that thing of xsl:output was wrong in the first place anyway (and that's what XALAN is relying on)...
You mean the output options should not be under control of the stylesheet?
Absolutely not... Cocoon internally is 100% unaware of any whatsoever encoding of characters... For instance it doesn't even know whether a character such as (C) [the copyright character] can be encoded in the output (imagine that I use an US-ASCII encoding). It _must_ not know it, that's the realm of the serializer.
Yes, also obvious. I only did not know if that was the point of your statement.
Joerg
