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 14833 - "If current node is a pre, textarea, or listing element, append a U+000A LINE FEED (LF) character." - no browser does this and when we tried it caused site-compat problems. It should either be removed or changed to only emit a extra LF if the element's fi
Summary: "If current node is a pre, textarea, or listing element, append a U+000A LINE...
Status: RESOLVED FIXED
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: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-15 14:02 UTC by contributor
Modified: 2013-03-27 13:09 UTC (History)
4 users (show)

See Also:

Attachments

Description contributor 2011-11-15 14:02:37 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#serializing-html-fragments
Complete: http://www.whatwg.org/c#serializing-html-fragments

Comment:
"If current node is a pre, textarea, or listing element, append a U+000A LINE
FEED (LF) character." - no browser does this and when we tried it caused
site-compat problems. It should either be removed or changed to only emit a
extra LF if the element's first child is a text node starting with a LF.

Posted from: 2001:4c28:a030:30:219:99ff:fe0e:5501
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111009 Firefox/10.0a1
Comment 1 Ian 'Hixie' Hickson 2011-12-07 23:22:37 UTC 
Well we definitely need something here, otherwise we'll get dataloss if there's a leading LF. But I can change it to be more conservative in when they are added, sure.
Comment 2 contributor 2012-01-31 00:39:18 UTC 
Checked in as WHATWG revision r6940.
Check-in comment: Make HTML serialisation more conservative near <pre>.
http://html5.org/tools/web-apps-tracker?from=6939&to=6940
Comment 3 Roan Kattouw 2013-02-07 03:47:33 UTC 
(In reply to comment #1)
> Well we definitely need something here, otherwise we'll get dataloss if
> there's a leading LF. But I can change it to be more conservative in when
> they are added, sure.
Thanks! The data loss issue has been bothering me for a while, and I've had to hack around it in some of my code. The console session in http://pastebin.com/64Jjs4NH demonstrates the insanity I'm dealing with.

Sadly, comment 0 is right that no browser does this. Both Firefox and Chrome completely ignore this rule, causing data loss when parsing and reserializing <pre>s and <textarea>s whose contents start with a newline.

I hope browsers will actually fix this behavior in the future. I guess I'll have to tweak my hack such that it will work both for broken browsers and fixed ones.
Comment 4 Roan Kattouw 2013-02-07 04:32:10 UTC 
(In reply to comment #3)
> I hope browsers will actually fix this behavior in the future.
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=838954 against Firefox and https://code.google.com/p/chromium/issues/detail?id=174829 against Chrome.
Comment 5 Simon Pieters 2013-03-27 13:09:33 UTC 
(In reply to comment #3)
> Sadly, comment 0 is right that no browser does this.

Opera has implemented and shipped the spec change here.