By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,738 Members | 1,730 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,738 IT Pros & Developers. It's quick & easy.

<textarea ... />

P: n/a

Hi all,

I just had a problem where Mozilla 1.6 did not accept a XHTML 1.0 page
that contained

<p><textarea cols="50" name="prod_prob_description" rows="4" /></p>

It did not accept the end tag />, but selected everything after til the
EOF as text within the textarea.

I tried to understand the standard which claims that an end tag is
required. The example names the ending element only: </textarea>.

I did not find a real declaration where and how to apply the short
version of /> within the element.

Is it a browser error or a HTML design error? Where's the matching
definition of the end tag, if not
http://www.w3.org/TR/1999/REC-html40...224/html40.txt ?

Thanks,
Martin
Jul 23 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a
Martin Trautmann <t-***@gmx.net> wrote:
I just had a problem where Mozilla 1.6 did not accept a XHTML 1.0 page
that contained

<p><textarea cols="50" name="prod_prob_description" rows="4" /></p>
Whilst that is allowed under XHTML it is recommended against,
especially if you were serving the page as text/html and applying the
other Appendix C hacks to make browsers think that it's HTML.
It did not accept the end tag />, but selected everything after til the
EOF as text within the textarea.
My guess (as you didn't supply a URL) is that you are serving your
pages as text/html and thus Mozilla is treating them as HTML.
I tried to understand the standard which claims that an end tag is
required. The example names the ending element only: </textarea>.
Which standard? In HTML the end tag is required for textarea.
<!ELEMENT TEXTAREA - - (#PCDATA) -- multi-line text field -->
The - - means that both start and end tags are required.
I did not find a real declaration where and how to apply the short
version of /> within the element.
In XHTML all elements are required to be closed. That can be done by
either including the end tag or by terminating the start tag with />.

However for documents on the WWW which must be compatable with HTML
user agents you are recommended to use the end tag for all elements
that are not declared as empty. See http://www.w3.org/TR/xhtml1/#C_3
Textarea is not declared as empty.
Is it a browser error or a HTML design error? Where's the matching
definition of the end tag, if not
http://www.w3.org/TR/1999/REC-html40...224/html40.txt ?


That's the HTML 4 spec, I thought you said you were using XHTML 1.0?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Jul 23 '05 #2

P: n/a
Martin Trautmann <t-***@gmx.net> wrote:
I just had a problem where Mozilla 1.6 did not accept a XHTML 1.0 page
that contained

<p><textarea cols="50" name="prod_prob_description" rows="4" /></p>

It did not accept the end tag />, but selected everything after til the
EOF as text within the textarea.

I tried to understand the standard which claims that an end tag is
required. The example names the ending element only: </textarea>.

I did not find a real declaration where and how to apply the short
version of /> within the element.
Non empty elements like textarea should not be quick closed, doing so
should work when xhtml is served as xhtml, but doing so when serving it
as text/html could easily cause problems.
Is it a browser error or a HTML design error?


It's one of the problems associated with using xhtml, quick closing non
empty elements is no longer recognized as an error by a validator. Stop
lying to yourself and browsers and use html strict.

--
Spartanicus
Jul 23 '05 #3

P: n/a
On Thu, 3 Mar 2005, Martin Trautmann wrote:
I just had a problem where Mozilla 1.6 did not accept a XHTML 1.0 page
Served as what media type? URL?
that contained

<p><textarea cols="50" name="prod_prob_description" rows="4" /></p>

It did not accept the end tag />
So don't do that.
, but selected everything after til the
EOF as text within the textarea.
Gosh, if I didn't know better, I'd start to think it really understood
SGML!
I tried to understand the standard which claims that an end tag is
required. The example names the ending element only: </textarea>.
So that's the answer.
I did not find a real declaration where and how to apply the short
version of /> within the element.
If and only if the element is self-terminating (such as <br />)
Is it a browser error or a HTML design error?


More likely a failure by the document author to apply the rules of
XHTML/1.0 Appendix C (assuming that you're serving this out as
text/html).
Jul 23 '05 #4

P: n/a
On Thu, 03 Mar 2005 13:28:09 +0000, Steve Pugh wrote:
Martin Trautmann <t-***@gmx.net> wrote:
I just had a problem where Mozilla 1.6 did not accept a XHTML 1.0 page
that contained

<p><textarea cols="50" name="prod_prob_description" rows="4" /></p>


Whilst that is allowed under XHTML it is recommended against,
especially if you were serving the page as text/html and applying the
other Appendix C hacks to make browsers think that it's HTML.
It did not accept the end tag />, but selected everything after til the
EOF as text within the textarea.


My guess (as you didn't supply a URL) is that you are serving your
pages as text/html and thus Mozilla is treating them as HTML.


Yes, the page is served as text/html:
http://www.filemaker.com/company/product/problems.html
I tried to understand the standard which claims that an end tag is
required. The example names the ending element only: </textarea>.


Which standard? In HTML the end tag is required for textarea.
<!ELEMENT TEXTAREA - - (#PCDATA) -- multi-line text field -->
The - - means that both start and end tags are required.


I checked in http://www.w3.org/TR/xhtml1/ first - but since I did not
find the ELEMENT declarations in there, I went over to HTML4.
I did not find a real declaration where and how to apply the short
version of /> within the element.


In XHTML all elements are required to be closed. That can be done by
either including the end tag or by terminating the start tag with />.

However for documents on the WWW which must be compatable with HTML
user agents you are recommended to use the end tag for all elements
that are not declared as empty. See http://www.w3.org/TR/xhtml1/#C_3
Textarea is not declared as empty.


Ah, thanks. I've seen now
http://www.w3.org/TR/xhtml1/dtds.htm...onal.dtd_input
as a possibly EMPTY element, while textarea is not EMPTY.
Is it a browser error or a HTML design error? Where's the matching
definition of the end tag, if not
http://www.w3.org/TR/1999/REC-html40...224/html40.txt ?


That's the HTML 4 spec, I thought you said you were using XHTML 1.0?


I took the wrong branch then.

Martin
Jul 23 '05 #5

P: n/a
On Thu, 03 Mar 2005 13:29:56 +0000, Spartanicus wrote:
Non empty elements like textarea should not be quick closed, doing so
should work when xhtml is served as xhtml, but doing so when serving it
as text/html could easily cause problems.


'should not' or 'SHOULD NOT' be quick closed?

Since it was served as text/html, this may be the explanation.
Is it a browser error or a HTML design error?


It's one of the problems associated with using xhtml, quick closing non
empty elements is no longer recognized as an error by a validator. Stop
lying to yourself and browsers and use html strict.


Hm - looks like a validator behavior that could be more strict, too.

Thanks,
Martin
Jul 23 '05 #6

P: n/a
On Thu, 3 Mar 2005 13:34:09 +0000, Alan J. Flavell wrote:
On Thu, 3 Mar 2005, Martin Trautmann wrote:
I just had a problem where Mozilla 1.6 did not accept a XHTML 1.0 page


Served as what media type? URL?


as mentionned before by now:
http://www.filemaker.com/company/product/problems.html

served as text/html
It did not accept the end tag />


So don't do that.


It's not mine, I don't have a choice.

Thanks,
Martin
Jul 23 '05 #7

P: n/a
Martin Trautmann <t-***@gmx.net> wrote:
Non empty elements like textarea should not be quick closed, doing so
should work when xhtml is served as xhtml, but doing so when serving it
as text/html could easily cause problems.
'should not' or 'SHOULD NOT' be quick closed?


Capitalization changes nothing.
Since it was served as text/html, this may be the explanation.
>Is it a browser error or a HTML design error?


It's one of the problems associated with using xhtml, quick closing non
empty elements is no longer recognized as an error by a validator. Stop
lying to yourself and browsers and use html strict.


Hm - looks like a validator behavior that could be more strict, too.


No it couldn't. The spec prose says that non empty elements should not
be quick closed, but it's not an error as per the dtd.

--
Spartanicus
Jul 23 '05 #8

P: n/a
On Thu, 03 Mar 2005 14:55:24 +0000, Spartanicus wrote:
Martin Trautmann <t-***@gmx.net> wrote:
Non empty elements like textarea should not be quick closed, doing so
should work when xhtml is served as xhtml, but doing so when serving it
as text/html could easily cause problems.


'should not' or 'SHOULD NOT' be quick closed?


Capitalization changes nothing.


It's the RFC style, claiming that you really should not do so, but doing
it anyway if your reasons are very well rethought.
Hm - looks like a validator behavior that could be more strict, too.


No it couldn't. The spec prose says that non empty elements should not
be quick closed, but it's not an error as per the dtd.


? I don't understand the description very well. But I don't see a weak
'should not', but

http://www.w3.org/TR/xhtml1/#h-4.3
XML does not allow end tags to be omitted. All elements other than those
declared in the DTD as EMPTY must have an end tag. Elements that are
declared in the DTD as EMPTY can have an end tag or can use empty
element shorthand (see Empty Elements).

Is there an inversion of this sentence for Elements, that are not
declared as EMPTY so that they can NOT use the empty element shorthand?
Or is this the lack of further specification which is read as 'should
not'?

http://www.w3.org/TR/xhtml1/#guidelines
C. HTML Compatibility Guidelines
C.3. Element Minimization and Empty Element Content

Given an empty instance of an element whose content model is not EMPTY
(for example, an empty title or paragraph) do not use the minimized
form (e.g. use <p> </p> and not <p />).
Martin
Jul 23 '05 #9

P: n/a
Spartanicus <me@privacy.net> wrote:
The spec prose says that non empty elements should not
be quick closed


Oops, it's in the compatibility guidelines, not in the spec.

--
Spartanicus
Jul 23 '05 #10

P: n/a
Martin Trautmann <t-***@gmx.net> wrote:
>'should not' or 'SHOULD NOT' be quick closed?


Capitalization changes nothing.


It's the RFC style, claiming that you really should not do so, but doing
it anyway if your reasons are very well rethought.


w3c uses different terminology: http://www.w3.org/TR/xhtml1/#defs
>Hm - looks like a validator behavior that could be more strict, too.


No it couldn't. The spec prose says that non empty elements should not
be quick closed, but it's not an error as per the dtd.


? I don't understand the description very well. But I don't see a weak
'should not', but

http://www.w3.org/TR/xhtml1/#h-4.3
XML does not allow end tags to be omitted. All elements other than those
declared in the DTD as EMPTY must have an end tag. Elements that are
declared in the DTD as EMPTY can have an end tag or can use empty
element shorthand (see Empty Elements).


Mhhh, that could be classified as an error, depending on how you define
"end tag". A quick closed element can be said to be a start &end tag in
one, but imo it's incorrect to refer to it as and "end tag".

--
Spartanicus
Jul 23 '05 #11

P: n/a
On Thu, 03 Mar 2005 15:45:32 +0000, Spartanicus wrote:
http://www.w3.org/TR/xhtml1/#h-4.3
XML does not allow end tags to be omitted. All elements other than those
declared in the DTD as EMPTY must have an end tag. Elements that are
declared in the DTD as EMPTY can have an end tag or can use empty
element shorthand (see Empty Elements).


Mhhh, that could be classified as an error, depending on how you define
"end tag". A quick closed element can be said to be a start &end tag in
one, but imo it's incorrect to refer to it as and "end tag".


My problem as a non-native English speaker is the problem how to look
for the proper definition of the end at all. It's referred to as
'shorthand', 'end tag', 'empty end tag', 'end of empty elements',
'minimized form', 'minimized tag', 'shorthand markup', 'shorttag' etc.

First of all I did not notice the relation between 'EMPTY' and end tags,
then I missed a kind or real name for the "/>", named the same wherever
it is used. Add my confusion whether to add a space before.

Most of this is clear by now.

But I still don't understand whether saying nothing about 'shorthand end
tags' in non-EMPTY elements either means they are undefined (and
optional) or are not permitted.
Jul 23 '05 #12

P: n/a
On Thu, 3 Mar 2005, Martin Trautmann wrote:
My problem as a non-native English speaker is the problem how to
look for the proper definition of the end at all.
de.comm.infosystems.www.authoring.misc ("dciwam") also has XHTML
specialists, if that helps.
But I still don't understand whether saying nothing about 'shorthand
end tags' in non-EMPTY elements either means they are undefined (and
optional) or are not permitted.


I thought that has already been explained on this thread. They are
incompatible with XHTML served as text/html, which is why XHTML/1.0
Appendix C says don't use them. http://www.w3.org/TR/xhtml1/#C_3

Later versions of XHTML either deprecate the use of text/html or
forbid it. But that's not going to be useful in a general WWW
situation yet.
Jul 23 '05 #13

P: n/a
On Thu, 3 Mar 2005 16:54:04 +0000, Alan J. Flavell wrote:
But I still don't understand whether saying nothing about 'shorthand
end tags' in non-EMPTY elements either means they are undefined (and
optional) or are not permitted.
I thought that has already been explained on this thread. They are
incompatible with XHTML served as text/html, which is why XHTML/1.0
Appendix C says don't use them. http://www.w3.org/TR/xhtml1/#C_3


Appendix C is on "don't use them for compatibility"!?
However, my question was: why doesn't the validator complain about them?
I got the idea from the discussion here that actually it's not
forbidden. I wonder why it's not forbidden - since the aforementionned
XHTML1 standard here is unclear to me. Currently, there's your
compatibility argument 'don't use'. There's 'use for EMTPY'. And there's
the open space of either

- may be used for non-EMPTY elements, since it's not explicitly
forbidden
- should not be used (read as 'must not be used' for 'strict')
other than for 'EMPTY only'
- or even 'must not' be used.
Later versions of XHTML either deprecate the use of text/html or
forbid it.


That's yet another problem.

It's clear to me by now that the shorthand end tag should not have been
used here, although some more liberal browser might have been able to
cope with it.

The 'academic' problem is still open to me what actually is permitted,
since not forbidden.
Jul 23 '05 #14

P: n/a
in comp.infosystems.www.authoring.html, Martin Trautmann wrote:
On Thu, 3 Mar 2005 16:54:04 +0000, Alan J. Flavell wrote:
But I still don't understand whether saying nothing about 'shorthand
end tags' in non-EMPTY elements either means they are undefined (and
optional) or are not permitted.
I thought that has already been explained on this thread. They are
incompatible with XHTML served as text/html, which is why XHTML/1.0
Appendix C says don't use them. http://www.w3.org/TR/xhtml1/#C_3


Appendix C is on "don't use them for compatibility"!?
However, my question was: why doesn't the validator complain about them?


Because it validates against spec, not some informal appendix.
I got the idea from the discussion here that actually it's not
forbidden.
Correct.
I wonder why it's not forbidden - since the aforementionned
XHTML1 standard here is unclear to me.
Then use HTML, whiout X.
Later versions of XHTML either deprecate the use of text/html or
forbid it.


That's yet another problem.


No, that is solution.
The 'academic' problem is still open to me what actually is permitted,
since not forbidden.


It is not forbidden to use that <textarea/> and XHTML served as
text/html. It makes no sence, but it is allowed.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Jul 23 '05 #15

P: n/a
On Thu, 3 Mar 2005, Martin Trautmann wrote:
Appendix C is on "don't use them for compatibility"!?
Exactly. Serving XHTML as text/html is intended as a compatibility
feature, and should only be done by reference to the guidelines.
However, my question was: why doesn't the validator complain about them?
Because they are not invalid!
I got the idea from the discussion here that actually it's not
forbidden.
Right. Just that it isn't compatible with text/html browsers.
It's clear to me by now that the shorthand end tag should not have been
used here, although some more liberal browser might have been able to
cope with it.
These "liberal" browsers are incompatible with SGML.
The 'academic' problem is still open to me what actually is
permitted, since not forbidden.


Compatibility is heuristic, rather than academic. If you follow this
argument to its logical conclusion you will find that HTML and
XHTML/1.0-Appendix-C are internally self-contradictory. They only
work in practice - not in theory.

EOJ.

Jul 23 '05 #16

P: n/a
On Thu, 3 Mar 2005 17:28:39 +0000, Alan J. Flavell wrote:
Compatibility is heuristic, rather than academic. If you follow this
argument to its logical conclusion you will find that HTML and
XHTML/1.0-Appendix-C are internally self-contradictory. They only
work in practice - not in theory.


Thanks :-)

YMMD,
Martin
Jul 23 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.