See https://gerrit.wikimedia.org/r/#/c/281076/ where this surfaced.

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":"&lt;pre>haha\n\nnoooo\n\nhaha&lt;/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

• T49344 – Do sub-documents so that we can model the <pre> bits of the document differently (also needed for lots of other work); this has been a wishlist item since 2013 so we can support references and image captions better, but is a huge amount of engineering work.
• T76550 – Do sub-surfaces so that the <pre> bits of the surface don't have the tools enabled (also needed for a few odds and ends); this is also a wishlist item since ~2014 for inline surface editing like for images but this might be the only real contender, and is quite a lot of engineering and a serious amount of interaction design/product work.
• Do some magic in the Converter (I think) with some ultra-special-casing of transclusion-wrapped <pre>s for that part of this

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.

In T156675#3027127, @Jdforrester-WMF wrote:

To support proper editability of <pre>s in VE, we'd need to

• T49344 – Do sub-documents so that we can model the <pre> bits of the document differently (also needed for lots of other work); this has been a wishlist item since 2013 so we can support references and image captions better, but is a huge amount of engineering work.
• T76550 – Do sub-surfaces so that the <pre> bits of the surface don't have the tools enabled (also needed for a few odds and ends); this is also a wishlist item since ~2014 for inline surface editing like for images but this might be the only real contender, and is quite a lot of engineering and a serious amount of interaction design/product work.
• Do some magic in the Converter (I think) with some ultra-special-casing of transclusion-wrapped <pre>s for that part of this

I think you should turn this comment into a separate task titled "Allow editing <pre> without a popup dialog/inspector" :)

In T156675#3082327, @matmarex wrote:

I think you should turn this comment into a separate task titled "Allow editing <pre> without a popup dialog/inspector" :)

This one will do.

In T156675#3082318, @matmarex wrote:

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.

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.