This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28467 - How character data is get serialized when appended as innerHTML to <pre> element.
Summary: How character data is get serialized when appended as innerHTML to <pre> ele...
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: https://html.spec.whatwg.org/#seriali...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-12 06:42 UTC by contributor
Modified: 2016-03-26 17:34 UTC (History)
5 users (show)

See Also:

Attachments

Description contributor 2015-04-12 06:42:54 UTC 
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
Comment 1 Abhijeet Kandalkar 2015-04-12 06:52:59 UTC 
Please refer JSfiddle demonstrating scenario ,

http://jsfiddle.net/abhijeetk/j91n2vLd/1/
Comment 2 Ian 'Hixie' Hickson 2015-04-16 22:05:54 UTC 
I don't understand the bug here. Are you saying the browsers and the spec match?
Comment 3 Abhijeet Kandalkar 2015-04-17 13:44:50 UTC 
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.
Comment 4 Simon Pieters 2015-04-20 11:19:58 UTC 
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
Comment 5 Ian 'Hixie' Hickson 2015-04-21 21:18:49 UTC 
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.
Comment 6 Anne 2016-03-25 13:08:52 UTC 
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1259723 against Gecko.