cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: XHTML Serializer block/Ajax: Bug
Date Sun, 18 Mar 2007 13:40:41 GMT
On 17.03.2007 16:43, Jason Johnston wrote:

> If by "the lazy guys" you also mean Cocoon itself.  For instance, the 
> CForms forms-field-styling.xsl creates all its output in the null 
> namespace, which is fine for regular HTML delivery but if for some 
> reaason you do want to deliver as XHTML you have to set the proper 
> namespace somehow.

A most trivial XSLT can do this.

> To interject a counter-opinion, there is a well-established precendent 
> on the Web today for delivering XHTML in ways that are consumable by 
> current-day user agents but without sacrificing the well-formedness or 
> validity of the XML.  True, you have to control certain aspects of the 
> serialization to avoid tripping up certain browsers, which can be a bit 
> of a pain.

This can be easily reached by using BrowserSelector.

> I think there's a lot of value in having the tool handle these things
> transparently rather than making users figure out workarounds themselves.

That's the point where I don't agree. By delivering XHTML while the 
browser can't understand it you force it into the quirks mode - and 
that's more or less unpredictable. If you deliver standard conform HTML 
instead the browser will behave (probably also more or less) standard 

Just an example, probably everybody who has been working with CSS knows 
the box model bug in IE. Since IE6 this one is fixed and you will get 
expected behaviour IF you are in standard compliance mode [1]. 
Otherwise, with the one fits all solution, you have to cope with that 
bug [2].

Despite this being just an example which I generalize IMO there is not 
lot of value doing such things transparently. Once again problems should 
get fixed where they arise. This means using HTMLSerializer here when 
necessary and not create one workaround (additional stuff in 
XHTMLSerializer) which leads to the next one (e.g. fixing IE box model) 
both bloating the code. That's just paradoxical. Documenting it is much 
more appropriate.



View raw message