Page MenuHomePhabricator

Evaluate compatibility of <picture> for browser SVG rendering compatibility
Closed, DeclinedPublic

Description

For client-side rendering of SVGs T5593, we can use <img> but that will fail on some older browsers that don't support SVG natively. The newer <picture> allows for multiple output types and fallback content, which should allow current browsers to pull the SVG source from the <picture> and older non-picture-supporting browsers to use an <img> with rasterized PNG in the fallback content.

However, need to check whether <picture> is well enough supported that we're happy with that.

Event Timeline

brion created this task.May 4 2016, 5:01 PM
Restricted Application added projects: Multimedia, Commons. · View Herald TranscriptMay 4 2016, 5:01 PM
Restricted Application added subscribers: Zppix, Steinsplitter, Aklapper. · View Herald Transcript
Danny_B added a subscriber: Danny_B.EditedMay 4 2016, 9:53 PM

http://caniuse.com/#feat=picture
http://caniuse.com/#feat=svg-img
http://caniuse.com/#feat=svg-html5

We can also consider using of the <object> element, which can deliver SVG and has better support as well as fallback.

See also Complete Guide to SVG Fallbacks

Restricted Application added subscribers: Poyekhali, Matanya. · View Herald TranscriptMay 4 2016, 9:53 PM

For the record: <picture> is currently only in draft http://w3c.github.io/html/semantics-embedded-content.html#the-picture-element which does not automatically imply that it will be in the final recommendation https://www.w3.org/TR/html5/ (like some other elements before), so IMO it makes sense to do the evaluation after it passes at least to CR status...

brion added a comment.May 4 2016, 10:34 PM

The modern web standardization process relies on actual implementations to shake out the details. :)

That said, we may not need <picture> here, as we may be able to hack it in via srcset:

<img src="/path/to/rasterization.png" srcset="/path/to/vector.svg 1x">

An explicit 1x specification in srcset *should* override the default src. All natively-srcset-supporting browsers also support native SVG. If we adjust the jquery.hidpi polyfill to skip .svg images, then I think it'll "just work". Lemme whip up a test page.

brion added a comment.May 4 2016, 10:52 PM

Ok, srcset with svg as 1x seems to work: https://brionv.com/misc/svg-srcset/

It's worth considering result for browsers that support svg-in-img but not srcset such as IE 11. Not sure if there's a reliable way to runtime-test for svg-in-img other than trying one.

Have had bad experiences with <object> but that was in the past. Worth retesting. SVG may behave differently in that scenario wrt to things like selection, right-click downloading, click handling behavior etc.

brion closed this task as Declined.May 4 2016, 11:37 PM

Breaking the srcset trick out to T134455 and resolving this one (picture) as declined. Srcset will be less disruptive, better supported, and seems to be just as functional for this case.