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é_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

-
Foo		bar

Section 2

-
Foo		bar
}

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.

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

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.

In T50429#979728, @Jdforrester-WMF wrote:

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.

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?

Are you aware of the VEForAll extension? https://www.mediawiki.org/wiki/Extension:VEForAll

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.

In T50429#4558267, @kaldari wrote:

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.

In T50429#4559065, @deryckchan wrote:

In T50429#4558267, @kaldari wrote:

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.

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

In T50429#4559824, @Jdforrester-WMF wrote:

In T50429#4559065, @deryckchan wrote:

In T50429#4558267, @kaldari wrote:

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.

We need to further explore the approach.

Just as a comment, this task is for "section editing inline with read mode", a cooler/faster system than T76541 (which is section editing on its own page). Not sure if that's clear here.

Thanks. I take your word for it that editing a section on the same page
will be *faster* than loading the section editor on a fresh screen. The
design intent is to reduce client load by putting as little of the page as
practical in edit mode.

Is this task also about supporting action=edit&section=new in VisualEditor? Thank you.

In T50429#6218951, @valerio.bozzolan wrote:

Is this task also about supporting action=edit&section=new in VisualEditor?

I don't think we have plans to add that, sorry.

I am just tyring to get the gnarly dependency graph look a bit more sane .. and AFAIK, this task isn't dependent on read views since you've all embarked on this work in previous years already. If my edit is in error, feel free to add the dependency back.

Not sure how related these are, but task watchers may be interested in T209955: [EPIC: Focus] Isolate Section Editing and children. (My uneducated observation is that the one doesn't necessarily sort the "performance" aspect of this one.)