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.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T44725 Multimedia file format support (tracking) | |||
| Open | None | T138665 Support SVG interactivity and animation in media-viewer | |||
| Open | None | T5593 [Epic] SVG client side rendering | |||
| Declined | None | T134409 Evaluate compatibility of <picture> for browser SVG rendering compatibility |
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
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...
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.
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.
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.