13983 2011-08-31 17:36:52 +0000 WF2: It seems like textarea's raw value should always normalize newlines to \n 2012-01-04 04:58:05 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#concept-textarea-raw-value P3 normal --- 1 contributor ian annevk hsteen ian jonas kennyluck mike public-html-admin public-html-wg-issue-tracking shadow2531 zcorpan public-html-bugzilla oldest_to_newest 56113 0 contributor 2011-08-31 17:36:52 +0000 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 56180 1 zcorpan 2011-09-01 13:52:27 +0000 Form submission should also normalize \n in *names* to \r\n 56213 2 hsteen 2011-09-02 10:14:42 +0000 Simon: see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12606 for newline handling when serializing for form submission. 56214 3 zcorpan 2011-09-02 10:23:57 +0000 Ah, OK, that bug covers submission. Then this bug is just "textarea's raw value should always normalize newlines to \n" 56230 4 jonas 2011-09-02 23:39:42 +0000 This matches what Gecko does too I believe. 58586 5 ian 2011-10-20 22:19:55 +0000 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? 58587 6 zcorpan 2011-10-20 22:34:25 +0000 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. 58859 7 ian 2011-10-25 04:51:01 +0000 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 59104 8 ian 2011-10-27 21:00:47 +0000 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). 59110 9 ian 2011-10-27 23:54:02 +0000 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? 59121 10 zcorpan 2011-10-28 08:04:06 +0000 (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. 59517 11 ian 2011-11-02 19:42:48 +0000 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. 59570 12 ian 2011-11-03 17:04:15 +0000 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 59571 13 contributor 2011-11-03 17:11:00 +0000 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