On Fri, May 13, 2016 at 1:28 PM, Jon Robson <jrob...@wikimedia.org> wrote:
> Thanks for starting this conversation Brion! > > On mobile we are constantly tackling the trade offs between data > shipped (cost for end user) and quality. Hopefully we'll have a better > solution for this by the end of the quarter which will allow us to > reconsider srcset usage. Note that srcset usage for raster images is a different issue from native SVG, in that the higher-resolution renderings *do* require more bandwidth than the lower-resolution images -- especially for photos. > That said relying on srcset to render SVGs > well seems like a hack to me and thus I'd rather we fixed the problem > at the source. > The problem is the intersection of: * some older browsers do not support SVG in <img> * <img> provides no system for automatic fallback based on the browser's format support * <picture> does provide that, but the spec is not finalized, browser support is not finalized, and it may have implications for scripting and styling by introducing a new wrapper element Using <img> with PNG in the src and a "1x" SVG in the srcset resolves the first case by feeding a compatible rasterization to old browsers, solves the second problem by using srcset support as a proxy check for SVG support (native srcset support implies SVG support in all known cases), and avoids the third problem by not using a new, different element for images. We could jump straight to <picture>, but it'll have bigger QA implications in that it may affect styling and JS gadgets that look for <img> elements specifically. <picture> would be nice for other things though -- future support of WebP for alternate, more bandwidth-efficient thumbnails, or if we start doing fancier types of responsive images based on "art direction" usages where a narrow column gets a different image than a wide window. > A few thoughts > * The ResourceLoaderImage module is being used widely to generate SVG > icons with png fallbacks. I'd be interested in seeing if we can use > this in some way for optimising SVGs and removing meta data. > Definitely yes! Just as we minify CSS and JS source, we should make sure the SVG icons are efficiently packed as well. (There's usually good opportunity to do that at commit time, but it's nice to be able to include comments and such in the source.) > * I wonder if there is an opportunity here to use BetaFeatures and > mobile beta to get a sense of performance impact of these changes? > This would allow people to opt in and for us to crowdsource feedback > in a safe enviroment. > Yes, I am suggesting exactly that. :) -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
