On 11/26/08, Rainer Schöpf <[EMAIL PROTECTED]> wrote:
> Hi Jürgen,
>   > Am 26.11.2008 um 11:10 schrieb Rainer Schöpf:
>   > > > Did you try the xhtml serializer?
>   > > > http://cocoon.apache.org/2.1/userdocs/xhtml-serializer.html
>   > > No, I didn't. I'm willing to try.
>   > >
>   > > However, since the browsers have problems with XHTML, isn't the HTML
>   > > serializer  the better way?
>   >
>   > I think the problem here is not on the browser side; but rather not all
>   > elements are allowed to collapse in xhtml. I had the same 
> misunderstanding a
>   > while ago - Richard Frovarp explained then that only some elements are
>   > allowed to be written in <element /> notation. Textarea is most likely not
>   > among them, nor is script.
>
> But as far as I can see, the XHTML serializer does collapse them. The page I
>  quoted in my first post,
>    http://hixie.ch/advocacy/xhtml
> claims that XHTML works only if the HTTP Content-Type is 
> application/xhtml+xml.
>  Currently, text/html is used (see the definition in the global sitemap.xmap
>  file). This is inconsistent with the meta-equiv html header specifying
>  application/xhtml+xml.

Some browsers (older MSIE) do not understand application/xhtml+xml.
The workaround is to send text/html, disrupting browsers that
differentiate XHTML.  The content-type header does not allow fallback
from multiple entries like mime-type.  Servers sending XHTML probably
need to use browser detection to decide the content-type.  I find
developing for the LCD (HTML) is easier.

>   > I wouldn't use the html serializer (outdated not future proof code).

I wrote the SimpleHTMLSerializer because I need to extend the
HTMLSerializer and Cocoon's HTMLSerializer could not be easily
extended.  HTML is stupid -- anything is accepted if a few rules are
followed. Uncollapsing every element except BR seems to work well.  I
lost validation, but that should not matter when Lenya/Cocoon is
producing the content.  Can you imagine any situation (current or
future) where this will not work?

> I'd be happy to not use it, but my problem is that I don't know how to get it 
> to
>  work otherwise: someone creates a new xhtml document containing an empty
>  textarea element, and things start to go wrong. The display is wrong, the 
> Edit
>  menu stops working.
>
>  I'm at a loss how to proceed, except by disallowing insertion of textarea
>  elements in the editor configuration.

Check the length of the value of the TEXTAREA element in your XSLT,
then either remove the element or add a space depending on the desired
output..

solprovider

Reply via email to