Last modified: 2014-10-24 07:24:54 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T45133, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 43133 - VisualEditor: Fly-out wikitext editor for unsupported extensions' source blocks ("alienated content")
VisualEditor: Fly-out wikitext editor for unsupported extensions' source bloc...
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
Editing Tools (Other open bugs)
unspecified
All All
: Low enhancement
: VE-deploy-2013-08-15
Assigned To: Ed Sanders
:
: 51131 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-14 18:15 UTC by James Forrester
Modified: 2014-10-24 07:24 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description James Forrester 2012-12-14 18:15:05 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.
Comment 1 Mark Holmquist 2012-12-14 21:56:28 UTC
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.
Comment 2 Roan Kattouw 2012-12-18 08:36:24 UTC
(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.
Comment 3 Adam Wight 2013-01-09 01:17:12 UTC
+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.
Comment 4 James Forrester 2013-01-09 01:48:13 UTC
(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.
Comment 5 James Forrester 2013-02-07 03:16:03 UTC
Moved to Lowest as this has a huge dependency on Parsoid which they are unlikely to implement; depending on their reconsideration in a while.
Comment 6 Bartosz Dziewoński 2013-04-26 17:49:52 UTC
*** Bug 47742 has been marked as a duplicate of this bug. ***
Comment 7 James Forrester 2013-07-10 18:53:41 UTC
*** Bug 51131 has been marked as a duplicate of this bug. ***
Comment 8 Richard Morris 2013-07-29 21:39:35 UTC
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.
Comment 9 MZMcBride 2013-07-30 04:39:03 UTC
(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. :-)
Comment 10 Tongbo Sui 2013-07-30 05:33:19 UTC
(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.
Comment 11 Roan Kattouw 2014-10-24 07:24:54 UTC
Fixed by Ed last year in https://gerrit.wikimedia.org/r/#/c/78035/

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links