Frontend standards group/2014-10-16-Weekly


Status updatesEdit

  • Templating in core
    • Jon's working on merging based on some of the Mantle code:
      • 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
  • 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

Technical discussionEdit


Patch: Demo: 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)
  • 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 featureEdit

Existing templates => array(




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


mw.template.get( '' )

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


  • 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 DemosEdit


  • Use cases
    • QA
    • Examples
    • Reference
    • HIG, and how it intersects with Style Guide