Parsoid output seems identical for both,
<pre>haha noooo haha</pre>
{{1x|<pre>haha noooo haha</pre>}}
but the latter displays on one line.
Parsoid output seems identical for both,
<pre>haha noooo haha</pre>
{{1x|<pre>haha noooo haha</pre>}}
but the latter displays on one line.
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T156675 Allow editing <pre> inline, without a popup dialog/inspector | |||
Open | None | T76550 Provide true nested, inheriting surfaces | |||
Open | None | T49344 Internal nodes should eventually be in a separate document ("sub-documents") |
What is Template:1x? Is it like Template:Echo? What is the HTML corresponding to the 1x example?
@Catrope Yeah, 1x replaced Echo
Here's Parsoid's output for two, respectively,
<pre data-parsoid='{"stx":"html","dsr":[0,28,5,6]}'>haha noooo haha</pre>
vs
<pre about="#mwt1" typeof="mw:Transclusion" data-parsoid='{"stx":"html","dsr":[30,65,null,null],"pi":[[{"k":"1"}]]}' data-mw='{"parts":[{"template":{"target":{"wt":"1x","href":"./Template:1x"},"params":{"1":{"wt":"<pre>haha\n\nnoooo\n\nhaha</pre>"}},"i":0}}]}'>haha noooo haha</pre>
And here's a screenshot of what that looks like in VE,
(Note, the screenshot is an inversion of the two, ie. typeof mw on the top, sorry)
Lowest might not be appropriate since we now add mw:Extension/pre to all html pre. See Icaffc8a73b0ae2281fa38223fb9f940075f2484f
That would have been helpful to flag. :-(
This means that <pre>s are no longer editable as rich text in VE (and won't be for years).
That was one of the fixes though. <pre> shouldn't have been rich text to begin with, it's plaintext only.
Sorry, poorly-phrased; <pre>s are now not editable inline as content, only via special handling in an extension window; indent-pres remain editable inline, which is a bit confusing for users. If you make a <pre> in VE it'll (always?) be indent-pred on serialisation AFAICT?
Sorry, I really should have communicated this better before deploying. I'm totally at fault.
<pre> and indent-pre have different semantics though, plaintext vs rich, respectively. That is a bit confusing, I agree, but that's wikitext.
If you make a <pre> in VE it'll (always?) be indent-pred on serialisation AFAICT?
I believe that's correct. I wasn't able to create a <pre> in VE. Only indent-pre.
<pre>s are now not editable inline as content, only via special handling in an extension window
My assumption was that that was the right thing to do, since it forces plaintext editing.
No worries.
To support proper editability of <pre>s in VE, we'd need to
No worries.
Phew ...
Ok, but keep in mind this task was about a small rendering difference, which is now slightly exacerbated by that patch. Proper edibility sounds like a major undertaking. The patch at least ensures html2html correctness.
I fixed this with https://gerrit.wikimedia.org/r/340555 (I don't think the current subtasks here match the task description). Task T159231 is similar to this, but a bit wider scope.
I think you should turn this comment into a separate task titled "Allow editing <pre> without a popup dialog/inspector" :)
That's not how it works. "I fixed this task, only I didn't fix what it asked to fix and I didn't fix any of the blockers" means "I fixed a different task". :-)
I fixed this task, as originally reported. Your comments on February 14 completely changed what this task is about, I guess.