|Resolved||Catrope||T44469 VisualEditor: Leading newlines in <pre>s get eaten|
|Resolved||• GWicke||T44666 Initial newline in <pre> is stripped|
|Resolved||ssastry||T44667 Presence/absence of initial newline in <pre> should be in round-trip data|
Mark and I looked at this and discovered it was because VE round-trips the HTML in question through the browser's HTML parser, which turns "<pre>\n" into "<pre>". Shockingly, this is actually mandated by the HTML spec.
We can work around this in the converter by setting a flag on these pre's on the way in and checking for it on the way out.
(In reply to comment #1)
We can work around this in the converter by setting a flag on these pre's on
the way in and checking for it on the way out.
...or not, grah. Because of the way the DOM API works, I have no way of detecting this from within a browser.
The approach we're taking now is that VE will work around this in cases where there are semantically meaningful newlines in the <pre> (i.e. >=1 newline read from the DOM) by adding a newline. That only leaves the ambiguity between <pre>Foo</pre> and <pre>\nFoo</pre> , which is syntactic, not semantic, and will be handled by Parsoid using round-trip data.