[whatwg] Textareas

[Ian Hickson]

On Sun, 2 Apr 2006, Csaba Gabor wrote:
> 
> 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).

With you so far.


> 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.

If it's done on the client side, the user can see how it will wrap, which 
is important if it's going to screw up the user's formatting.


> 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

I don't think the "new" behaviour is actually any different in practice, 
is it? It's just a grandfathering of the meaning.


> 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.

I don't understand the difference between what IE6 does and what the spec 
says should happen.


> 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.

I'm not 100% sure what you're asking for, but we will be adding features 
to control the cursor position in HTML5.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'