https://www.mediawiki.org/w/index.php?title=VisualEditor%3APre&diff=609875&oldid=609874
Version: unspecified
Severity: normal
Description
Description
Details
Details
- Reference
- bz42469
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| 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 |
Event Timeline
Comment Actions
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.
Comment Actions
(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.
Comment Actions
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.
Comment Actions
The VE portion of this is fixed in https://gerrit.wikimedia.org/r/36692 . The Parsoid portion of this is bug 42666 and bug 42667.