Change DOM rendering of <nowiki /> to be <span typeof="mw:Nowiki"></span> or similar?
OpenPublic

Description

VisualEditor deliberately drops <span typeof="mw:Nowiki"> annotations on changed content to prevent originally-necessary <nowiki> blocks interfering with editing. This means that HTML editors don't need to know or care about <nowiki>s, and they are just magically sorted out in the back-end so the resultant wikitext is the most like what a human would create.

However, <nowiki />s come out as a <meta typeof="mw:Placeholder">, which VisualEditor doesn't show to users but also won't ever remove, leading to potential issues where a no-longer-needed <nowiki /> sits in the wikitext, disruptively confusing to wikitext editors.

If Parsoid instead represented it as <span typeof="mw:Nowiki"></span> or similar, VisualEditor could do the same (well, a bit more work) and so drop it when the context has been edited, letting Parsoid re-generate it if needed.


Version: unspecified
Severity: minor
URL: https://en.wikipedia.org/w/index.php?title=Footprints_%28film%29&curid=39472392&diff=579475542&oldid=579357688

bzimport added a project: Parsoid-DOM.Via ConduitNov 22 2014, 2:22 AM
bzimport set Reference to bz56381.
Jdforrester-WMF created this task.Via LegacyOct 30 2013, 7:31 PM
GWicke added a comment.Via ConduitNov 15 2013, 12:15 AM

If we want to perform clean-up like this, then we should perhaps implement that in Parsoid rather than VE so that other users benefit from it as well.

Jdforrester-WMF added a comment.Via ConduitNov 15 2013, 2:05 AM

(In reply to comment #1)

If we want to perform clean-up like this, then we should perhaps implement
that in Parsoid rather than VE so that other users benefit from it as well.

Happy for it to be done in Parsoid instead, and for us to remove the dropping from VE.

Jdforrester-WMF added a comment.Via ConduitJan 18 2014, 5:41 AM
  • Bug 59829 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitJan 18 2014, 5:41 AM
  • Bug 53659 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitJan 18 2014, 5:42 AM
  • Bug 59650 has been marked as a duplicate of this bug. ***
marcoil placed this task up for grabs.Via WebNov 25 2014, 6:30 PM
marcoil added a project: Parsoid.
marcoil set Security to None.
Jdforrester-WMF moved this task to Requests from VE/Flow/others on the Parsoid workboard.Via WebNov 25 2014, 7:53 PM
ssastry moved this task to VE Q3 on the Parsoid workboard.Via WebMon, Feb 2, 11:02 PM
Jdforrester-WMF moved this task to Dependencies on the § VisualEditor Q3 Blockers workboard.Via WebTue, Feb 10, 7:43 PM
Jdforrester-WMF set Story Points to 0.Via WebTue, Feb 10, 8:31 PM
ssastry added a subscriber: Esanders.Via WebTue, Feb 17, 6:30 PM

How about <meta typeof="mw:Nowiki" ../>. Can VE handle that instead?

gerritbot added a project: Patch-For-Review.Via ConduitTue, Feb 17, 6:35 PM
gerritbot added a subscriber: gerritbot.

Change 191096 had a related patch set uploaded (by Subramanya Sastry):
WIP: T58381: Represent <nowiki/> as a mw:Nowiki meta tag

https://gerrit.wikimedia.org/r/191096

Patch-For-Review

ssastry added a comment.Via WebTue, Feb 17, 6:39 PM

Uploaded a WIP there in case that would work. The meta tag seems the right approach and fits in with the use of marker meta tags for various other wikitext constructs.

ssastry claimed this task.Via WebTue, Feb 17, 10:48 PM
Esanders added a comment.Via WebTue, Feb 17, 11:51 PM

<meta> tags will be metadata in VE, so may end up somewhere else if content is deleted. Also <meta> and <link> tags suffer from being destroyed by copy/paste and so require special treatment (we also do this for HTML comments).

ssastry added a comment.EditedVia WebFri, Feb 20, 10:04 PM

Based on an IRC discussion y'day during the VE/Parsoid/Services check-in, it seems that more than fixing the representatoin for nowiki, VE wants Parsoid html2wt to be more aggressive removing existing <nowiki/> from edited content rather than emit those back as is. Something to be considered.

A related idea that came up during the discussion was: maybe Parsoid shouldn't emit the nowiki markup anymore in its HTML. This will work only if:
(a) selser is smart enough to add nowikis wherever required (even for unedited content)
(b) selser is smart enough to not introduce dirty diffs by optimizing / moving around nowikis because of (a). This is especially a concern fwiki, itwiki, etc. where quotes are used in non-italic/non-bold scenarios more heavily. So, any fixes we do should be tested more heavily against these wikis.

A related discussion around (a)/(b) here can be found in https://phabricator.wikimedia.org/T87708#1055269 and later comments.

But, based on all this, I am not sure that this task should be on the VE Q3 blocker list anymore. These fixes are more of a longer-term nature than what is required immediately for VE in Q3. @Jdforrester-WMF, thoughts?

Jdforrester-WMF added a comment.Via WebFri, Feb 20, 10:58 PM

Based on all this, I am not sure that this task should be on the VE Q3 blocker list anymore. These fixes are more of a longer-term nature than what is required immediately for VE in Q3. @Jdforrester-WMF, thoughts?

I'm not sure. Reducing the frequency of <nowiki>s is a key "corruption" concern of users, and as such is a key blocking focus for Q3. I don't particularly see this task as the one-true-fix, and happy for this to be removed if the other work in this area addresses the concerns. What do you think?

ssastry added a comment.Via WebFri, Feb 20, 11:18 PM

I agree that fixing nowiki issues are important. But, we should add specific nowiki corruption tasks to the board rather than have a generic longer-term solution like this. I will go over our current nowiki list and add any specific nowiki corruption scenarios to the VE Q3 board. Sound good?

Jdforrester-WMF added a comment.Via WebFri, Feb 20, 11:19 PM

Works for me.

ssastry moved this task to Backlog on the Parsoid workboard.Via WebMon, Feb 23, 3:43 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.