Page MenuHomePhabricator

Presence/absence of initial newline in <pre> should be in round-trip data
Closed, ResolvedPublic

Description

There is a syntactic (but not a semantic) difference between <pre>Foo</pre> and <pre>\nFoo</pre>. VE will normalize the latter to the former (due to the browsers' HTML DOM implementation), so Parsoid should use round-trip data to serialize this correctly.

Test wikitext:

<pre>Foo</pre>

<pre>
Foo</pre>

/_rtform/ claims this round-trips cleanly, but it's lying. If you put the wikitext into /_wikitext/, grab the HTML, then copypaste that into /_html/ , you'll see the initial newline in the second <pre> is eaten.


Version: unspecified
Severity: normal

Details

Reference
bz42667

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:44 AM
bzimport added a project: Parsoid.
bzimport set Reference to bz42667.
Catrope created this task.Dec 4 2012, 1:23 AM

From http://dev.w3.org/html5/spec-preview/syntax.html#element-restrictions:

"A single newline may be placed immediately after the start tag of pre and textarea elements. This does not affect the processing of the element. The otherwise optional newline must be included if the element's contents themselves start with a newline (because otherwise the leading newline in the contents would be treated like the optional newline, and ignored)."

This is about the syntax, so applies to serializing and parsing. A serializer must emit an additional newline if the pre content (without the optional newline) in the DOM starts with a newline. Sadly, the innerHTML method in modern browsers does not seem to implement this, so we have to work around it.

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptJan 28 2016, 6:09 PM