- From: Benjamin Franz <snowhare@netimages.com>
- Date: Tue, 12 Nov 1996 05:01:20 -0800 (PST)
- To: Carl Morris <msftrncs@htcnet.com>
- cc: "Kevin 'Kev' Hughes" <kevinh@eit.com>, WWW HTML List <www-html@w3.org>
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 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. </'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. > a TEXTAREA is > 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
Received on Tuesday, 12 November 1996 08:01:17 UTC