[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 04:50:51 UTC