Frontend standards group/2014-10-16-Weekly
Agenda
editStatus updates
edit- 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)
- Jon's working on merging based on some of the Mantle code: https://gerrit.wikimedia.org/r/#/c/165952/
- 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
Technical discussion
editResourceLoaderImageModule
editPatch: 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
- SVG rendering class in core needs to be refactored to not be reliant on filesystem storage
- 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
editExisting 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/
- Location of template files
Discussion:
- 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
editPlanning: https://etherpad.wikimedia.org/p/OOUIDEMOS
- Use cases
- QA
- Examples
- Reference
- HIG, and how it intersects with Style Guide