28467 2015-04-12 06:42:54 +0000 How character data is get serialized when appended as innerHTML to <pre> element. 2016-03-26 17:34:03 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED MOVED https://html.spec.whatwg.org/#serialising-html-fragments P3 normal Unsorted 1 contributor ian annevk ian kandalkar.abhijeet58 mike zcorpan contributor oldest_to_newest 119440 0 contributor 2015-04-12 06:42:54 +0000 Specification: https://html.spec.whatwg.org/ Multipage: https://html.spec.whatwg.org/multipage/#serialising-html-fragments Complete: https://html.spec.whatwg.org/#serialising-html-fragments Referrer: https://www.google.co.in/ Comment: How character data is get serialized when appended as innerHTML to <pre> element. ? HTML : <div><pre id="test3"></pre></div> JS : document.getElementById("test3").innerHTML = "\n\n\nfoo"; str = document.getElementById("test3").innerHTML; As per spec, If current node is a pre element, and the first child node of the element, if any, is a Text node whose character data has as its first character a U+000A LINE FEED (LF) character, then append a U+000A LINE FEED (LF) character. I was expecting, str = "\n\nfoo" but FF/chrome is returning it as str="\n\n\nfoo" Posted from: 106.51.129.57 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 119441 1 kandalkar.abhijeet58 2015-04-12 06:52:59 +0000 Please refer JSfiddle demonstrating scenario , http://jsfiddle.net/abhijeetk/j91n2vLd/1/ 119582 2 ian 2015-04-16 22:05:54 +0000 I don't understand the bug here. Are you saying the browsers and the spec match? 119635 3 kandalkar.abhijeet58 2015-04-17 13:44:50 +0000 Currently, blink/Gecko/Webkit all doesn't support proper serialization of HTML markup inside <pre> tag. 1. During parsing, In the HTML syntax, a leading newline character immediately following the pre element start tag is stripped. Refer https://html.spec.whatwg.org/#the-pre-element 2. Creating HTML fragment for innerHTML function call should behave in reverse way as that of parsing. As per spec, https://html.spec.whatwg.org/#serialising-html-fragments "If current node is a pre, textarea, or listing element, and the first child node of the element, if any, is a Text node whose character data has as its first character a U+000A LINE FEED (LF) character, then append a U+000A LINE FEED (LF) character." Consider jsfiddle in previous comment: <pre id="test1"> foo</pre> str = document.getElementById("test1").innerHTML; val1 = (str.match(/\n/g) || []).length; During parsing, html markup inside <pre> is "\n\n\nfoo" (three newlines) but when you as for innerHTML it is returning "\n\nfoo" (two newline) That is for each rountrip we are ignoring '1' newline. Refer chrome issue : https://code.google.com/p/chromium/issues/detail?id=174829 Currently browsers are not behaving properly for <pre> serialization. I have identified three use cases as mentioned in http://jsfiddle.net/abhijeetk/j91n2vLd/1/. Could you please let me know proper behavior in each of this case. 119678 4 zcorpan 2015-04-20 11:19:58 +0000 The proper behavior per spec is to serialize an extra LF when the first child is Text and starts with LF. Test: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3504 119734 5 ian 2015-04-21 21:18:49 +0000 As far as I can tell this is a bug with the browsers, not with the spec. If that is the case, then the bug should be filed in the relevant bug trackers of the browser vendors. 125629 6 annevk 2016-03-25 13:08:52 +0000 I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1259723 against Gecko. 125635 7 annevk 2016-03-26 17:34:03 +0000 https://github.com/whatwg/html/issues/944