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.

(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.

+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.

(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.

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

• Bug 47742 has been marked as a duplicate of this bug. ***

• Bug 51131 has been marked as a duplicate of this bug. ***

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.

(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. :-)

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.

Fixed by Ed last year in https://gerrit.wikimedia.org/r/#/c/78035/