Frontend standards group/2014-10-16-Weekly

= Agenda =

Status updates

 * Templating in core
 * Jon's working on merging based on some of the Mantle code: https://gerrit.wikimedia.org/r/#/c/165952/
 * Trevor has written up feedback, just needs to be submitted (Done!)
 * Brion provisionally endorsing that; Arch committee will approve once we update the RfC with status & more detailed plans [at next week's Wed checkin]
 * speak soon or forever hold your peace! (still expecting handlebars variant as a standard component)
 * first patch is transport/generic html; second patch will add the handlebars implementation. (note the current MobileFrontend-ish implementation only has a JS-side Hogan implementation, no server-side yet.)
 * Arch committe is ready to accept what FE standards agrees on at the next arch meeting (next week)
 * PHP implementation of OOjs UI
 * Patch: https://gerrit.wikimedia.org/r/#/c/160996/ (and dependents)
 * Planning: http://etherpad.wikimedia.org/p/OOUIPHP
 * Coming along well. Will get merged in the next few work days
 * Need to add testing across JS and PHP next
 * MediaWiki theme for OOjs UI
 * Seems to look better but we didn't have Prateek at the meeting
 * ResourceLoader image module
 * Trevor has hacked this together ... see below

ResourceLoaderImageModule
Patch: https://gerrit.wikimedia.org/r/#/c/165922/ Demo: https://github.com/trevorparscal/colorize Discussion:
 * Colorizing
 * Rasterization
 * SVG rendering class in core needs to be refactored to not be reliant on filesystem storage
 * ImageMagick renderer SUCKS, but may be acceptable as fallback renderer
 * rsvg -- availability/versions in production? (also known rendering limitations, but usually not a problem for icons)
 * Problems with rsvg: https://bugzilla.wikimedia.org/show_bug.cgi?id=8901 :)
 * potentially consider an HTTP-based SVG rendering service for better isolation
 * Proc_open, we have a wrapper. And a more specific wrapper for Insecure ImageM
 * Caching
 * (need per-image caching so don't have to rebuild giant collections at once after a small change)
 * Storage
 * memcache probably good enough?
 * Invalidation
 * Fragmentation
 * (rendering speed / poolcounters need? probably no need; icons are in version control, tend to be small and simple. should render fast)
 * need for non-data URI fallbacks? (IE6 static skin stuff ...)
 * Trevor considering doign SVG check in RL startup to reduce amount of stuff. Timo concerned this may split cache.
 * could expose PNG fallbacks as URLs through load.php (scary!)
 * probably only expose PNGs via URLs, don't data-URI them <- lazy rasterization is possible


 * -- Cache png binaries in memcached and/or database (maybe separate wg*cache, defaulting to mainCache/memcached in prod).
 * ++ Generated stylesheet embeds SVG and url-loads PNG. Covers all browsers. Might potentially use url loading for png in a browser that supports svgs but not data urls, but that's an OK fallback.
 * -- We need the images by url, need an http endpoint (i.e. load.php?module=x&image=y&options&version&only=image).
 * ++ They're by url and we never embed, so don't need to do svg2png in main load.php req.
 * ++ One request per image: parallisation for the first cache-miss client.
 * ++ One request per image: great caching on a per-image level at both Varnish and browser level.
 * ++ Request collapsing in Varnish will make perf pretty good. (Roan to verify Varnish request collapsing)

ResourceLoader Template feature
Existing templates => array(  'resources/mediawiki/name.html' ),

Proposal templates => array(     'name' => 'resources/mediawiki/name.html'    ), ),

mw.template.get( 'ext.mobilefrontend.name' )

OR mw.template.get( 'moduleName', 'name' ) DRY: var template = mw.template.bind( 'moduleName' ); template.get( 'name' ); I LOVE THIS Even easier porting to the Magical Future

<--

OR (magical future; needs requirejs/commonjs-like module context): module.get( 'name' ); // where module is new magical object

Patch: https://gerrit.wikimedia.org/r/#/c/165952/ Discussion:
 * Location of template files
 * Am I doing anything crazy wrong that needs to stop immediately
 * How should naming of templates work
 * How to communicate template engine type ?
 * Backwards compatibility
 * probably try to normalize the template paths on the existing Mantle users before switching to the center? question is still a bit open...

OOjs UI Demos
Planning: https://etherpad.wikimedia.org/p/OOUIDEMOS
 * Use cases
 * QA
 * Examples
 * Reference
 * HIG, and how it intersects with Style Guide