Message-Id: <199611122250.QAA06057@inet.htcnet.com> From: "Carl Morris" <email@example.com> To: "Benjamin Franz" <firstname.lastname@example.org>, 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.