cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: Serializers issues...
Date Wed, 21 Apr 2004 18:44:28 GMT
On 21 Apr 2004, at 14:27, Joerg Heinicke wrote:
> Pier Fumagalli <pier <at>> writes:
>> Dunno, maybe it's my config, but with the
>> garbage serializer, I'm able to validate my pages at the W3C validator
>> service, with the default one, I'm not...
> HTML or XHTML? Snippet from my Woody/CForms application:
> "">
> ...
> <link href="cforms/resources/woody.css" type="text/css" 
> rel="stylesheet">
> <script type="text/javascript"
> src="cforms/resources/mattkruse-lib/OptionTransfer.js"></script>
> ...
> <textarea title="" name="longCause" id="longCause" 
> type="textarea"></textarea>
> ...
> or in XHTML:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "">
> ...
> <link href="cforms/resources/woody.css" type="text/css" 
> rel="stylesheet"
> /><script type="text/javascript"
> src="cforms/resources/mattkruse-lib/OptionTransfer.js" />
> ...
> <textarea title="" name="longCause" id="longCause" type="textarea" />
> Are they "wrong" in your understanding? Wasn't the issue reports about 
> missing
> spaces before closing the tag? Nothing against your serializers, I'm 
> only
> curious.

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 

If someone has better suggestions, please let us know! :-P

>> 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"/>

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).

>> 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.

> Maybe we can simply fix it by setting the encoding in the response 
> header:
> As recent 
> browsers look
> first there before relying on the meta tag information. AFAIK your 
> serializers
> already add the encoding to the header, don't they?

The Garbage serializers add a META tag if and only if they can do it 
(they know the HTML/XHTML DTDs, they know where to output those tags), 
but in XML (for example) it doesn't and it uses the <?xml 
encoding="..."?> prolog pseudo-processing instruction...

And in addition, it prepares the correct header, with full content-type 
AND charset...

That serializer simply plays on the safe side... It tries to fix all 
the bugs and incoherences in the different browsers by not only taking 
care of outputting (or not) close tags, but also to prepare a 
compatible content-type header so that most (trivial) problems can be 

Just in case (just in case) it also converts all the different cases of 
HTML tags to upper and of attributes to lower (both lower cases in 
XHTML) as outlined in the spec...

It basically does all those boring jobs that makes the page safe, and 
(to do that) it's EXTREMELY slow (well, not that much) :-P


View raw message