Last modified: 2014-10-24 07:24:54 UTC
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.
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. :-)
(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/
