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 "&#160;", 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 "&lt;/textarea&gt;"?
 > >   Rainer Schöpf
 > 

   Rainer Schöpf
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to