Re: HTML 3.2 PR TEXTAREA WRAP attribute

Benjamin Franz (snowhare@netimages.com)
Tue, 12 Nov 1996 05:54:14 -0800 (PST)


Date: Tue, 12 Nov 1996 05:54:14 -0800 (PST)
From: Benjamin Franz <snowhare@netimages.com>
To: James Aylett <sja20@hermes.cam.ac.uk>
cc: "Kevin 'Kev' Hughes" <kevinh@eit.com>, www-html@w3.org
Subject: Re: HTML 3.2 PR TEXTAREA WRAP attribute
In-Reply-To: <Pine.LNX.3.93.961112131631.9265C-100000@crystal.clare.cam.ac.uk>
Message-ID: <Pine.LNX.3.95.961112054319.7306A-100000@ns.viet.net>

On Tue, 12 Nov 1996, James Aylett wrote:

> On Tue, 12 Nov 1996, Benjamin Franz wrote:
> 
> > Sure you have to validity check your data. *But you have to do that
> > *anyway*. No change in status. That is a null argument. 'You would have to 
> > do what you do anyway'. BUT - you have greatly improved the odds of the
> > data *already* being valid when you recieve it and reduced the chance of
> > the CGI doing something *unexpected to the user* due to invalid data.
> 
> That's only a partly fair point, as far as I'm concerned. If a CGI program
> can't cope with something which 8% of the population might throw at it,
> it's effectively useless - especially since dealing with a single unsplit
> line is so trivial. At this level of validation it is perfectly possible
> to write a parser which will never do anything unexpected, unless you
> start doing horrible things with the semantics of the data (in which case
> there are better ways of approaching things).

A) 'Single unsplit line'. Bad assumption. The real problems come up with
'a mixture of split and unsplit lines'. The is frequently caused by a
browser 'softwrapping' text. The *user* can't tell the difference between
a 'softwrapped' line and a 'hardreturn'. So they edit along, do a little
revising - and boom. Longline/shortline.

B) 'never do anything unexpected' *TO THE USER*. Not the programmer. It is
impossible without the use of something like 'WRAP=HARD' to meet this goal
because the *USER* expects that what they see is what will be sent. And
without WRAP=HARD - this is simply not true. At *best* the CGI can make
*guesses* about where the breaks should occur.

C) WRAP=HARD does not cause any *more* hardship for the 8% without
a browser that support it than no WRAP=HARD does. This *is* null.

-- 
Benjamin Franz