I'm aware that putting text in a textarea element is a workaround. But I cannot give this to my users.
Doesn't <map:serialize type="html"/> produce valid HTML? Rainer On Sun, 23 Nov 2008 at 16:13 -0500, [EMAIL PROTECTED] wrote: > 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 > Rainer Schöpf
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
