Re: HTML 3.2 PR TEXTAREA WRAP attribute

Benjamin Franz (
Tue, 12 Nov 1996 05:01:20 -0800 (PST)

Date: Tue, 12 Nov 1996 05:01:20 -0800 (PST)
From: Benjamin Franz <>
To: Carl Morris <>
cc: "Kevin 'Kev' Hughes" <>, WWW HTML List <>
Subject: Re: HTML 3.2 PR TEXTAREA WRAP attribute
In-Reply-To: <>
Message-ID: <>

On Mon, 11 Nov 1996, Carl Morris wrote:

> Because the server has no use knowing where the browser chose to wrap,
> absolutely no use.

<'server doesn't know where browser EOL is' simulation mode>

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

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

> not something reliable enough for an email CGI to expect the formdata
> at exactly what it told the browser... thats not even a moral of
> HTML...

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. 

> | 	* It is necessary for applications that require line breaks
> | 	  within input.
> CGI's process all their data as one HUGE line....  whats wrong with the
> CGI deciding where to split the data, uh?

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. 

Benjamin Franz