cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <coc...@lojjic.net>
Subject Re: XHTML Serializer block/Ajax: Bug
Date Fri, 16 Mar 2007 13:58:50 GMT
Joerg Heinicke wrote:
> Jason Johnston <cocoon <at> lojjic.net> writes:
> 
>> The first issue is that XHTMLSerializer encodes all double-quotes in 
>> text content as &quot;, which is of course absolutely valid XML/XHTML. 
>> Unfortunately, when an XHTML document is served up with a text/html 
>> mime-type, as you're doing, Firefox doesn't actually parse the document 
>> with an XML parser; it instead uses the "quirky" HTML parser which 
>> doesn't handle &quot; entities in script.  I suspect MSIE behaves similarly.
> 
> At least for Firefox it is not as simple as you write. IIRC you can serve XHTML
> document with text/html and they are parsed as XHTML using an XML parser. But
> the document itself must also match some criteria (Doctype, XML declaration?).
> There are documents available about this topic on the internet, but I have no
> time to search for them at the moment.
> 
>> The bad news is that apparently Dojo uses 
>> document.write(), which is not allowed in XHTML, so a different error is 
>> thrown.  Dojo would have to be fixed to be able to use this mime-type.
> 
> So, Dojo is not XHTML compatible at all?

Apparently not, though I haven't researched it in depth.  I just know 
that document.write() is not allowed in XHTML.

> 
>> Another option might be to wrap the contents of <script> elements within 
>> a CDATA section so the JS could remain unencoded but it would still 
>> result in well-formed XML.  I'm not sure how some browsers would handle 
>> the CDATA delimiters so they might have to be commented out so they're 
>> not mistaken for script code:
>>
>> <script type="text/javascript">/*<![CDATA[*/
>> while(0 < 1 && true) alert("oops");
>> /*]]>*/</script>
> 
> Actually I don't like it. From an XML POV the above and the current solution are
> absolutely equal. What we are going to do with such a fix is to fix awkward
> browser behaviour or even wrong document contents.

I understand what you're saying; it definitely creates uglier content. 
But in terms of fixing browser behavior, we actually already have logic 
in place that does just that by preventing collapsing of <script /> 
tags.  From an XML point of view <script/> and <script></script> are 
also equal, but we force the latter simply because browsers handle it 
better.  I don't see this situation as any different.

> 
> If Dojo is not XHTML compatible at all, it is also clear that you shouldn't use
> XHTMLSerializer at all - and we shouldn't fix the XHTMLSerializer to make the
> output readable as tag soup what quirks mode actually means.

I also sort of agree that using XHTMLSerializer, or XHTML in general, in 
this situation probably isn't the best choice.  In addition to the 
browser incompatibilities, there are other known issues like CForms 
adding arbitrary attributes like <form dojoType=""> which will make the 
document not validate anyway.






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message