The read HTML should have hinting to allow full DOM copying (as opposed to just rich copying) from read mode into VE surfaces
OpenPublic

Description

As perhaps a simpler case of copy and paste from 'external sources', pasting richtext that copied from the same wiki should work seamlessly.

In many cases, the 'html' already has the metadata needed. e.g. the image, or text-with-wikilinks, even the categories, should be paste-able

https://en.wikipedia.org/wiki/Pelham_Parkway

With a tiny bit of additional html attributes, the navbox templates ({{Parkways in New York City}} & {{Bronx streets}}) could be copied as they are self-contained units - no parameter were used to invoke them.

Again with a bit of markup, the Infobox pasted into a VE session, but only the shell transclusion could set up - the parameters would need to be entered by the user in the VE.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51547

bzimport added a project: VisualEditor-MediaWiki.Via ConduitNov 22 2014, 1:51 AM
bzimport set Reference to bz52091.
jayvdb created this task.Via LegacyJul 26 2013, 12:47 PM
Jdforrester-WMF added a comment.Via ConduitJul 26 2013, 11:12 PM

This is not simpler. This is the same. The problem is not taking in rich text (from any source), it's inserting it sanely into VisualEditor's ContentEditable surface, sadly. Merging.

  • This bug has been marked as a duplicate of bug 33105 ***
jayvdb added a comment.Via ConduitJul 26 2013, 11:19 PM

This is a separate problem James. This is about copying from a non-VE wiki page on the same wiki. That is very different from copying from another VE, or another website. As I eluded to in my initial enhancement request, additional HTML needs to be emitted into the read version of the wiki page in order that a VE could pick up the name of the template to use when pasting it into a VE.

Jdforrester-WMF added a comment.Via ConduitJul 26 2013, 11:26 PM

(In reply to comment #2)

This is a separate problem James. This is about copying from a non-VE wiki
page on the same wiki. That is very different from copying from another VE,
or another website. As I eluded to in my initial enhancement request,
additional HTML needs to be emitted into the read version of the wiki page in
order that a VE could pick up the name of the template to use when pasting it
into a VE.

Oh, sorry, I missed your comment about adding RDFa/etc. hinting to highlight what DOM elements are what.

"Tiny" is not remotely the correct word - this will require us to replace the entire read DOM with the same output as Parsoid provides VisualEditor, which is vaguely scheduled to be considered for research/analysis in about a year's time (this is so far off in the distance there isn't even a bug for it yet). Recasting.

Jdforrester-WMF added a comment.Via ConduitNov 1 2013, 4:32 AM
  • Bug 52787 has been marked as a duplicate of this bug. ***
Esanders added a comment.Via ConduitJan 21 2014, 3:05 PM

NB Firefox throws away RDFa properties when copying, so this won't be possible without JavaScript intercepting copy events, as it stands.

Jdforrester-WMF moved this task to Backlog on the VisualEditor workboard.Via WebNov 24 2014, 4:24 PM
Jdforrester-WMF set Security to None.
Jdforrester-WMF changed the title from "VisualEditor: The read HTML should have hinting to allow full DOM copying (as opposed to just rich copying) from read mode into VE surfaces" to "The read HTML should have hinting to allow full DOM copying (as opposed to just rich copying) from read mode into VE surfaces".Via WebDec 16 2014, 7:12 PM

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.