This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/the-button-element.html Multipage: http://www.whatwg.org/C#concept-textarea-raw-value Complete: http://www.whatwg.org/c#concept-textarea-raw-value Comment: It seems like textarea's raw value should always normalize newlines to \n (and form submission should normalize \n to \r\n) Posted from: 85.227.158.34 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.9.168 Version/11.50
Form submission should also normalize \n in *names* to \r\n
Simon: see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12606 for newline handling when serializing for form submission.
Ah, OK, that bug covers submission. Then this bug is just "textarea's raw value should always normalize newlines to \n"
This matches what Gecko does too I believe.
Do you have a testcase demonstrating what you mean? Is this just about DOM manipulation inserting U+000Ds using .textContent and those needing to not be reflected in .value?
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1217 (expect \n) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1218 here I expected \n for all of them, which webkit does. Opera currently normalizes them all to \r\n, but we'll change it to \n. Firefox changes the .value = 'x\r' to \n, but doesn't change the others, which is a bit weird.
Pressing enter inserts a U+000A. I don't understand where 1217 would be getting its U+000Ds. Haven't look at 1218 in detail yet, but I'm not convinced what WebKit does there is right (e.g. try it with span/textContent instead of textarea/value
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1238 is a variant of 1218 that also shows the textLength (which is supposed to be post-normalisation).
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1240 Opera: - value is raw value normalised to \r\n - setting value sets raw value (implied) - textLength is based on raw value normalised to \r\n - textContent is not normalised Chrome: - value is raw value normalised to \n - setting value sets raw value (implied) - textLength is based on raw value normalised to \n - textContent is not normalised Firefox: - value is raw value not normalised - setting value normalises to \n - textLength is based on raw value not normalised - textContent is not normalised IE9: - value is raw value not normalised but with \rs turned into \n - setting value normalises to \n - no textLength support - textContent is normalised to \n So from this I think it would be reasonable to say: - value should be raw value normalised to \r\n (what is submitted) - setting value can set raw value (since getting it is normalised so it doesn't matter what the raw value really is) - textLength should be based on the raw value normalised to \r\n (again, what is submitted) - textContent should not be normalised (since that's a far broader change than just <textarea> if we do it) I believe this is what the spec says now. Are there any Web-compat reasons to do something else?
(In reply to comment #9) > So from this I think it would be reasonable to say: > - value should be raw value normalised to \r\n (what is submitted) Only Opera does this. We will change to normalize to \n. > - setting value can set raw value (since getting it is normalised > so it doesn't matter what the raw value really is) > - textLength should be based on the raw value normalised to \r\n > (again, what is submitted) Should be normalized to \n. > - textContent should not be normalised (since that's a far broader > change than just <textarea> if we do it) > > I believe this is what the spec says now. > > Are there any Web-compat reasons to do something else? Yes. We have lots of bugs on this. It breaks BBCode, apparently, where the code gets confused about the caret's position or something and inserts it's "markup" in the wrong place because Opera uses two characters for newlines, where other browsers used just one.
Ah, well that's good to know. Changing this basically makes textLength useless — until now, it's been useful because it compares to maxlength="". But I guess if it equals value.length it's useless anyway. So new proposal: - value should be raw value normalised to \n. - raw value with \n turned to \r\n is what is submitted. - setting value sets raw value unmodified - textLength returns value.length - textContent should not be normalised I think this matches Chrome, more or less.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: see comment 11
Checked in as WHATWG revision r6815. Check-in comment: compat changes for <textarea>.value and .textLength http://html5.org/tools/web-apps-tracker?from=6814&to=6815