Mike Brown wrote:
Serving XHTML as text/html may add to the confusion. When you do that, most
browsers (especially since very few have true support for XHTML) are not aware
that they are processing XML, so they go into HTML tag soup processing mode
and see the XML declaration as just junk. That's why I suggested the META.
Somehow, this didn't work.
It is not outside the realm of possibility for an XSLT processor to give you
the option of emitting NCRs even when the output encoding allows those
characters to be encoded directly. Most don't offer such functionality,
however. Saxon does (saxon:character-representation="decimal" in xsl:output).
I see.
You're also free to output us-ascii, if your processor supports it, and then
rewrite the encoding declaration afterward (or override it out-of-band, e.g.
in the HTTP Content-Type header) to say utf-8 or some other us-ascii superset.
XML does have a clause saying that it's an error to misdeclare the encoding,
but it goes on to say that ASCII entities don't strictly need a declaration
since the UTF-8 assumption won't cause problems.
When hand-coding web pages, I try to always use NCRs for any non-ASCII
chars, and don't send the charset parameter, which works out OK so far,
since as you say, in this case it doesn't matter what the browser
assumes, sniffs, or defaults to.
But for XSLT generated pages, I now output encoding="UTF-8" and send the
charset=utf-8.
Sending charset=utf-8 solved the problem, so I have none left to solve
for now :)
But thanks again for your tips,
Tobi
--
Vim users donate.
http://iccf-holland.org/donate.html
Web developers check.
http://www.pinkjuice.com/check/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list