cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <>
Subject Re: XHTML Serializer block/Ajax: Bug
Date Sat, 17 Mar 2007 15:43:45 GMT
Joerg Heinicke wrote:
> On 16.03.2007 21:52, Grzegorz Kossakowski wrote:
>> Moreover, I wonder why we need special XHTMLSerializer? As XHTML is 
>> only XML with special namespace and tag set why we don't use just 
>> normal xml serializer and configure proper mime type? Do I miss 
>> something important?
> If you have a look into the source code [1] you can see that it handles 
> (besides the stuff fixing the tag soup) doc type, mime type and has same 
> special XHTMLEncoder [2], which adds the HTML 4 entities. So far 
> absolutely ok.
> It puts every element in no namespace into the XHTML namespace. Still 
> acceptable, but abdicable - it's for the lazy guys.

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.

> Also the meta tag 
> for content type it adds should be abdicable. AFAIR it's also only for 
> IE as it stumbles on the XML declaration.
> But at the end it should not do more than 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.  But I think the end result is a good one: more documents get 
published as true XML but can still be consumed by non-XML user agents. 
  In fact this compatibility was an important consideration when XHTML 
1.0 was created, and there is an entire appendix in the W3C 
Recommendation dedicated to the subject [1].

Now, XHTMLSerializer is a tool for publishing XHTML.  Adopting a 
hard-line attitude and deliberately ignoring those things that can be 
(fairly easily) done to make the XHTML consumable by current-day user 
agents greatly decreases the usefulness of that tool.  I think there's a 
lot of value in having the tool handle these things transparently rather 
than making users figure out workarounds themselves.



View raw message