Talk:Architecture Summit 2014/HTML templating

Session : HTML Templating -- https://www.mediawiki.org/wiki/Architecture_Summit_2014/HTML_templating#AgendaDate Agenda
 * 5-20 minutes - various lightning talks about the different proposals on the table
 * 40-60 minutes - discussion of big questions

Nirvana Templates
Owen Davis 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 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" min 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 code? :: Using a standard library has advantages, but you need to port the data as well (which means you have to do as much work) :: But there are still advantages – this encourages us to enhance our API * 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 People seem to be relatively sold on the idea: this is what Gabriel wanted.
 * 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

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.

* 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. 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 Wrap up: Next steps
 * 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)?
 * 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.

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