Talk:Parsoid/Roadmap

Notes from Parsoid team meeting on 2013-01-09

Storing HTML DOM instead of Wikitext

• Concerns

• Templating

• Recursive parameters to templates might be difficult to represent as DOM fragments - especially when the template is affecting an attribute
• Wikitext template parameters are not necessarily properly nested (token stream)
• What constraints, if any, do we want on template parameters?
• What constarints, if any, do we want to enfornce on template and extension output?:Ex: well-nested DOM

• Enforcing properly nested output of individual templates or combinations of templates is actually not that hard

• Supporting templating capabilities on DOM that is equivalent in power to wikitext templates
• What additional meta information needs to be added to the DOM to support the new functionality (fragment caching, parsing, etc.)
• Possibly, don't support the new templating language (expressions, iteration etc) within articles, but reserve for a special namespace or content-type
• Multiple template languages: Lua, wikitext are special cases of a general pattern
• Possibly have some way for templates/Lua to specifically support visual editing

• Lua modules can maybe export a %%__%%veinfo%%__%% method or similar to describe its parameters (using RDF schema similar to templates?)
• Templates could probably have a subpage (e.g. /doc on enwiki templates, but for machines instead of humans)

• We already set the RDFa namespace for the template to the template page, which could include an (RDFa-encoded?) schema

• And a hook for rendering, see below
• Non-compliant templates/Lua modules/tag extensions can easily be alienated (but that's not Parsoid's problem obviously)

• Benefits

• Faster than a parser
• The cluster won't be overly affected by the change, as storage is organized amorphously

• Things we need to do

• Make a prototype that people can see in action, so we can convince them to take it seriously
• Tag extensions

• Maybe use an HTTP GET request to MW to get the result of any parser hooks (maybe use this for Lua, templates, etc. etc.)

• Current Lua is hard to support outside of the PHP preprocessor because of parent frames etc
• Can enable ESI (Edge-Site Includes) which we could use for fast-changing fragment from e.g. Wikidata

• Methods to provide access to HTML-expanded article text

• Warmed cache

Random thoughts If wikitext support is removed, wiktiext-based editing can be supported via an extension Way for a template to set its own "max-age"

ESI would be a benefit for logged-in users

What is the implementation path that lets us experiment with html storage while meeting VE launch goals for the summer?

• side-by-side html storage for sure, but more details.

Etherpad etiquette: Name yo'self!

non-WMF wikis

"We will support simple HTML-only wikis with VisualEditor front-end without the need for a Parsoid installation. Besides other tweaks, this means that we will be providing a visual diff interface in place of the current wikitext-based diff."

Great news! Sharihareswara (WMF) (talk) 05:09, 25 January 2013 (UTC)

Research / prototype: HTML-only wiki support

It is excellent news that you are working to make it possible for smaller Mediawiki installations to use the VE. However, I fear that the path to combine this with "html-only" wikis is not welcome. For the foreseeable future smaller wikis will need many features beyond diff that are presently based on wikitext, especially for import/export, mass-replace, refreshing-operations, etc. Furthermore, independent of the size of the wiki-installation, most wikis have experienced editors which are likely to prefer continuing to tackle editing, and especially editing problems in wikitext.

I would therefore like to encourage you to focus resources on making it as simple as possible for small installations to install the full feature set, with wikitext and html working in parallel and parsoid combining the two. --Vigilius (talk) 23:49, 30 January 2013 (UTC)

DOM templating

Re attribute-based templating for visual editing, cscott comments:

Or something like handlebars.js? cscott (talk) 18:42, 1 October 2013 (UTC)

Handlebar does not actually provide attributes to work with in a visual editor. The association between template and logic is all defined outside the HTML itself, which makes it harder to let the user discover or call code that affects a given element in the DOM.

Handlebar also seems to be string-based with optional HTML escaping. -- Gabriel Wicke (GWicke) (talk) 19:09, 1 October 2013 (UTC)