VisualEditor: Fly-out wikitext editor for unsupported extensions' source blocks ("alienated content")
Closed, ResolvedPublic

Description

For content which is alienated, provide a way for users to get a wikitext editing window for just the wikitext for that item. This allows users to modify content that does not have an inspector yet, and for "power users", make tweaks in an environment that is familiar to them, without overwhelming other users. Ideally, this would be syntax-highlighted and pretty and helpful, but anything at all would be a start. :-)

This will require some serious magic in Parsoid to identify the causal wikitext and allow partial document retrieval, and so this is very much in the "enhancement" pile for now; putting in UI as it's an inspector, but it will have impacts all the way down through DM.


Version: unspecified
Severity: enhancement

bzimport set Reference to bz43133.
Jdforrester-WMF created this task.Via LegacyDec 14 2012, 6:15 PM
MarkTraceur added a comment.Via ConduitDec 14 2012, 9:56 PM

It should be noted that a lot of this is already supported. I don't think it's perfect, and VE would have to perform some acrobatics to get it working, but you could essentially make it work if you set the wikitext source on the element, then serialized the DOM and re-parsed it to get the visual representation back.

James_F and I chatted about this for some time, and I'm pretty sure that's one of the saner ways to do it (unless you wanted to simply ignore the visual portion of "VisualEditor" and submit the alien's changes only when the user is done editing.

Catrope added a comment.Via ConduitDec 18 2012, 8:36 AM

(In reply to comment #1)

It should be noted that a lot of this is already supported. I don't think
it's
perfect, and VE would have to perform some acrobatics to get it working, but
you could essentially make it work if you set the wikitext source on the
element, then serialized the DOM and re-parsed it to get the visual
representation back.

The wikitext is currently exposed in the data-parsoid attribute, but the contents of that attribute are supposed to be private and VE isn't supposed to look at them, just preserve them. There were earlier hacks in VE that extracted information from data-parsoid to work around Parsoid issues (specifically, we had to look at sHref for links and stx==html for list items), but Gabriel has been glaring at me every time I did that.

So to make the wikitext editable, it would have to be moved to a more public place, or data-parsoid would have to be declared semi-public. Either way, we need to spec how Parsoid is going to present the wikitext to VE and what VE is allowed to do with it.

James_F and I chatted about this for some time, and I'm pretty sure that's
one
of the saner ways to do it (unless you wanted to simply ignore the visual
portion of "VisualEditor" and submit the alien's changes only when the user
is
done editing.

Yeah, you probably don't want to continuously rerender as the user types, that would get crazy. But as you say, you'd want to reparse the entered wikitext so you can rerender it and give the user visual feedback. That should be interesting to implement.

awight added a comment.Via ConduitJan 9 2013, 1:17 AM

+1, I imagine this feature as a toggle button, which switches the main view between its current rendering containing uneditable blocks, to a hybrid rendered + wikitext view in which the VE-opaque stuff is displayed as raw source.

The VE is great, but I have not found it to be usable for anything beyond the most trivial copy-editing, because of this issue.

Jdforrester-WMF added a comment.Via ConduitJan 9 2013, 1:48 AM

(In reply to comment #3)

+1, I imagine this feature as a toggle button, which switches the main view
between its current rendering containing uneditable blocks, to a hybrid
rendered + wikitext view in which the VE-opaque stuff is displayed as raw
source.

Actually, we'll probably have inspector buttons on alienated nodes that trigger a float-over IFRAME quasi-window (in the same way that we do for the link inspector) for the individual item, rather than have a different editing mode (disrupting the entire editing flow feels wrong), but these decisions have yet to be taken.

Jdforrester-WMF added a comment.Via ConduitFeb 7 2013, 3:16 AM

Moved to Lowest as this has a huge dependency on Parsoid which they are unlikely to implement; depending on their reconsideration in a while.

matmarex added a comment.Via ConduitApr 26 2013, 5:49 PM
  • Bug 47742 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitJul 10 2013, 6:53 PM
  • Bug 51131 has been marked as a duplicate of this bug. ***
SalixAlba added a comment.Via ConduitJul 29 2013, 9:39 PM

There are quite a lot of extensions where the content should probably be treated as a simple block of text. <math>, <source>, <pre>, <poem> basically just have plain text ending with the appropriate closing tag.

Some partial fix of this would be a great step in allowing VE to be used on some large classes of article.

MZMcBride added a comment.Via ConduitJul 30 2013, 4:39 AM

(In reply to comment #8)

There are quite a lot of extensions where the content should probably be
treated as a simple block of text. <math>, <source>, <pre>, <poem> basically
just have plain text ending with the appropriate closing tag.

Sort of. Ideally there will one day be a visual math editor, a visual music editor, and we already have [[mw:Extension:CodeEditor]] (which is even deployed to certain wikis) for JavaScript and CSS, which will likely cover <pre> and <source>/<syntaxhighlight> blocks.

I suppose <poem> and <nowiki> blocks can use a simple editor. :-)

bzimport added a comment.Via ConduitJul 30 2013, 5:33 AM

suitongbowgn wrote:

(In reply to comment #9)

(In reply to comment #8)
> There are quite a lot of extensions where the content should probably be
> treated as a simple block of text. <math>, <source>, <pre>, <poem> basically
> just have plain text ending with the appropriate closing tag.

Sort of. Ideally there will one day be a visual math editor, a visual music
editor, and we already have [[mw:Extension:CodeEditor]] (which is even
deployed
to certain wikis) for JavaScript and CSS, which will likely cover <pre> and
<source>/<syntaxhighlight> blocks.

I suppose <poem> and <nowiki> blocks can use a simple editor. :-)

For <math> please see bug 43058. I believe it is already available via VisualEditor experimental code.
For <syntaxhighlight> please see bug 47742. The code is currently under code review and will be available via VE experimental code in the future.

Catrope added a comment.Via ConduitOct 24 2014, 7:24 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.