RE: TEXTAREA and white space, CR

> 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

Received on Thursday, 22 April 2004 07:34:23 UTC