No browser understands the collapsed elements syntax in HTML. A <SCRIPT/> in the HEAD element usually displays a blank page.
The best solution is to write an HTMLSerializer to produce valid HTML. Most Lenya and Cocoon users would find one very useful, but nobody has written one. (My current work will include one. Cocoon does not make it easy to extend the core classes.) The current workaround is to place text inside the TEXTAREA (and B, H1, I, LINK, SCRIPT, and many other elements) so the elements do not collapse. Try a space, then " ", then a period or underscore. solprovider On Sat, Nov 22, 2008 at 12:06 PM, Rainer Schöpf <[EMAIL PROTECTED]> wrote: > I've encountered a problem with textarea-Elements in content. > > A user asked me how to create a form with a textarea Element. It is quite > easy to enter the HTML code, for example in TinyMCE, directly as HTML: > > <h1>New XHTML document</h1> > <p> > Here comes the text of your new document... > </p> > <p> > <textarea cols="60" name="thema" rows="3"></textarea> > </p> > <p> > <input name="zeit" type="text" /> > </p> > > However, when you save it, it looks very strange: the second input field is > missing, and the HTML _code_ following the textarea is shown in the textarea > input field. > > The problem here is that an empty textarea element is emitted as > > <textarea .../> > > and not as > > <textarea ...></textarea> > > The former is certainly valid XHTML, but the browser doesn't treat it as > such, but as an error: it behaves as if the "/" character was missing, thus > efectively treating the rest of the document as part of the textarea. > (Tested with Firefox3 and IE7). > > A bit of research led to this page: > > http://hixie.ch/advocacy/xhtml > > which claims that XHTML doesn't work together with content-type text/html in > these browsers. > > (See also: http://www.lshift.net/blog/2006/04/03/xhtml-considered-harmful) > > One could argue that the "correct" Content-Type "application/xhtml+xml" is > set in the META http-equiv="content-type" tag of the HTML head, but that > doesn't matter since the http response header sets text/html; just as the > charset in that META tag doesn't matter if the http header specifies another > one. > > OK, so I changed my publication's sitemap to finally call map:serialize with > type="html" instead of type="xhtml". This seems to get around the problem. > > I hope I have explained myself correctly; I'm very grateful for any other > insight or proposal. > > (The obvious workaround, not using textarea, is probably not something I can > easily explain to my user :-)) > > > Finally, another problem that looks much easier to solve: > > Try to edit the page with the textarea element with TinyMCE, and the editor > area is messed up: everything after the textarea is placed below the > editable area. Sometimes even the Save and Cancel buttons stop working. > > What happens is this: tinymce uses a textarea for the editor instance, and > the inner textarea Element is copied as is. The browser takes the first > "</textarea>" (the one terminating the inner one) as end tag for the first > "<textarea>" (the outer one). > > I'm not sure how this should be handled: by escaping the inner textarea, ie. > sending "</textarea>"? > Rainer Schöpf
