Page MenuHomePhabricator

Allow editing <pre> inline, without a popup dialog/inspector
Open, LowestPublic8 Story Points

Description

Parsoid output seems identical for both,

<pre>haha

noooo

haha</pre>
{{1x|<pre>haha

noooo

haha</pre>}}

but the latter displays on one line.

Event Timeline

Arlolra created this task.Jan 30 2017, 8:20 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 30 2017, 8:20 PM

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>
Arlolra added a comment.EditedJan 31 2017, 1:48 AM

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)

Jdforrester-WMF renamed this task from Adding a mw typeof to html pre strips newlines in rendering in VE to Adding a mw typeof=transclusion to html <pre> treats it as inline not block in VE rendering.Feb 14 2017, 8:23 PM
Jdforrester-WMF triaged this task as Lowest priority.
Jdforrester-WMF set the point value for this task to 8.
Jdforrester-WMF moved this task from To Triage to Freezer on the VisualEditor board.

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.

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" :)

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

This one will do.

Jdforrester-WMF renamed this task from Adding a mw typeof=transclusion to html <pre> treats it as inline not block in VE rendering to Allow editing <pre> inline, without a popup dialog/inspector.Mar 8 2017, 12:56 AM

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.

Magol added a subscriber: Magol.Dec 28 2017, 10:56 AM