Few users will notice a space in an empty TEXTAREA. Either selecting the field selects the space so it is overwritten or the space remains at the end of their input. Most applications should trim the input to remove extra spaces from the application or user.
No, the default HTMLSerializer does not produce HTML acceptable by most browsers. Your current problem and many other frustrations occur because the HTMLSerializer collapses empty elements. Tonight I wrote a simple HTMLSerializer extending AbstractSerializer with 13 lines of code (not counting lines for imports, class, functions, and empty catches.) Seems much better than the default. - Removes all namespaces. - No collapsed elements. - Every element has a closing tag except BR. Set as the default HTML Serializer in my Lenya. Testing by removing the many workarounds. I changed a SCRIPT element that was eating the page until the underscore was added: <script src="...">_</script> To: <script src="..."/> And the resulting HTML is: <script src="..."></script> solprovider On 11/24/08, Rainer Schöpf <[EMAIL PROTECTED]> wrote: > 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
