Re: HTML 3.2 PR TEXTAREA WRAP attribute

Carl Morris (msftrncs@htcnet.com)
Tue, 12 Nov 1996 16:49:58 -0600


Message-Id: <199611122250.QAA06057@inet.htcnet.com>
From: "Carl Morris" <msftrncs@htcnet.com>
To: "Benjamin Franz" <snowhare@netimages.com>,
Subject: Re: HTML 3.2 PR TEXTAREA WRAP attribute
Date: Tue, 12 Nov 1996 16:49:58 -0600

| 
| Unless it is being used to communicate with people,
| in which 
| is is vital that the server know how it appeared to
| the person
| entering the text. As you might have noticed, it
| is incrediblely
| annoying to get 'longline/shortline' when reading
| something.
| In fact, it can almost make it unreadable.
| 
| 
| Got a headache yet? The point is that it can be 
| *VERY* important 
| that a server know where the browser wrapped the 
| lines. And 
| *whether or not* it goes into the 3.2 DTD, professional
| designers know 
| this and will continue to use WRAP=HARD to reduce the 
| number of 
| unexpected surprises.


NO!  The browser doesn't even know where it wrapped... MSIE always
wraps the text in a TEXTAREA, and does not tell the server where...
this is the ultimate is design.  It is then 100% up to the server to
brake(damn I can't spell the right one) the long lines down...  The
user should not be required to guess or be forced to his browsers
chose.

My browser might just reply

hello this
is how I
am going to
wrap this
TEXTAREA.
Mad at me 
yet?

when using some funny wrap.  But it doesn't, instead it sends one huge
long line.  CGI data is traditionally one long URL encoded line...  I
have processed this stuff in DOS CGI's and can see no reason to change.
 A browser such as Netscape simply needs to clean up its BUGGY
interface with not wrapping things.

| 
| </'server doesn't know where browser EOL is' simulation mode>
| 
| > | 	* It is necessary for forms that expect input for traditional
| > | 	  email applications.
| > 
| > FORMS must assume that they will have to truncate the data to 72
| > character lines.  MSIE does not take the WIDTH attribute literally,
72
| > characters to MSIE creates a BOX half the width of the screen, and
then
| > uses a PS font, and may actually fit only 40 characters, or 140
| > characters in to the box per line ... you never know. 
| 
| I should hope so. Since the relevant attribute is 'MAXLENGTH'. There
is no
| 'WIDTH" attribute for INPUT tags. And MSIE DOES honor MAXLENGTH. Try
it.

Wrong, TEXTAREA has a WIDTH tag ... MAXLENGTH is exactly that, and only
applies to INPUT, and no browser I have tried supports multiline INPUT

| You are thinking 'automated tool processing form data via email' when
what
| the problem is is 'mail intended to be read by humans'.  Believe me -
I
| *KNOW* what I am doing when I use forms and *still* get bitten by the
| 'browser and server disagree on where the end of lines are' problem.
| WRAP=HARD works in the browsers *most* people use today. And the
| consequences for those who use browsers that do not honor it is *no
worse*
| than if it didn't exist at all. 

Form data IS NOT INTENDED FOR HUMANS...  The idea of even emailing it
is a bad idea... now if your CGI creates a nice e-mail out of the data,
thats another story, your app can wrap the text, not the user and his
browser, or you can let the recipient WRAP the text, in the case of
quoted/printable.

| Because automated splitting _usually_ produces email that is damn
near
| unreadable. WRAP=HARD insures that line breaks usually occur *where
they
| are expected to*. The 'line breaks happen only where someone hit
return or
| when we reach column 72' model usually insures human unusable output
| instead. Is is a _guarantee_ that line breaks will _always_ happen
where
| expected? No. But is is clearly an improvement over line breaks
almost
| _never_ occur where expected. 
| 
| The WRAP attribute should be formally added to the DTD. 

Only because you have used NETSCAPE and their buggy TEXTAREA and
e-mail.  Try a Microsoft solution and you will never notice any of
these problems.  Their e-mail apps wrap text to the screen, their
browser, as per the spec, wraps TEXTAREA...  I think the spec stands
fine where it is, and MS proves it can be done better than Netscape
when the spec is follow, not lead.