WebHeadStart.org is currently in beta. Please pardon our appearance as we work to provide you with the most comprehensive
reference on today's web technologies.
Interested in advertising on WebHeadStart? Become an advertising partner today!
> Briefly, what the specifications say has largely been overruled by
> implementations, so that you now need a nonstandard attribute
> (wrap="off")
> if you want to make browsers behave according to the "standard". See
> http://www.cs.tut.fi/~jkorpela/forms/textarea.html#wrap for
> an overview
> (somewhat dated, but paints the big picture, I hope).
I fought with the wrapping problem in the past as well, so I know exactly
what your are talking about, but my issue here is a bit different.
> > I'd like to display a text that starts with a CR in a TEXTAREA.
>
> Oh. The TEXTAREA element is for user input. There's no
> prohibition against
> using it for data display, but you should expect its implementation
> reflect is meaning and purpose.
Well, I appreciate that a TEXTAREA element is for user input,
but I don't think it is uncommon to allow the user to edit a
previously saved text. I assume that the TEXTAREA displays it's
contents as the initial text for this reason.
> > So, what should conforming HTML look like to display a text starting
> > with a CR in a TEXTAREA?
>
> They need not display it at all. But if they are visual user
> agents, they
> are expected to honor line breaks, including CR, so they
> should display an
> initial empty line in that case.
Why? If I write
<html>
<body>
this
is
several
lines
</body>
</html>
all users agents I know will render this as
this is several lines
The spec does not specify anywhere that text in a TEXTAREA
should behave any different.
> > <textarea>
> >
> > test
> > </textarea>
> >
> > seems to work for IE6/NS7, but doesn't in Opera 7.11.
>
> Could be a bug in 7.11. My Opera 7.23 shows an empty line.
I wouldn't call it a bug. They just picked a different
implementation that also complies to the standard. :-)
> > And, as a more general note, aren't user agents supposed to
> > collapse all sequences of white spaces also in a textarea
> > according to section 9.1, making it impossible to display
> > a preset text in a TEXTAREA that contains multiple spaces?
>
> It says "For all HTML elements except PRE", but apparently it
> should be
> "PRE and TEXTAREA". Just an oversight I guess. It is crucial
> for the very
> purpose of TEXTAREA to accept user input as such and transmit
> it, and it
> would be highly unnatural to display spaces as collapsed when
> they must be
> kept uncollapsed in the actual data to be sent. As a side effect, any
I completely agree on this and all user agents I know implement
sending the data the user has entered properly including all
white space.
> initial data in the TEXTAREA element should be treated the same way,
> obviously, especially since it too will be actually sent as
> such, unless
> changed by the user.
I agree, but NO browser implements this properly. Have a look
at the following JSP-example. It displays the contents of
what the browser sent to the JSP in a textarea. Now try to
enter text that starts with a CR and submit the page to itself.
test.jsp:
<%
String value = request.getParameter("myTest");
if (null == value) {
value = "";
};
%>
<html>
<body>
<form action="test.jsp" method="post">
<TEXTAREA name="myTest"><%= value %></TEXTAREA>
<INPUT type="submit" />
</form>
</body>
</html>
You'll see that the first empty line dissappears in all browsers,
although the JSP puts _EXACTLY_ the text that was sent
from the browser as the content for the TEXTAREA.
> Strangely enough, the sample style sheet for HTML 4.0 in the
> CSS 2 spec,
> http://www.w3.org/TR/REC-CSS2/sample.html
> contains
> PRE { white-space: pre }
> but nothing (!) for TEXTAREA. Another oversight, I guess.
>
> I'm afraid we just have to acknowledge that
> a) the implementations do not handle newlines as described in the spec
I agree on that one.
> b) there's an oversight in describing how whitespace is handled is
> TEXTAREA
That's the feeling I get, but I wonder why has noone ever correctly
specified the behavior for TEXTAREA. I can't be the first one to
stumble on that.
> c) people are probably not interested in improving the HTML 4
> specifications, since work is directed towards the XHTML 2
> activity, which
> means that HTML forms will be dropped out in favor of the XForms
> construct (which we might enjoy in the wild in the 2010s, I'd
> estimate).
I understand that but I wonder why there is no clearification
for XHTML 1.0 or at least XHTML 1.1, which are fairly new standards,
to make our life easier until XHTML 2 appears and is properly implemented
in all user agents.
Thanx for your answer!
Kind regards,
Guenther
