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 15002 - Clarify status of initial newline in <pre> and <textarea>
Summary: Clarify status of initial newline in <pre> and <textarea>
Status: RESOLVED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML/XHTML Compatibility Authoring Guide (ed: Eliot Graff) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Eliot Graff
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-30 13:03 UTC by Henry S. Thompson
Modified: 2011-12-02 14:38 UTC (History)
5 users (show)

See Also:

Attachments

Description Henry S. Thompson 2011-11-30 13:03:20 UTC 
In the Newlines in textarea and pre Elements section, please add something clarifying that in order to begin the content of one of these elements with a newline, a character reference, e.g. &#10;, should be used.
Comment 1 Henri Sivonen 2011-12-01 06:24:15 UTC 
(In reply to comment #0)
> In the Newlines in textarea and pre Elements section, please add something
> clarifying that in order to begin the content of one of these elements with a
> newline, a character reference, e.g. &#10;, should be used.

A character reference is no different from a literal line feed character in this case. The character reference is expanded on the tokenizer level but the line feed is dropped on the tree builder level. The tree builder doesn't know if the character originated from a character reference, so &#10; immediately after <pre> gets dropped, too.

See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1265 in a browser that implements the HTML parsing algorithm.
Comment 2 Henry S. Thompson 2011-12-01 09:50:44 UTC 
Thanks for the example, which is equivalent to what I did look at in both FF and Chrome, which I guess do not implement the HTML parsing algorithm (in the versions I'm using) . . .

What browser do you recommend at the moment for this kind of exploration?

This does make it impossible to produce polyglot which begins a <pre> with a newline :-(
Comment 3 Henri Sivonen 2011-12-02 14:20:05 UTC 
(In reply to comment #2)
> Thanks for the example, which is equivalent to what I did look at in both FF
> and Chrome, which I guess do not implement the HTML parsing algorithm (in the
> versions I'm using) . . .

Chrome seems to have a bug here.

Which version of Firefox did you use? Firefox should behave per spec here.

> What browser do you recommend at the moment for this kind of exploration?

The latest version of Firefox or Opera 11.60 or newer.

Chrome implemented a snapshot of the HTML parsing algorithm in 7 or 8 and hasn't updated their implementation since, so Chrome doesn't reflect the more recent spec changes. However, I think in this case Chrome is buggy even according to the way the spec was at the time Chrome implemented.

> This does make it impossible to produce polyglot which begins a <pre> with a
> newline :-(

Yes.
Comment 4 Henry S. Thompson 2011-12-02 14:38:48 UTC 
(In reply to comment #3)
> (In reply to comment #2)
> > Thanks for the example, which is equivalent to what I did look at in both FF
> > and Chrome, which I guess do not implement the HTML parsing algorithm (in the
> > versions I'm using) . . .
> 
> Chrome seems to have a bug here.
> 
> Which version of Firefox did you use? Firefox should behave per spec here.

3.6.4 -- Sorry, I had no idea I was so far out of date with FF.
8.0.1 behaves as you suggest.