Section-level content retrieval and editing has the potential to speed up typical read and edit use cases, which is especially important on mobile. As discussed in T87556, a reasonable granularity for this would be top-level elements (direct children of `<body>`) or sections. Since the concept of sections is still a bit fluid and might end up being marked up as `<section>` elements, we decided to focus on the element retrieval portion first, without making assumptions on whether those elements are `<section>` elments or paragraphs, headings or tables.
## Implementation sketch for the retrieval portion
- mark top-level elements specially in Parsoid, in a way that's easy to match with a regexp; use that in RB to build up an offset index of element id to HTML byte range, and store it
- alternative to regexps: build an offset map while serializing in Parsoid & return that in the pagebundle (possibly in the XMLSerializer)
- In RESTBase: given a title, revision and section id(s), use the offset index to extract the requested sections from the stored HTML, and return them in a JSON blob with one entry per section.
## Implementation sketch for the save portion
- Client sends a 'changeset' JSON blob with an array of element replacements:
```
{
changes: [
{
id: "mwXXOriginalId",
replace: "<p id='mwXXOriginalId'>Modified content</p><p>Possibly new content</p>"
},
{
id: "mwXXOtherId",
prepend: "<p>Some content</p>"
},
{
id: "mwXXOtherId",
append: "<p>Some content</p>"
}
]
}
```
Alternatively, we could also support replace semantics only, at the cost of
senneeding
to send possibly untouched adjacent sections back:
```
{
"mwXXOriginalId": "<p id='mwXXOriginalId'>Modified content</p><p>Possibly new content</p>",
"mwXXOtherId": "<p>Some content</p><p id='mwXXOtherId'>Possibly unchanged original content for element</p>"
}
```
We'll also need a special ID to support editing blank pages / replacing the entire content.
- RB or Parsoid extracts the original HTML for each section, and converts it using the original data-parsoid to wikitext
- operations are applied by concatenating new section's wikitext with slices of original wikitext based on original DSR offsets for adjacent sections, resulting in a full wikitext revision
- RB returns this wikitext to the client, or directly saves the new revision on behalf of the client. The latter could be faster & more convenient. RESTBase could start a parse back to HTML in parallel with saving, reducing the time it takes to have fully parsed HTML in storage right after an edit. Minor complication is the need to check for templates parametrized on revision id.
## Other remarks
- Element-based changesets look like they could possibly be a building block of a simple collaborative editing solution. Finer-grained changes to an element could also be more compactly described in an object describing the transforms relative to the original content.