Architecture Summit 2014/HTML templating

Subpage for the discussion of HTML templating at the summit.

HTML templating

Proposals that involve adding an abstraction layer for server-side and/or client-side HTML skin/user interface generation

Slide deck: https://docs.google.com/presentation/d/1bi5tddMFKVXJ0o1qMvBn_5kIzcbI_1IzkZMsLbOgY_E/edit?usp=sharing

Overview

The main focus of all of these RFCs is around HTML generation for user interface elements. This category is not about wikitext templates or anything to do with how we translate wikitext markup

"Template Engine" is Chris Steipp's submission outlining the use of Twig. From my conversations with Chris, it's not so much that he's eager to adopt Twig specifically so much as standardize on *something*, and make sure there's usage guidelines around it to avoid common mistakes. He's seen many attempts at per-extension template libraries that bloat our code and often start off with big security vulnerabilities. There are many extensions that use Twig, and it seems to be a popular choice for new work, so Chris is hoping to standardize on it and put some usage standards around it.

"HTML templating library" is Ryan Kaldari's submission, promoting the use of Mustache or something like it. His main motivation is to have a Javascript template library for front-end work, but is hoping we choose something that has both Javascript and PHP implementations so that any PHP template system implementation is compatible with what we use for Javascript templating.

"MVC Framework" is Owen Davis's description of Wikia's Nirvana framework, which has been central to all of the user-facing work they've been doing for the past 2-3 years. As Owen points out in the talk page for this, it's really view-controller rather than full MVC. A big plus of adopting this RFC is that it would make it much more likely that Wikia-developed extensions (of which there are many) would be of greater use to the larger MediaWiki community, and would generally help facilitate greater collaboration between Wikia and the rest of us.

"OutputPage Refactor" is another submission from Owen Davis, which isn't really about templating, so much as taking the HTML generation code out of OutputPage. Wikia has been maintaining a fork of OutputPage for quite some time, so they already have quite a bit of experience with the proposed changes. This is clustered with the templating proposals, since I imagine the work that gets factored out of OutputPage would need to be factored into whatever templating system we choose.

The Parsoid team is working on HTML templating for content, UI and messages. The security requirements are basically the same as those discussed in Chris' "Template Engine" RFC, with an emphasis on automatic contextual sanitization of user input to avoid issues like XSS. AngularJS is the current front-runner for an implementation starting point.

The first three seem somewhat mutually exclusive, though it's clear our task is likely to come up with a fourth proposal that incorporates many requirements of those three. The Parsoid work shoots for a long-term solution, but is just starting and initially focusing on JS. The OutputPage Refactor proposal, given some fleshing out, may not be controversial at all.

Big Questions

What aspects of performance are important in this conversation, and just how important are they?
What features should we generally avoid in templating languages?
What features are essential?
Is Javascript/PHP compatibility important? If we don't pursue a dual strategy, is it more important to tackle PHP or Javascript first?
Is template inheritance important?
Do we want to consider opening up templating to on-wiki use, or just developers?
How important is existing usage? How entrenched are any incumbents?
How should we arrive a decision?

Agenda

Etherpad: https://etherpad.wikimedia.org/p/html_templating

5-20 minutes - various lightning talks about the different proposals on the table
40-60 minutes - discussion of big questions

Discussion at Architecture Summit

Nirvana Templates

Presentation by Owen Davis: https://commons.wikimedia.org/wiki/File:Wikia_Nirvana_Templates.pdf

questions:

kinda needs some special knowlege of what will go in (great for single-skin wikia, might need generalization for other use)
- Explicitly includes extensions directly from skin. Different from MediaWiki's usual general hook flexibility
what could we change to make HTML-escaping easier? (this is listed as not being fixed by the current code)

HTML Templating Engines

Presentation link: https://commons.wikimedia.org/wiki/File:HTML_Template_Engines_for_MediaWiki.pdf

Gabriel Wicke, Ryan Kaldari, Chris Steipp, and Jon Robson

MW lacks standard MVC framework
long term plans to move to HTML storage on backend (we'll need a template language that's friendly with VE etc)
-> HTML-based templating, starting with UI messages
- Might later be used for on-wiki Templates (longer-term)
currently we have lots of custom half-hacked solutions along these lines in various extensions and 3rd-party uses. Please unify!
"avoid jQuery spaghetti"

Minimum requirements

boolean if/else
array handling
secure by default (escaping!)
extensible to accomodate i18n <- pass in a message key or object and have it Just Work
small client-side footprint
readable
commentable

candidates:

many mustache/handlebars thingies; PHP and JS versions exist which has an advantage
twig/swig
nirvana (wikia's php solution)
angularjs, knockoutjs -- on the JS end
"write our own!"

security

manual vs automatic context-sensitive escaping to avoid XSS!
more automatic & clarity is good, can make things MUCH easier to sec-review
DOM-aware libraries seem to work well with escaping

performance

not a huge variation, usually pretty fast

power:

logic-less template lib can require more add'l work
but they're easier to read

option 1: long-term solution first.

parsoid team prototyping simple DOM-based templating. angular-like.
try to finish it up in a couple months
if fails, move on to option 2

option 2: temporary solution first

work with string-based system (Handlebars) with manual sanitization. may be security regressions :(

develop longer-term DOM-based solution

Queue up questions here:

do we need to be able to share templates with API clients, mobile apps, etc as well as core PHP+JS

Using a standard library has advantages, but you need to port the data as well (which means you have to do as much

But there are still advantages – this encourages us to enhance our

Are there really no templating solutions that aren't good enough?

Ori says it's pretty unlikely that we really have unique needs AND can keep up with the browser technology

is there any downside to going with DOM right away?

It says Handlebars relies on "manual sanitization". Isn't it enough to use the normal double-curly braces?
Shadow DOM etc -- should we get into this race?
- http://wiki.whatwg.org/wiki/Component_Model#Shadow_DOM
It would be kind of cool if we had a side-by-side comparison of the different options
Roan interrupts on scope: Do we want to use this for wikitext templates as well

People seem to be relatively sold on the idea: this is what Gabriel wanted.

I think this should be a separate discussion. We already have wikitext templates and Lua. Adding a third one on-wiki is a major decision, and affects maintainability (language will probably not be exactly the same as the UI template language(s)).

Trevor discussed using a widget library (if only such a library existed)
- oojs-ui (yes, that was the joke) (https://www.mediawiki.org/wiki/OOjs_UI)

Trevor says it's particularly useful for interface generation

Might be helpful to combine the two (Brion) – some sort of recursive thing.

use a template library *as* your widget library
some basic ability to call other templates (w/ dependencies on RL load for JS side)

Success criteria for this session:

Tim: Deciding on "Option One" (coming up with our own thing), versus "Option Two" (using somebody else's)

Brion: Pick a direction

Queued comments and questions

Dan (Milimetric): Knockout http://knockoutjs.com/ provides a more holistic approach, where you change the definitions and knockout sorts out the behaviour
Matt (Superm401): security implications of string-based (handlebars etc)? (some do by default, some don't.... but eg if you forgot your double-quotes you might be damaged!) Engineers might write templates rather than designers for safety?
- I was actually saying engineers might write them in general (this remains to be seen)
- The explanation was that while curly-brace style string templates do escape automatically, Html::element and friends have specific handling for things like certain attributes (e.g. I think href was mentioned).
Ori: What special needs do we have that mean we can't use an existing framework?

Gabriel / Ryan point out that user-editable templates are one thing. templates get built by community as well -- translated messages and customized messages. safety first?

I don't really think i18n messages should be doing these types of templates, particularly if there's any security issues to be thought
- Customized messages (modifying pages in the MediaWiki namespace) are not the same as templates (Template namespace) or Lua modules (Module namespace), and should not be conflated. MediaWiki messages can have multiple different parsing models; only 'parse' is similar to full wikitext parsing.
Nik Everett: Should we really share templates between the client and server applications?
Shahyar: Are we open to new options? What have we tried?

Ryan: Comparison is on the original RFC (link plz) https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library

Nobody supports "Do Nothing" option

Trevor says that widget libraries are necessary to make sure that we can plug in / out different widgets.

vote of some sort? we're kinda confused :D hmmm.
derailment on whether trees of widget libraries and templates are the same thing or not -- Trevor says that a widget has a narrower API.
* Can we put up some oojs-ui and Mustache code so people can get a basic idea of the difference (and delve more deeply later)?

such disagreement

very controversy

wow

https://upload.wikimedia.org/wikipedia/commons/thumb/f/f6/Boxing_current_event.svg/500px-Boxing_current_event.svg.png

Other comments

How do we implement a DOM system in PHP?
Jon: We don't want to proliferate standards – we need at the very least a common interface.
Owen: Likes widgets. MW is a web framework, and having a widget library would help us to stop proliferating standards. Widget systems are a lot of work. Would max out complexity.
Inez: Performance. Likes knockout – works on DOM performance.
Markus Glaser: 3rd parties need to be able to alter/extend templates.
Katie: Working with PHP backend is really important.

Wrap up: Next steps

Support for changing status quo

Tim: Spec. Let's not standardise on one thing and then standardise on something else.
Brion: NFI. Go with something existing and give it a go.
DJ: Migration is not that much work – so going the wrong way and experimenting is okay.
Juliusz as well
RobLa: We need a working group which can come up with a short term trial solution.
Timo: rollout a group at a time, have some early adopters
- I would be interested in helping with this. (MarkH?)
Brion: someone should investigate existing work in VE & co to get a better idea of the widget/template distinction and how we can make sure low-level crud doesn't get done by default