Description

As mentioned in our roadmap, we would like to use Parsoid HTML+RDFa for regular page views too.

This has several potential advantages:

It can speed up visual editing by eliminating the need to re-load content for editing.

With stable element IDs / T116350 in Parsoid HTML we can explore new light-weight editing tools. The ability to associate metadata with elements using the ID lets us also implement new features like per-paragraph comments, blame maps etc.

It lets us preserve rich metadata associated with content across copy & paste. See T54091.

We are moving towards a uniform content representation with a well-defined DOM spec and improve rendering consistency between view and edit mode.

In the longer term, we can stop maintaining two wikitext parsers.

Before we can do this, we need to address several issues:

The size of compressed HTML delivered on view needs to be close to that of the PHP parser. With all metadata in attributes it is currently about 100% larger. T54936 , T1228, T78676

Site-specific CSS rules for the content need to be adjusted to work on Parsoid's more semantic HTML structures: T53245

Client-side scripts (mobile front-end, gadgets, browser extensions) can modify the DOM before editing. We'll need to either stash away a pristine copy of the content, or detect modifications based on a hash or the like & re-load content from the server to avoid this creating dirty diffs.

FWIW, I did get some informal agreement that using Parsoid HTML for "Printable page" views was a reasonable thing to deploy on wikitech, as a first step. I may try to write a standalone extension to do this.

Congratulations! This is one of the 52 proposals that made it through the first deadline of the Wikimedia-Developer-Summit-2016selection process. Please pay attention to the next one: > By 6 Nov 2015, all Summit proposals must have active discussions and a Summit plan documented in the description. Proposals not reaching this critical mass can continue at their own path out of the Summit.

With so many blocking/blocked tasks, no specific Summit plans specified in the description, and no assignee, it is difficult to evaluate whether this Summit proposal is On Track with ongoing discussion. Can someone step in as driver of the discussion and confirm the interest in getting a slot in the Summit schedule, please?

Today is November 6, and this proposal is basically not on track. Unless the situation suddenly changes and/or @RobLa-WMF and the Architecture Committee really want to schedule it, it will be removed as a Wikimedia-Developer-Summit-2016 proposal.

Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. If the session in this task took place, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to "resolved". If this session did not take place, change the task status to "declined". If this task itself has become a well-defined action which is not finished yet, drag and drop this task into the "Work continues after Summit" column on the project workboard. Thank you for your help!