Page MenuHomePhabricator

Change DOM rendering of <nowiki /> to be <span typeof="mw:Nowiki"></span> or similar?
Closed, ResolvedPublic0 Estimated Story Points

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

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:22 AM
bzimport added a project: Parsoid-DOM.
bzimport set Reference to bz56381.

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.

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

  • Bug 59829 has been marked as a duplicate of this bug. ***
  • Bug 53659 has been marked as a duplicate of this bug. ***
  • Bug 59650 has been marked as a duplicate of this bug. ***
marcoil added a project: Parsoid.
marcoil set Security to None.

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

gerritbot subscribed.

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

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.

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

Based on an IRC discussion y'day during the VE/Parsoid/Services check-in, it seems that more than fixing the representation 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?

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?

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?

Change 232313 had a related patch set uploaded (by Arlolra):
T58381: Edited nowiki content should invalidate the nowiki

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

Change 232313 had a related patch set uploaded (by Arlolra):
WIP: Edited nowiki content should invalidate the nowiki

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

Change 191096 abandoned by Subramanya Sastry:
WIP: T58381: Represent <nowiki/> as a mw:Nowiki meta tag

Reason:
Once we figure out how to not generate HTML for <nowiki>s and instead add them back where needed, this is going to be irrelevant.

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

Change 232313 abandoned by Arlolra:
WIP: Edited nowiki content should invalidate the nowiki

Reason:
For now ... until I pick it up again.

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

Change 281076 had a related patch set uploaded (by Arlolra):
WIP: Tokenize html pre as an extension tag

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

Change 281076 merged by jenkins-bot:
Treat html pre and nowiki as extension tags

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

Parsoid now represents them as <span typeof="mw:Nowiki"></span>, but VisualEditor still needs to do the work to drop them when the context has been edited.

@Jdforrester-WMF Do we actually need any work in VE? This seems to be magically working okay in my testing. If I'm missing something, is there a task?