You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lenya.apache.org by Rainer Schöpf <ra...@proteosys.com> on 2008/11/22 18:06:26 UTC
Fun with textarea-Elements
Hello,
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
Re: Fun with textarea-Elements
Posted by so...@apache.org.
On 12/1/08, Richard Frovarp <ri...@sendit.nodak.edu> wrote:
> Rainer Schöpf wrote:
> > On Wed, 26 Nov 2008 at 15:36 -0600, Richard Frovarp wrote:
> > > Rainer Schöpf wrote:
> > > > On Wed, 26 Nov 2008 at 11:19 -0600, Richard Frovarp wrote:
> > > > > > > Which browsers have issues? I'm issuing XHTML strict without
> issue.
> > > > > > Try inserting an empty textarea-Element.
> > > > > > Doesn't work in Firefox 3 nor in IE7.
> > > > > > Rainer
> > > > > > > > Are you talking empty as in <textarea></textarea> or
> </textarea>? The second
> > > one is not valid XHTML. There is an issue with the generator collapsing
> the
> > > elements because it is perfectly valid XML to do so. But if you were to
> have
> > > proper XHTML, FF3 and IE7 would render it fine.
> > > > Richard
> >
> > Empty as in <textarea></textarea>. Someone created a document containing
> exactly that. The generator collapses it and the browser gets confused.
> > Rainer
>
> Yeah, but at that point it isn't XHTML anymore. There is a difference
> between properly formed XHTML and what this generator dumps out. The
> generator is following the rules of XML, which are not the rules of XHTML.
> So the problem isn't with XHTML, the problem is with the generator creating
> things that aren't really XHTML. solprovider's serializer may be what's
> needed.
>
> Richard
My serializer creates good HTML if the source is already HTML-like
e.g. XHTML. Rereading the original post suggests the serializer may
not solve the original issue.
Rainer wants to allow editors to enter a TEXTAREA within the TEXTAREA
used for entering RichText. TEXTAREAs cannot be nested. When the
document is opened again for editing, the nested TEXTAREA closes the
editor field and destroys the rest of the field. Rainer needs to
replace the nested TEXTAREA tags with something else before sending to
the browser, then use JavaScript to translate the nested tags. From
the explanation, the nested TEXTAREA saves correctly so:
Saved field contains ... <TEXTAREA ... ></TEXTAREA> ...
Send to browser as ... [TEXTAREA ... ][/TEXTAREA] ...
After loading, browser translates to ... <TEXTAREA></TEXTAREA> ...
While this is probably possible, the document editors were not
designed to be form creators. Nested FORMs are likely to be the next
issue. Why show a TEXTAREA without a FORM element? The FORM element
must be processed like the TEXTAREA so the nested FORM does not
destroy the document editor.
solprovider
Re: Fun with textarea-Elements
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Rainer Schöpf wrote:
> On Wed, 26 Nov 2008 at 15:36 -0600, Richard Frovarp wrote:
>
> > Rainer Schöpf wrote:
> > > On Wed, 26 Nov 2008 at 11:19 -0600, Richard Frovarp wrote:
> >
> > > > > Which browsers have issues? I'm issuing XHTML strict without issue.
> > >
> > > Try inserting an empty textarea-Element.
> > >
> > > Doesn't work in Firefox 3 nor in IE7.
> > >
> > > Rainer
> > >
> > >
> >
> > Are you talking empty as in <textarea></textarea> or </textarea>? The second
> > one is not valid XHTML. There is an issue with the generator collapsing the
> > elements because it is perfectly valid XML to do so. But if you were to have
> > proper XHTML, FF3 and IE7 would render it fine.
> >
> > Richard
>
> Empty as in <textarea></textarea>. Someone created a document containing exactly
> that. The generator collapses it and the browser gets confused.
>
> Rainer
>
>
Yeah, but at that point it isn't XHTML anymore. There is a difference
between properly formed XHTML and what this generator dumps out. The
generator is following the rules of XML, which are not the rules of
XHTML. So the problem isn't with XHTML, the problem is with the
generator creating things that aren't really XHTML. solprovider's
generator may be what's needed.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
On Wed, 26 Nov 2008 at 15:36 -0600, Richard Frovarp wrote:
> Rainer Sch�pf wrote:
> > On Wed, 26 Nov 2008 at 11:19 -0600, Richard Frovarp wrote:
>
> > > > Which browsers have issues? I'm issuing XHTML strict without issue.
> >
> > Try inserting an empty textarea-Element.
> >
> > Doesn't work in Firefox 3 nor in IE7.
> >
> > Rainer
> >
> >
>
> Are you talking empty as in <textarea></textarea> or </textarea>? The second
> one is not valid XHTML. There is an issue with the generator collapsing the
> elements because it is perfectly valid XML to do so. But if you were to have
> proper XHTML, FF3 and IE7 would render it fine.
>
> Richard
Empty as in <textarea></textarea>. Someone created a document containing exactly
that. The generator collapses it and the browser gets confused.
Rainer
Re: Fun with textarea-Elements
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Rainer Schöpf wrote:
> On Wed, 26 Nov 2008 at 11:19 -0600, Richard Frovarp wrote:
> >
> > Which browsers have issues? I'm issuing XHTML strict without issue.
>
> Try inserting an empty textarea-Element.
>
> Doesn't work in Firefox 3 nor in IE7.
>
> Rainer
>
>
Are you talking empty as in <textarea></textarea> or </textarea>? The
second one is not valid XHTML. There is an issue with the generator
collapsing the elements because it is perfectly valid XML to do so. But
if you were to have proper XHTML, FF3 and IE7 would render it fine.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
On Wed, 26 Nov 2008 at 11:19 -0600, Richard Frovarp wrote:
> Rainer Schöpf wrote:
> > Hi Jürgen,
> >
> > > Hi Rainer
> > > > Am 26.11.2008 um 10:20 schrieb Rainer Schöpf:
> > > > > On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
> > > > > > > This counters your first post stating the TEXTAREA element is
> > > > > collapsed.
> > > > > > No, it doesn't. As I explained in my first post, textarea
> > elements are
> > > > collapsed when using the default sitemap. By changing type="xml" to
> > > > type="html"
> > > > in map:serialize, I get the code shown in my last message.
> > > > > > > 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?
> >
> > Rainer
> >
>
> Which browsers have issues? I'm issuing XHTML strict without issue.
Try inserting an empty textarea-Element.
Doesn't work in Firefox 3 nor in IE7.
Rainer
Re: Fun with textarea-Elements
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Rainer Schöpf wrote:
> Hi Jürgen,
>
> > Hi Rainer
> >
> > Am 26.11.2008 um 10:20 schrieb Rainer Schöpf:
> >
> > > On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
> > >
> > > > This counters your first post stating the TEXTAREA element is
> > > > collapsed.
> > >
> > > No, it doesn't. As I explained in my first post, textarea elements are
> > > collapsed when using the default sitemap. By changing type="xml" to
> > > type="html"
> > > in map:serialize, I get the code shown in my last message.
> > >
> >
> >
> > 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?
>
> Rainer
>
Which browsers have issues? I'm issuing XHTML strict without issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by so...@apache.org.
On 11/26/08, Rainer Schöpf <ra...@proteosys.com> 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
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
Hi Florent,
yes, the purpose is to create a form, for submitting a paper for a conference.
Submission is not a problem if the URL points to another webserver.
I agree that using another mechanism (eg. Cocoon Forms) is preferable, but I
still need to implement that.
Rainer
On Thu, 27 Nov 2008, Florent André wrote:
> Hy,
>
> I have another silly question : What is the objective of the textarea
> creation ? Does your users want to create a form (with text field,
> textarea, radio button, and so on) ?
>
> And now, after the creation of the textareas, how can you submit your
> modification ?
>
> My idea behind this question is : how about create a dedicated module to
> form ? With this you can have the hand on the code generation and the "edit
> again"...
>
>
> Have a good day
>
>
> On Thu, 27 Nov 2008 08:35:28 +0100 (CET), Rainer Schöpf
> <ra...@proteosys.com> wrote:
> > On Wed, 26 Nov 2008 at 15:38 -0600, Richard Frovarp wrote:
> >
> > > Rainer Schöpf wrote:
> > >
> > > >
> > > > I'm at a loss how to proceed, except by disallowing insertion of
> > textarea
> > > > elements in the editor configuration.
> > > >
> > > > Maybge I've done something wrong, but I don't see what.
> > > >
> > > > Perhaps you could try the attached simple XHTML document and tell me
> > what
> > > > happens.
> > > >
> > > > Rainer
> > > >
> > >
> > > Maybe this is a silly question, but how do you edit pages that have
> > textareas
> > > in it? Wouldn't the closing textarea tag finish off the textarea that
> > the
> > > editor is working in? Or are there editors that can deal with this?
> >
> > That is indeed a problem.
> >
> > Bitflux works OK for editing, but I have still to find out how to create
> a
> > textarea in it.
> >
> > You can create such a document with TinyMCE, but not edit it again
> > properly: the
> > inner </textarea> ends the editable range.
> >
> > (My first reaction was to delete the entire document and recreate it.)
> >
> > Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
> For additional commands, e-mail: user-help@lenya.apache.org
>
>
--------------------------------------------------------
ProteoSys AG
Carl-Zeiss-Straße 51
55129 Mainz
Dr. Rainer Schöpf
Leiter Software/Softwareentwicklung
Mail: rainer.schoepf@proteosys.com
Phone: +49-(0)6131-50192-41
Fax: +49-(0)6131-50192-11
WWW: http://www.proteosys.com/
--------------------------------------------------------
ProteoSys AG - Carl-Zeiss-Str. 51 - D-55129 Mainz
Amtsgericht Mainz HRB 7508 - USt.-Id Nr.: DE213940570
Vorstand: Helmut Matthies (Vorsitzender), Prof. Dr. André Schrattenholz
Vorsitzender des Aufsichtsrates: Dr. Werner Zöllner
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by Florent André <fl...@4sengines.com>.
Hy,
I have another silly question : What is the objective of the textarea
creation ? Does your users want to create a form (with text field,
textarea, radio button, and so on) ?
And now, after the creation of the textareas, how can you submit your
modification ?
My idea behind this question is : how about create a dedicated module to
form ? With this you can have the hand on the code generation and the "edit
again"...
Have a good day
On Thu, 27 Nov 2008 08:35:28 +0100 (CET), Rainer Schöpf
<ra...@proteosys.com> wrote:
> On Wed, 26 Nov 2008 at 15:38 -0600, Richard Frovarp wrote:
>
> > Rainer Schöpf wrote:
> >
> > >
> > > I'm at a loss how to proceed, except by disallowing insertion of
> textarea
> > > elements in the editor configuration.
> > >
> > > Maybge I've done something wrong, but I don't see what.
> > >
> > > Perhaps you could try the attached simple XHTML document and tell me
> what
> > > happens.
> > >
> > > Rainer
> > >
> >
> > Maybe this is a silly question, but how do you edit pages that have
> textareas
> > in it? Wouldn't the closing textarea tag finish off the textarea that
> the
> > editor is working in? Or are there editors that can deal with this?
>
> That is indeed a problem.
>
> Bitflux works OK for editing, but I have still to find out how to create
a
> textarea in it.
>
> You can create such a document with TinyMCE, but not edit it again
> properly: the
> inner </textarea> ends the editable range.
>
> (My first reaction was to delete the entire document and recreate it.)
>
> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
On Wed, 26 Nov 2008 at 15:38 -0600, Richard Frovarp wrote:
> Rainer Sch�pf wrote:
>
> >
> > I'm at a loss how to proceed, except by disallowing insertion of textarea
> > elements in the editor configuration.
> >
> > Maybge I've done something wrong, but I don't see what.
> >
> > Perhaps you could try the attached simple XHTML document and tell me what
> > happens.
> >
> > Rainer
> >
>
> Maybe this is a silly question, but how do you edit pages that have textareas
> in it? Wouldn't the closing textarea tag finish off the textarea that the
> editor is working in? Or are there editors that can deal with this?
That is indeed a problem.
Bitflux works OK for editing, but I have still to find out how to create a
textarea in it.
You can create such a document with TinyMCE, but not edit it again properly: the
inner </textarea> ends the editable range.
(My first reaction was to delete the entire document and recreate it.)
Rainer
Re: Fun with textarea-Elements
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Rainer Schöpf wrote:
>
> I'm at a loss how to proceed, except by disallowing insertion of textarea
> elements in the editor configuration.
>
> Maybge I've done something wrong, but I don't see what.
>
> Perhaps you could try the attached simple XHTML document and tell me what
> happens.
>
> Rainer
>
Maybe this is a silly question, but how do you edit pages that have
textareas in it? Wouldn't the closing textarea tag finish off the
textarea that the editor is working in? Or are there editors that can
deal with this?
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
Hi Jürgen,
> Hello Rainer
>
> Am 26.11.2008 um 11:10 schrieb Rainer Schöpf:
>
> > Hi Jürgen,
> >
> > > Hi Rainer
> > >
> > > Am 26.11.2008 um 10:20 schrieb Rainer Schöpf:
> > >
> > > > On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
> > > >
> > > > > This counters your first post stating the TEXTAREA element is
> > > > > collapsed.
> > > >
> > > > No, it doesn't. As I explained in my first post, textarea elements are
> > > > collapsed when using the default sitemap. By changing type="xml" to
> > > > type="html"
> > > > in map:serialize, I get the code shown in my last message.
> > > >
> > >
> > >
> > > 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.
> I wouldn't use the html serializer (outdated not future proof code).
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.
Maybge I've done something wrong, but I don't see what.
Perhaps you could try the attached simple XHTML document and tell me what
happens.
Rainer
Re: Fun with textarea-Elements
Posted by =?...@athena.apache.org,
_privat=22?= <jr...@datacomm.ch>.
Hello Rainer
Am 26.11.2008 um 11:10 schrieb Rainer Schöpf:
> Hi Jürgen,
>
>> Hi Rainer
>>
>> Am 26.11.2008 um 10:20 schrieb Rainer Schöpf:
>>
>>> On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
>>>
>>>> This counters your first post stating the TEXTAREA element is
>>>> collapsed.
>>>
>>> No, it doesn't. As I explained in my first post, textarea
>>> elements are
>>> collapsed when using the default sitemap. By changing type="xml" to
>>> type="html"
>>> in map:serialize, I get the code shown in my last message.
>>>
>>
>>
>> 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.
I wouldn't use the html serializer (outdated not future proof code).
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
Hi Jürgen,
> Hi Rainer
>
> Am 26.11.2008 um 10:20 schrieb Rainer Schöpf:
>
> > On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
> >
> > > This counters your first post stating the TEXTAREA element is
> > > collapsed.
> >
> > No, it doesn't. As I explained in my first post, textarea elements are
> > collapsed when using the default sitemap. By changing type="xml" to
> > type="html"
> > in map:serialize, I get the code shown in my last message.
> >
>
>
> 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?
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by Jürgen Ragaller <ra...@apache.org>.
Hi Rainer
Am 26.11.2008 um 10:20 schrieb Rainer Schöpf:
> On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
>
>> This counters your first post stating the TEXTAREA element is
>> collapsed.
>
> No, it doesn't. As I explained in my first post, textarea elements
> are
> collapsed when using the default sitemap. By changing type="xml" to
> type="html"
> in map:serialize, I get the code shown in my last message.
>
Did you try the xhtml serializer?
http://cocoon.apache.org/2.1/userdocs/xhtml-serializer.html
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
On Wed, 26 Nov 2008, solprovider@apache.org wrote:
> On 11/26/08, Rainer Schöpf <ra...@proteosys.com> wrote:
> > On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
> > > This counters your first post stating the TEXTAREA element is
> > > collapsed.
> >
> > No, it doesn't. As I explained in my first post, textarea elements are
> > collapsed when using the default sitemap. By changing type="xml" to type="html"
> > in map:serialize, I get the code shown in my last message.
> >
> > So, my question is: what are the problems with this approach? You seem to say
> > that it's not good enough, because of cocoon's limitations.
> > Rainer
>
> I missed some information.
> Which serializer had the problem?
> Which serializer are you using now? Does the problem still appear?
>
> The HTMLSerializer is usually the final step.
> The XHTMLSerializer requires browsers that understand XHTML.
> The XMLSerializer is used mostly for internal pipelines, not for
> sending webpages to a browser.
>
> HTTP's content-type header must match the data. Do not claim XHTML is
> "text/html"; use "application/xhtml+xml". (My guess why not
> "text/xhtml" is committees.)
I see now where our misunderstanding comes from.
When I install lenya 2.0.2 from source, it references in its toplevel
sitemap.xmap file only the classes XMLSerializer and the HTMLSerializer. There
are two variants of the XMLSerializer:
"xhtml" with mime-type text/html
"xml" with mime-type text/xml
In the default publication's sitemap.xmap the second one is used for internal
pipelines, the first one for the final step. The HTMLSerializer is _not_ used.
As a consequence, empty elements like textarea area collapsed, leading to
disappearing text or out of order display.
In my test publication, I use the HTMLSerializer for the final step, and the
page looks as I expect it. (Actually it is a bit more work, since the sitemaps
for several modules like tinymce need to be changed as well.)
So, I wonder whether the default publication should be changed likewise.
Thanks,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by so...@apache.org.
On 11/26/08, Rainer Schöpf <ra...@proteosys.com> wrote:
> On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
> > This counters your first post stating the TEXTAREA element is
> > collapsed.
>
> No, it doesn't. As I explained in my first post, textarea elements are
> collapsed when using the default sitemap. By changing type="xml" to type="html"
> in map:serialize, I get the code shown in my last message.
>
> So, my question is: what are the problems with this approach? You seem to say
> that it's not good enough, because of cocoon's limitations.
> Rainer
I missed some information.
Which serializer had the problem?
Which serializer are you using now? Does the problem still appear?
The HTMLSerializer is usually the final step.
The XHTMLSerializer requires browsers that understand XHTML.
The XMLSerializer is used mostly for internal pipelines, not for
sending webpages to a browser.
HTTP's content-type header must match the data. Do not claim XHTML is
"text/html"; use "application/xhtml+xml". (My guess why not
"text/xhtml" is committees.)
If your pages appear correctly, please ignore my comments.
If you have a problem, the first check should be which Serializer is
used. When I was testing the new SimpleHTMLSerializer, some pages
were not using it because the final serialization was to XML. My
error -- I believed map:mount returned to the calling XMAP. Firefox
displayed these pages as HTML. MSIE correctly displayed XML -- using
the specified content-type -- which led to finding the problem.
"The rest of the page disappearing" is often caused by collapsed
elements. I most often see this with collapsed SCRIPT elements in the
HEAD hiding the entire page.
HTH,
solprovider
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
On Tue, 25 Nov 2008 at 23:57 -0500, solprovider@apache.org wrote:
> This counters your first post stating the TEXTAREA element is
> collapsed.
No, it doesn't. As I explained in my first post, textarea elements are
collapsed when using the default sitemap. By changing type="xml" to type="html"
in map:serialize, I get the code shown in my last message.
So, my question is: what are the problems with this approach? You seem to say
that it's not good enough, because of cocoon's limitations.
> Have you solved the problem or is your browser fixing the
> HTML?
I think, it's the former. At least, the result (ie. the visible page) seems ok,
which it doesn't with the default sitemap.
> Firefox's View Source has two problems:
> 1. Resubmits the request -- bad when debugging POST requests.
> 2. What you see is not what the server sent. The HTML is parsed and cleaned.
I looked at it both with View Source and through the firebug extension which
doesn't resubmit the request. I'm not sure about your second point. I admit that
I haven't checked.
> Is the problem only with TEXTAREAs created with TinyMCE? Someone else
> may need to assist.
I tried kupu as well. I haven't systematically tried all combinations, but I
looked at the XHTML in the publication's content subtree. So I have a pretty
good idea what comes from the editor and what not.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by so...@apache.org.
On 11/25/08, Rainer Schöpf <ra...@proteosys.com> wrote:
> On Tue, 25 Nov 2008, solprovider@apache.org wrote:
> > 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.
> That's not my point. "Users" in this context are the editors. The problem ist
> that you _must not_ create an empty textarea if you want to be able to use
> or even only edit it.
>
> I agree that it doesn't matter for the final form.
Different architectures. Mine requires TEXTAREAs to exist so the
RichText editor (Xinha) knows where to display.
> > 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.
> Interestingly, this is not what I see, when I use
> <map:serialize type="html"/>
> in sitemap.xmap (in lenya 2.02).
Both Lenya 1.2 and 2.0 use:
org.apache.cocoon.components.serializers.HTMLSerializer
Lenya 2.0 adds this parameter:
<doctype-default>loose</doctype-default>
> Instead, I get this HTML code:
> <TABLE>
> <TR>
> <TD valign="top">Thema:</TD>
> <TD>
> <TEXTAREA cols="60" name="thema" rows="3"></TEXTAREA>
> </TD>
> </TR>
> <TR>
> <TD>Zeitbedarf:<BR> (inkl. Diskussion)</TD>
> <TD valign="top"> <INPUT name="zeit" type="text"> min.</TD>
> </TR>
> <TR>
> <TD>Benötigt werden:</TD>
> <TD>
> <INPUT name="equipment" type="text">
> </TD>
> </TR>
> <TR>
> <TD colspan="2">(z. B. Beamer, Notebook mit Acrobat Reader, Tafel)</TD>
> </TR>
> </TABLE>
> Rainer
This counters your first post stating the TEXTAREA element is
collapsed. Have you solved the problem or is your browser fixing the
HTML? Firefox's View Source has two problems:
1. Resubmits the request -- bad when debugging POST requests.
2. What you see is not what the server sent. The HTML is parsed and cleaned.
Is the problem only with TEXTAREAs created with TinyMCE? Someone else
may need to assist.
solprovider
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
On Tue, 25 Nov 2008, solprovider@apache.org wrote:
> 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.
That's not my point. "Users" in this context are the editors. The problem ist
that you _must not_ create an empty textarea if you want to be able to use
or even only edit it.
I agree that it doesn't matter for the final form.
> 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.
Interestingly, this is not what I see, when I use
<map:serialize type="html"/>
in sitemap.xmap (in lenya 2.02).
Instead, I get this HTML code:
<TABLE>
<TR>
<TD valign="top">Thema:</TD>
<TD>
<TEXTAREA cols="60" name="thema" rows="3"></TEXTAREA>
</TD>
</TR>
<TR>
<TD>Zeitbedarf:<BR> (inkl. Diskussion)</TD>
<TD valign="top"> <INPUT name="zeit" type="text"> min.</TD>
</TR>
<TR>
<TD>Benötigt werden:</TD>
<TD>
<INPUT name="equipment" type="text">
</TD>
</TR>
<TR>
<TD colspan="2">(z. B. Beamer, Notebook mit Acrobat Reader, Tafel)</TD>
</TR>
</TABLE>
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: Fun with textarea-Elements
Posted by so...@apache.org.
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 <ra...@proteosys.com> 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, solprovider@apache.org 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
> > <ra...@proteosys.com> 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
Re: Fun with textarea-Elements
Posted by Rainer Schöpf <ra...@proteosys.com>.
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, solprovider@apache.org 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
> <ra...@proteosys.com> 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
Re: Fun with textarea-Elements
Posted by so...@apache.org.
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
<ra...@proteosys.com> 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