W3C home > Mailing lists > Public > public-html@w3.org > September 2008

RE: [forms] control_element.value getter/setter newline normalization

From: Justin James <j_james@mindspring.com>
Date: Tue, 30 Sep 2008 12:20:28 -0400
To: "'Michael A. Puls II'" <shadow2531@gmail.com>, <public-html@w3.org>
Message-ID: <00df01c92318$73b8d4d0$5b2a7e70$@com>

No matter how you cut it, "this is a pretty crappy situation for interop" will apply. Clearly, we can't dictate the form of newline in the JavaScript spec (not that you suggested that). Nor can we dictate what the server thinks a newline character is. The internal representation of a GUI widget I would imagine is up to the standards of the OS (or the widget author, should they choose to override the OS's guidelines). And of course, some developers have a particular newline pattern beat into their heads, regardless of the fact that it is not standard across all platforms.

Not that I have any real solutions.

J.Ja

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Michael A. Puls II
> Sent: Tuesday, September 30, 2008 12:50 AM
> To: public-html@w3.org
> Subject: [forms] control_element.value getter/setter newline
> normalization
> 
> 
> Consider the following:
> 
> <script>
>     // Normalize stray \r and stray \n to \r\n
>     var ta = document.createElement("textarea");
>     var enableFix = false;
>     var newlines = /\r\n|\r|\n/g;
>     function getValue(textarea) {
>         if (enableFix) {
>             return textarea.value.replace(newlines, "\r\n");
>         }
>         return textarea.value;
>     }
>     function setValue(textarea, v) {
>         if (enableFix) {
>             textarea.value = v.replace(newlines, "\r\n");
>         } else {
>             textarea.value = v;
>         }
>     }
>     setValue(ta, "\n\r\n\r");
>     alert(encodeURIComponent(getValue(ta)));
> </script>
> 
> Without the fix:
> 
> Firefox: %0A%0D%0A%0D
> IE 8 beta 2: %0D%0A%0D%0A
> Safari: %0A%0A%0A
> Opera: %0D%0A%0D%0A%0D
> 
> With the fix:
> *: %0D%0A%0D%0A%0D%0A
> 
> Basically, Safari, Opera and IE 8 beta 2 all try to do some type of
> normalization on the newlines. They don't agree with each other
> though, but they try to do something.
> Firefox does zero newline normalization.
> 
> This is a pretty crappy situation for interop. Maybe something should
> be specified to help solve this.
> 
> Normalizing newlines to \r\n makes sense as then the value will better
> reflect what gets submitted (Opera does this, but doesn't normalize
> stray \r well).
> 
> However, normalizing to \n (like Safari) would work better for those
> textarea.value.length limit scripts that count \r\n as 2. Normalizing
> to \n would also fit with how newlines are normalized during parsing
> (besides IE).
> 
> Doing no newline normalization like Firefox has its advantages too.
> What you input, is what you get. I think this also fits with the DOM
> spec too (as in, it never says to normalize, in this case). That also
> has the advantage of not forcing any normalization (might be better
> for performance) and leaving it up to the script author to do
> normalization IF needed.
> 
> --
> Michael
Received on Tuesday, 30 September 2008 16:36:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:58 UTC