[Epic] Support editing parts of a page in VisualEditor-MediaWiki
Open, LowPublic

Description

It should be possible to edit a part of a MediaWiki page such as a section or paragraph via VisualEditor without loading the entire article into the editor. This would be especially useful on mobile devices. This ticket is designated to serve as the parent task for all work related to such a goal.

The parsing-related work can be seen at Parsoid: Section-Editing-Support board.

Details

Reference
bz48429

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

Related URL: https://gerrit.wikimedia.org/r/68868 (Gerrit Change I13bbb9549c999bb7301bbcf530706a813184425d)

I submitted the patch above to show two links side-by-side, in the form of "[edit] [edit source]", similarly to how the article tabs are done.

I like kipod's ideas (comment 22). I think to more fully support section editing means to make it easy to choose either editor at any time.

Let me explain. If the Bartosz patch is implemented (comment 24), or some variation of it, there will be "edit" and "edit source" links or icons on every section.

It would be wonderful if the "edit source" links or icons for sections also showed up inside the Visual Editor. The Visual Editor could treat "edit source" links or icons as uneditable links. But the link would still work. So people could click "edit source" links or icons to open source editing of a section.

People could go to source mode editing at anytime, even from inside the Visual Editor. That would be so convenient and so useful.

Later on, this functionality could be extended to anything the Visual Editor can't edit. People could click on templates, tables, etc. inside the Visual Editor and go directly to source mode editing of that section. Or they could right-click templates, tables, etc. to go to a new tab in source mode for that section.

Timeshifter, this sounds very much like what is described at bug 43133.

Bartosz (comment 26). If I am reading bug 43133 right it sounds way too complicated. What I am suggesting is a simple "edit source" link to source mode editing of a section. Nothing fancy like floating windows, etc. tied in any way to the Visual Editor.

One clicks out of the Visual Editor altogether. This means that edits to the source wikitext in a section are treated the same no matter how one got to that wikitext edit window. This avoids integration conflicts, additional edit conflicts, or anything complicated.

Same for clicking on stuff Visual Editor can't edit. One is sent to source mode for the section where that stuff is found. Nothing more.

For transcluded templates one still has to go to the bottom of the source-mode edit window for the whole page. That is where the list of transcluded templates is found. It would be nice if one could see such a list at the bottom of source-mode edit windows for sections too.

(In reply to comment #20)

I read the discussion, and it seems nobody mentioned what i think is the
"real"
bug here: we have the "edit source" link, that drops you back to wikitext
editor. The correct behavior for ve should obviously be to drop you to a
section edit if the hser entered edit state through an edit section link.

Peace.

I have created this as bug 49664.

(In reply to comment #25)

It would be wonderful if the "edit source" links or icons for sections also
showed up inside the Visual Editor. The Visual Editor could treat "edit
source" links or icons as uneditable links. But the link would still work. So
people could click "edit source" links or icons to open source editing of a
section.

I have created this as bug 49665.

(In reply to comment #18)

I commented at
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/
Feedback#Now_unable_to_edit_sections_by_old_method
that it would be ideal to have section-edit links for [edit] and [edit
source].

ie.

Sandbox [edit]

replaced with:

Sandbox [edit] [edit source]

I believe this would prevent a LOT of complaints in the short term, and it
would permit a lot of us to continue being active beta testers
(section-editing
is my most frequent type of edit), that it should be High priority, if at all
possible. Thanks.

I have created this as bug 49666.

Related URL: https://gerrit.wikimedia.org/r/69984 (Gerrit Change I4b9c47fd65a700a81c880144247fec524edff7e5)

Just a note (for users not following the other bugs) that we have just merged a change along the lines of bug 49666 - there will be both an "edit" and an "edit source" link on every section, with the edit link taking the user into VisualEditor, scrolled down to that section.

This enhancement request (to have VE appear just for a section within a wider page) is not impossible, and we're keen to explore what impact it has, but very hard, and blocked on Parsoid's HTML being used as the basis for MW's read pages, so may take some time.

*** Bug 50592 has been marked as a duplicate of this bug. ***

99of9 added a comment.Jul 2 2013, 10:46 PM

I can't believe that section editing is marked as a "lowest priority" "enhancement"! This is incredibly important to me. The way it's currently set up wastes bandwidth and slows load time relative to the old editor. Both of these are important when making a quick-fix edit. Hardly "marginal utility". James, please try regular editing on a slow connection if you haven't done this before, I'm pretty sure you'll end up editing the section source. I'm quite supportive of visual editor in general, but if this is not going to be fixed, I may have to turn back.

(In reply to comment #34)

I can't believe that section editing is marked as a "lowest priority"
"enhancement"!

"Enhancement" means "the software doesn't do this, and isn't as-written meant to do this"; it's not a judgement on whether it should.

"Lowest priority" means "the core developers of this are not intending to work on this issue any time soon"; bugs are always open to other developers coming and working on them, which frequently happens.

"Lowest" is a very clear way of me marking the bug as something that can be taken up without fear of duplication of work by a developer new to the code. (This is known as avoiding "cookie licking".)

This is incredibly important to me.

I appreciate that it is important to some editors, but I have to balance all requested features, changes and bugs with VisualEditor against one another, and in my judgement this is, relatively, an edge case.

The way it's currently set up wastes bandwidth and slows load time relative
to the old editor. Both of these are important when making a quick-fix edit.

I agree with that; I recommend using the wikitext editor for exactly these use cases by power users if they prefer.

Hardly "marginal utility".

That specifically refers to finding a solution which you don't want.

A simpler solution - involving having the entire document available, but just not editable except for the section the user asked for - is do-able, but in that case, the benefits you're looking for (low bandwidth, fast loading time, low load on local computers) would not be present; hence, marginal utility.

Solving what you're actually asking for (a form of VisualEditor/Parsoid that loaded and edited only one section at a time) would be a mammoth piece of work, albeit with some usefuless as you describe.

James, please try regular editing on a slow connection if you haven't done
this before, I'm pretty sure you'll end up editing the section source.

I've edited Wikipedia (and other wikis) since 2001, including over heroically-terrible connexions through the years; I am very aware of the impact that our current site has on low-bandwidth users, even without VisualEditor, but I cannot justify spending donor funds to that extent when there are more pressing demands on the resources of the VisualEditor team.

I'm quite supportive of visual editor in general, but if this is not going
to be fixed, I may have to turn back.

I'm sorry that that is the case, and hope that it does not come to that. Sorry if my explanation here is insufficient.

Solving what you're actually asking for (a form of VisualEditor/Parsoid that
loaded and edited only one section at a time) would be a mammoth piece of
work,
albeit with some usefuless as you describe.

> James, please try regular editing on a slow connection if you haven't done
> this before, I'm pretty sure you'll end up editing the section source.

I've edited Wikipedia (and other wikis) since 2001, including over
heroically-terrible connexions through the years; I am very aware of the
impact
that our current site has on low-bandwidth users, even without VisualEditor,
but I cannot justify spending donor funds to that extent when there are more
pressing demands on the resources of the VisualEditor team.

My first thought is what were people thinking when they thought that using a visual editor to edit a whole page at a time would not slow things down a lot for many users? I am not a developer though, and hindsight is 20/20.

Whatever it costs to make a visual editor that edits a section at at time would be worth it. The WMF spends money on far less important things. I have been saying this for years.

I think millions of dollars more a year should be spent on developer salaries just for the visual editor, and the coordination of vast armies of volunteer developers to work on the visual editor. Another spending priority would be developer money for cross-wiki watchlists.

99of9 added a comment.Jul 3 2013, 8:24 AM

the core developers of this are not intending to work on this issue any time soon

That's exactly what befuddles me, and seems like a poor judgement. If it's anywhere near as big a task as you envisage, then I can't expect a volunteer to take it up. So I conclude that realistically it will never be done.

having the entire document available, but just not editable

Ok, I agree that would be useless, possibly of negative value. You're right that this is not what I'm asking for.

Parsoid that loaded and edited only one section at a time would be a mammoth piece of work

Obviously I'm not a mediawiki programmer, so I speak from ignorance here. But I don't understand why Parsoid can't just be given a shorter piece of wikitext to parse, along with the section number it is starting at. Since the old editor is quite capable of serving up a correct section of the wikicode to the user, I don't see why the same wikicode can't be given to Parsoid. Please can you get a third and fourth opinion on the feasibility of this. Someone in your team may be able to think of a way around the problems you envisage.

I've edited Wikipedia (and other wikis) since 2001, including over heroically-terrible connexions

So have you now also tried VisualEditor on those heroically-terrible connections? I'm willing to bet that you will feel the weight of this problem.

I cannot justify spending donor funds

The whole goal of VisualEditor is to improve accessibility and the editing experience for lower-tech editors right? Well, the sad truth is that low-tech and globally underrepresented editor communities are strongly correlated with low bandwidth access. Section editing in a long article gives an order of magnitude speed gain to those editors. If you cannot do this for the target audience, I fear that VisualEditor will not serve those who need it the most.

I really hope you will discuss this with more people before confining it to the dustbin.

99of9 added a comment.Jul 3 2013, 11:58 AM

Oh, and sorry to be pedantic, but in the original context, "marginal utility" was not referring to a specific semi-solution as far as I can see:

I don't seem to be able to section edit with VisualEditor.

To edit a section, we would need to get its HTML from Parsoid - but a section

isn't guaranteed to be balanced HTML ...

Coming up with a solution to this is would be a significant piece of

engineering effort for marginal utility.

Thank you for confirming now that you *do* see utility in stopping the waste of bandwidth and slowing of load time. Even if you think it is too difficult.

I appreciate the VE is a hard problem - but now you have an interface that *lies* to the user. It claims visual section editing is possible, but the PM for the VE has stated this functionality will not be funded.

So, is the interface lying to the user this bug, or should it be a separate bug?

If lying to the user is considered a feature, what is it for?

Ah, I see the "edit|edit source" links on sections have turned back into just "edit" links, which edit the wikitext. Thank you :-)

Ah, the disappearing double-links are Bug 50731.

joedecker wrote:

This is quite serious for slow connections.

99of9 added a comment.Jul 31 2013, 4:08 AM

I'm upgrading this to "normal" since it's listed at #4 on https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems and I'm not seeing any good case for low/lowest made here.

(In reply to comment #43)

I'm upgrading this to "normal" since it's listed at #4 on
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems and I'm
not
seeing any good case for low/lowest made here.

The "priority" field doesn't mean "how much do people want it", it's "how soon are the developers likely to get to do it".

As I explained above, this will require a series of major changes in Parsoid and a huge re-write of MediaWiki's skins system as we switch over to use Parsoid's generated HTML for read pages, and is many (many) months away - we're hoping to be able to undertake it some time towards the start/middle of next calendar year.

Magically changing the status of the priority doesn't make this complex work happen any quicker. There is no value in edit-warring over Bugzilla statuses, so I'm going to leave this as is, but please don't make changes like this.

99of9 added a comment.Aug 1 2013, 3:11 PM

This:
"but I cannot justify spending donor funds to that extent"
just turned into:
"we're hoping to be able to undertake it some time towards the start/middle of next calendar year"

Which sure sounds like a priority change, so I'm not sure if my flag change was psychic-magic or precipitative-magic, but either way, it now seems like the correct priority status. I've tried communicating other ways:
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Section_editing_will_never_be_implemented
("Any update from the dev discussion?") but got no answer, and the known problems page still says "not planned".

Anyway, it's good to hear that you are now planning to do this. I'm sure it will be worth it for low-bandwidth editors.

upgrading this to "highest" as this is the main reason for item 1 (slow loading), item 2 (slow scrolling) and item 6 (no section editing) of https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Known_problems. personally i think this should be _the only_ "immediate". why?

i tried it at https://en.wikipedia.org/wiki/Jos%C3%A9_Mourinho.

  • 1 click and 15 secs to edit
  • 1 click to make go a away a note (see attachment)
  • 1 click to edit summary
  • 1 click and 20 secs to review changes
  • 1 click to return to save form
  • 1 click and 40 secs to save
  • 5* pg down to go to the section just edited

section edit with the text editor takes:

  • 1 click and 2 secs to open
  • 1 click and 2 secs to preview
  • 1 pg-down to find the save button
  • 1 click and 10 secs to save

note blocks section edit

Attached:

james, we tried your sections within a table example from above here:
https://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor/Known_problems#section_in_a_table
and we could not create something useful.

(In reply to comment #2)

{|
! Foo !! Bar

-

=== Section 1 ===

-
Foobar

=== Section 2 ===

-
Foobar
}

Coming up with a solution to this is would be a significant piece of
engineering effort for marginal utility.

The section editing feature in the old parser works by excluding all sections headings where the heading is not a child of the document root. The previous section thus runs on past the excluded heading. This means that a section can always be represented as a set of adjacent DOM subtrees. It seems to me that the same solution could be implemented in VE.

The definition of "children of the document root" would change somewhat, since it is a different kind of DOM, so the number of excluded sections would be larger, but it would still be a better solution than what we have now.

  • The reasons we brought in section-editing originally were two-fold - to skip past confusing wikitext in other areas to find the item you actually wanted to edit (not an issue in the context of VisualEditor), and to avoid edit conflicts using the page-based diffs at the time (not an issue for ~ 7 years since Tim re-wrote the diff tool).

Section editing has never had any special case to help with edit conflicts -- it was always dealt with using the generic three-way merge feature, which, for the record, I did not write.

I think the main two reasons for implementing section editing were bandwidth and avoiding the need to scroll. Erik's original post on the subject suggests as much:

http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/3433

Note that it was implemented at a time when 56k modems were still common -- I had one at the time, and I was certainly glad of the performance improvement.

  • Editing by section blocks users from editing other areas at the same time that the notice flaws in after they've entered editing, for very limited added-value.

For large articles, I think the added value would be very large indeed. People don't want to wait tens of seconds to make a small correction, and it's likely that VE performance causes many edits to be abandoned.

Perhaps there are other solutions for the performance issue, but it seems to me that this is a fairly obvious approach, especially for bandwidth reduction.

Yes, the existing feature prevents users from editing other sections on the page, which sucks. That could presumably be addressed in VE: a separate content-editable region could be created by each section edit click, to be saved in bulk.

Kipod added a comment.Aug 7 2013, 9:44 PM

(In reply to comment #49)

Yes, the existing feature prevents users from editing other sections on the
page, which sucks. That could presumably be addressed in VE: a separate
content-editable region could be created by each section edit click, to be
saved in bulk.

i agree with Tim's comment wholeheartedly, except the last paragraph: preventing the user from editing outside the section doesn't "suck". it's a great feature.

when editing a section, we have automatically generated edit summary with the section name. for users that use wikitext editor, you pretty much know, when you see the very common "/* section name */ optional comment" edit summary, that the edit is indeed confined to the section whose name appears in the comment.

but with VE, because of the wrong (IMHO) way bug 50872 was handled, a user can press the "sectionedit" link of some section, then edit anywhere on the page, and the summary will still show the section name of the click. this makes the summary practically useless: when looking at the history, seeing a section name in the summary tells me nothing - i don't care which button Joe pressed, i care which content was changed, and the summary does not tell me that anymore.[1]

since the most urgent issue ATM for VE is unacceptable performance on longer articles with slower machines, true section edit would be (as Tim notes) a very very desirable feature.

how about this: i think that the cases where a section is not balanced, in terms of html tags (the case described in comment 2) is very rare. how about falling back to full article edit in those rare cases? [2]
true, it means that those cases would be even slower, but i believe that those are a negligible minority. the vast majority of the sections *are* balanced, and will gain greatly (performance wise) from the ability to edit a single section.

peace.


[1] this can be handled by undoing the solution for bug 50872, and solving bug 51903 instead (i.e., create the summary by analyzing the diff instead of the button the user clicked), but the best thing, IMO, would be to support true "section edit" for VE.

[2] this means: get the section content from the server, and if it "does not make sense", like the example in comment #2, get and edit the whole page.

Comment 46 ignored comment 44, hence making the priority value reflect reality again. If there are further good arguments to give this higher priority, feel free to convince the *developers* to set a higher priority again.

Mike Christie has a suggestion: Edit the whole page, but only display the chosen section.

By this I don't think he means "discard" everything except the section, but instead just to cover up the other parts. We're already scrolling to the chosen section, so this would add maybe a gray or white block over everything above that (or perhaps collapse it), and ideally everything below it, too.

This would help people who are using section editing to keep them focused on their chosen tasks, rather than because of beliefs about performance or edit conflicts.

Re comment 52: I agree that show/hide would be nice for the uneditable sections.

More importantly, if this behaviour is implemented, please make it a preference option. I often use "edit beta" on one section in order to fix a problem I see in the section just above it; I'd hate to lose that capability.

Another thought on the preference: currently clicking on a section edit gives a pre-filled edit summary including the section. Whether this happens should depend on the same preference. If I have "section-editing" set to yes, I would get the pre-filled edit summary and other sections hidden; if I have it set to no, I would get no pre-filled edit summary, and I would see the whole article, as happens now. This would help avoid the (common) situation where the edit summary is misleading when a section edit is clicked.

No, it definitely shouldn't be a preference – instead, it should be possible for everyone to "expand" the editing area from the one section to the entire article.

(In reply to Tim Starling from comment #49)

> * Editing by section blocks users from editing other areas at the same time
> that the notice flaws in after they've entered editing, for very limited
> added-value.

For large articles, I think the added value would be very large indeed.
People don't want to wait tens of seconds to make a small correction, and
it's likely that VE performance causes many edits to be abandoned.

Perhaps there are other solutions for the performance issue, but it seems to
me that this is a fairly obvious approach, especially for bandwidth
reduction.

For what it's worth...

I did a non-scientific poll and asked the Hebrew Wikipedia community what are the people's reasons to avoid VE. Precisely this suggestion came up several times.

Jdforrester-WMF renamed this task from VisualEditor: Support editing of sections inside a page to Support editing parts of a page in VisualEditor.Dec 2 2014, 10:01 PM
Jdforrester-WMF set Security to None.
Ckoerner added a subscriber: Ckoerner.
Salquint added a subscriber: Salquint.EditedJan 15 2015, 4:38 PM

I've been using Semantic Forms for more than 4 years now. It used to support the FCKEditor extension (and branch SMW+ supported the WYSIWYG extension).
But the decision to stop using FCKEditor going forward was at least related to the promise of a cleaner integration with VisualEditor (Yaron Koren would be able to
comment more accurately on that). I believe that was decided around 2012.

I'm now with a new company, and I've been tasked with evaluating Atlassian Confluence. It supports bare pages, but also form-based pages. The only significant feature it has over
Semantic Mediawiki / Forms installation is WYSIWYG editing. I can't stick with MW 1.16 / FCKEditor as I did at my previous company, so it looks like we'll to go with
Confluence... which is a shame to me, since I know how versatile the mediawiki environment is.

It doesn't seem like the work-arounds being considered would support being about do do WYSIWYG editing in a text field or the free text area of a Semantic Form.
If that's the case, it would be nice if this could be marked WONTFIX, and a new issue created that discusses compensating for the lack of an edit section as we
know it in Mediawiki.

Or, it's 2015, the solution is about to be released any day now, and I'll shut up (I can do that last one anyway).

It's entirely do-able for the developers of SemanticMediaWiki to create a VisualEditor integration for each of the fields in a form. Indeed, it's one of the use-cases we built VisualEditor around. However, it'd be a bunch of work and it's nothing we're planning to do at the Wikimedia Foundation (we don't support Semantic MediaWiki either). So effectively this is a "no" for your question.

This task is talking about using VisualEditor to edit parts of a single-content-block page, not a page made up via collections of different pieces of information.

It's entirely do-able for the developers of SemanticMediaWiki to create a VisualEditor integration for each of the fields in a form. Indeed, it's one of the use-cases we built VisualEditor around.

I have been poking around the VE and (recently) Semantic Forms looking for a place where I can dig in. This may be it. I can't promise anything, but knowing this is a place that needs work and that some of my users could use it helps.

Knowing other people want it doesn't hurt, either.

Vedmaka added a subscriber: Vedmaka.
Qgil removed a subscriber: Qgil.Apr 3 2016, 7:41 PM
Krinkle removed a subscriber: Krinkle.Apr 3 2016, 9:46 PM
Tbayer added a subscriber: Tbayer.Jun 30 2016, 5:57 PM
Liuxinyu970226 added a subscriber: Liuxinyu970226.
Jdforrester-WMF set the point value for this task to 40.May 12 2017, 12:22 AM
Beck added a subscriber: Beck.Jun 3 2017, 1:45 PM
deryckchan added a subscriber: deryckchan.
Jdforrester-WMF renamed this task from Support editing parts of a page in VisualEditor to Support editing parts of a page in VisualEditor-MediaWiki.May 20 2018, 7:36 AM
Jdforrester-WMF updated the task description. (Show Details)
kaldari renamed this task from Support editing parts of a page in VisualEditor-MediaWiki to [Epic] Support editing parts of a page in VisualEditor-MediaWiki.Wed, Sep 5, 12:40 AM
kaldari updated the task description. (Show Details)
kaldari removed the point value for this task.

Currently the main blocker (although it may not be a hard blocker) is parsing support for managing state that is page-level (mainly for reference management). @dchan is exploring doing some of the subtree editing business on the client side as something of a stop-gap solution. The Parsing team's work on server-side ref management will probably be a better long-term solution (see T146072). They are hoping to have that work wrapped before the end of 2018. Anything to add @ssastry, @dchan, @DLynch, @Esanders?

dchan added a comment.Wed, Sep 5, 2:29 AM

Thanks @kaldari! As I understand it the fundamental differences between T76541 and T146072 are:

  • With T76541 , the browser has all the document-level data (meta / internal list items, in VE parlance) at its disposal, but at a cost of the whole document being received and parsed (though not rendered, which greatly improves speed and memory usage).
  • With T146072 , the browser only has to receive and render a single section that effectively behaves like a small, simple document, but at a cost of not having all the document-level data at its disposal.

It seems there's substantial overlap where either may be adequate to achieve certain functionality, but that the tasks are actually complementary – there are use cases that would need one or the other. For instance, T76541 would be needed to suggest existing citations when adding a new reference, or to keep reference numbering accurate while editing; but you would clearly want T146072 for certain microedit-style approaches that step rapidly between documents.

Currently the main blocker (although it may not be a hard blocker) is parsing support for managing state that is page-level (mainly for reference management). @dchan is exploring doing some of the subtree editing business on the client side as something of a stop-gap solution. The Parsing team's work on server-side ref management will probably be a better long-term solution (see T146072). They are hoping to have that work wrapped before the end of 2018. Anything to add @ssastry, @dchan, @DLynch, @Esanders?

What's the worst that can happen if we let VE load a section of a page, ignoring page-wide state variables? We have made do with section edit page previews, which ignore the effects of other parts of the page on the section you're editing, without too many issues for over a decade.

Currently the main blocker (although it may not be a hard blocker) is parsing support for managing state that is page-level (mainly for reference management). @dchan is exploring doing some of the subtree editing business on the client side as something of a stop-gap solution. The Parsing team's work on server-side ref management will probably be a better long-term solution (see T146072). They are hoping to have that work wrapped before the end of 2018. Anything to add @ssastry, @dchan, @DLynch, @Esanders?

What's the worst that can happen if we let VE load a section of a page, ignoring page-wide state variables? We have made do with section edit page previews, which ignore the effects of other parts of the page on the section you're editing, without too many issues for over a decade.

From a product feature perspective, the citation functionality that people most like about VE wouldn't work (it's entirely page-level content). With the stop-gap work Ryan mentions, it will, mostly, but e.g. citations from this section but also used elsewhere won't be editable, which will be very confusing.

From a product reliability perspective, there's the risk of catastrophic page corruption from section-spanning structures (people putting headings in a table, using headings via a template, or using templates that open a div but don't close it, or…), and even if that is somehow(?!) avoided, it'll be at best confusing when some section edit buttons refuse to load.

DLynch moved this task from Freezer to Needs Discussion on the VisualEditor board.Wed, Sep 5, 4:37 PM

Thanks James, that sounds reasonable. I think Ryan's proposal is a fine
solution - we can allow sections to be edited while freezing references
that are reused elsewhere on the page, preventing them from being deleted.

If a section cannot be edited, I think users will find it reasonable when
they see an error like "This section cannot be edited on its own because it
depends on [another section of the page / name of transcluded page]. Please
try editing [the whole page / link to transcluded page] instead."

Currently the main blocker (although it may not be a hard blocker) is parsing support for managing state that is page-level (mainly for reference management). @dchan is exploring doing some of the subtree editing business on the client side as something of a stop-gap solution. The Parsing team's work on server-side ref management will probably be a better long-term solution (see T146072). They are hoping to have that work wrapped before the end of 2018. Anything to add @ssastry, @dchan, @DLynch, @Esanders?

What's the worst that can happen if we let VE load a section of a page, ignoring page-wide state variables? We have made do with section edit page previews, which ignore the effects of other parts of the page on the section you're editing, without too many issues for over a decade.

From a product feature perspective, the citation functionality that people most like about VE wouldn't work (it's entirely page-level content). With the stop-gap work Ryan mentions, it will, mostly, but e.g. citations from this section but also used elsewhere won't be editable, which will be very confusing.

From a product reliability perspective, there's the risk of catastrophic page corruption from section-spanning structures (people putting headings in a table, using headings via a template, or using templates that open a div but don't close it, or…), and even if that is somehow(?!) avoided, it'll be at best confusing when some section edit buttons refuse to load.

Parsoid currently provides <section> wrappers around HTML and these section wrappers also have editable / uneditable markers on them based on the well-formedness of the wikitect that generated them. So, a section edit scenario, if the section is opened for editing, Parsoid guarantees that the content in there does not contain HTML tags that had an incorrect overlap elsewhere. So, if you open such a section for editing (and just that section), and since VE doesn't introduce bad markup, you are unlikely to cause page corruption.

As for dealing with global state, we have two separate work-in-progress patches

  • https://gerrit.wikimedia.org/r/#/c/mediawiki/services/parsoid/+/456520/ frees clients from having to worry about global state, i.e. what happens if you delete a named ref that is used elsewhere. That patch requires clients to mark deleted references with a 'deleted' marker in the data-mw property instead of actually deleting the refences. Parsoid then handles updating state appropriately.
  • https://gerrit.wikimedia.org/r/#/c/mediawiki/services/parsoid/+/441151/ adds support for subtree editing. It effectively takes the desired subtree and computes a "closure" of that subtree wrt global state so that the subtree now behaves like a self-contained high-level document. This depends on the previous patch for handling named references.

As part of the patches above, we are adding extension API endpoints to make this support generic, since for example, there is also templatestyles, which has page-level global state when templatestyle uses are deduplicated.

It will take a little while to work through all the details to completion, test, etc. but that is the generic direction we are going towards on the Parsoid end.

JTannerWMF added a subscriber: JTannerWMF.

We need to further explore the approach.