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: 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
Please refer JSfiddle demonstrating scenario , http://jsfiddle.net/abhijeetk/j91n2vLd/1/
I don't understand the bug here. Are you saying the browsers and the spec match?
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.
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
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.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1259723 against Gecko.
https://github.com/whatwg/html/issues/944