[whatwg] Textareas

Csaba Gabor csaba2000 at yahoo.com
Sun Apr 2 17:38:03 PDT 2006


I've run into some issues with textareas and after checking
http://www.w3.org/Submission/web-forms2/ and seeing that the mailing list is active...

1. I always thought that cols, which has been around forever, was advisory regarding width, in
the sense that if there was no other overriding factor (CSS style settings), then cols would
dictate the width of the textarea, and that would be the end of it.
I further thought that .wrap=hard meant that the newlines that were sent to the server reflected
exactly what the user saw / how the text was arranged in the textarea in the sense that there
was exactly and only 1 newline (%0D%0A) exactly between each adjacent (possibly empty) pair of
lines.

Indeed, this is the behaviour that IE 6 exhibits on my Win XP Pro system.  So when I saw that
the linefeeds that FF was putting in were not reflecting what I was seeing on the screen I filed
a bug report against it.  Only afterwards did I come back to web-forms2 to review it, and was
shocked by what I read:

To paraphrase, it seems that cols is no longer simply advisory for (only) determining the width
of the textarea.  With .wrap=hard it says that the breaks should be dictated by the value of
cols (and that if cols doesn't exist, the breaks should be dictated by the size of the textarea
(I presume that's what "display width" means).  It further goes on to say that this is anyways
not a good thing because users have different size displays so everyone's wrapping position
would be different, defeating the purpose of client side wrapping).

Now, I am really wondering about that whole paragraph, my paraphrasing not withstanding.  First
of all, 'defeating the purpose of client side wrapping' begs the question of what is the purpose
of .wrap?  It's pretty clearly not something for the client side, right?, since there is no
visible difference to the user while working with a textarea (there would be if .wrap=off, but
that is not covered here).  So if it's not useful for the client, it should be useful for the
server.  How?

Ensuring that text is broken up every cols characters is a pretty trivial function (by this I
mean that it is trivial to do server side) that does not serve much purpose in having it done on
the client side.  On the other hand, it is very useful information to know what the user was
seeing so that what is processed on the server side has some correlation to what the user
submitted.  This is the dichotomy between how .wrap has been used so far - either delivering
what the user saw (.wrap=hard) or what the user intends to be seen (.wrap=soft), making it
useful for both sides.

You can't deduce server side what the user saw client side, even assuming you know how wide the
textarea is by any other means - the user might not even be using a fixed width font -
.wrap=hard serves a very useful purpose here.  And I don't see that the argument is any
different whether or not cols has been set.  In addition, there are millions of sites out there
with .cols set because it must be (because cols has been mandatory for so long).  These people
will be in for a rude awakening indeed, to find out that cols now means something completely
different.  But I think I'd be even more annoyed as a user, it being  as if I was chopped off in
mid

In short, I have outlined a compelling reason to have .wrap behave as it does on IE6 vs. a
passing comment about the purpose of client side wrapping.  In short, I am asking where this
most peculiar mandate about .wrap=hard came from and expressing my strong disagreement with what
I understand so far.


2.  As long as I am writing, I may as well ask about another textarea issue that has always
seemed strangely absent.  Why is it that there is no way to find out what will actually be
transmitted from a textarea.  Seems to me that the client (javascript) might be at least as
interested in this as the server cgi.  It would be useful to know what row and column one was on
in the textarea.  Of course, it is possible to know what row one is on within the .value
(because you can figure out where the caret is, and then count preceding \n's), but with
wrapping, these two are different, and you don't really know for sure where things are being
wrapped.  Therefore, it would be exceptionally useful to have something like .observedValue to
reflect what is being seen.  In IE, I think I can figure this out via some range monkeying about
(since they allow for rangeHeight (or something like that)), but I am stumped with Mozilla/FF.

Csaba Gabor from Vienna

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



More information about the whatwg mailing list