As a result of a weird lunchtime hacking idea, I’ve created a crude working example of the proposed picture element markup and behavior (a polyfill for a non-existent feature, how weird…).
This isn’t meant to be used in a production setting right now; it just seemed like it might be helpful to have something tangeable to work with while mapping out a preferred markup pattern. That said, I think it behaves roughly the same as existing client-only workarounds, so if it ends up proving helpful, I’ll try and maintain it as discussions progress so that it could potentially be used as a polyfill when-or-if a picture element lands in a browser or a candidate recommendation.
Like the proposed picture element, you’ll need a media-query supporting browser to see anything more than fallback content, so IE9+, etc.
- The JS uses the matchMedia API (with polyfill included in the external folder) to find matches within the source elements, keeping the last match it finds in source order.
- Per Mat’s example markup, the last element in the picture element is the fallback img element, and for the sake of this script, the matching src is simply plugged into that element.
- This script does nothing to prevent the fallback image from downloading before it is overridden by another potential match, and I’m not sure it needs to, since that’s an advantage a native implementation will bring.
- The script is configured to run when the DOM is ready, and on window resize (which tends to catch orientationchange as well).
Please let me know if this is at all detrimental to the planning stages. Here’s hoping it provides us something to play with and see what sort of markup will make the most sense in the end.