Our goal is a markup-based means of delivering alternate image sources based on device capabilities, to prevent wasted bandwidth and optimize display for both screen and print.
Note: When the group expanded its scope in November 2014, it changed the name from "Responsive Images" to "Responsive Issues."
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
I’ve been working on a JS implementation of the picture tag. It is important that a JS implementation is possible – if a JS implementation isn’t possible on older/current browsers, then these older/current browsers will display the mobile sized image.
Chrome, FF and Opera came together very quickly, as ever though IE7/8 is slightly more challenging, but the real stumbling block is IE9.
The picture tag version I’ve been working on implementing is [3] in the etherpad
<picture>
<source />
<source />
<img>
</picture>
Approach One: In non-IE Jquery allows us to select the Elements. This makes life very easy, we can just select the picture elements, loop over the source elements and regex the contents of the media attribute:
http://jsfiddle.net/7555C/4/
Approach Two: In IE7/8 it gets a little more tricky as we can’t directly select the picture element. We can however select the image element, and then get it’s parent, and then get it’s parents inner html, and then regex the required information out of it:
http://jsfiddle.net/BKAWp/6/
Neither of these approaches will work in IE9 though. In IE9 we still can’t select the picture tag, and the source elements actually get removed from the html. (I’m assumming this is because they are recognized as elements, which are invalid in that location). If we have no way of accessing the information in the source element then we can’t use that syntax.
Because IE9 doesn’t recognize pic-source it doesn’t remove it from the html, and then we can use approach two:
http://jsfiddle.net/rerGC/17/
There are also a couple of other differences, IE9 doesn’t like <pic-source />, and needs <pic-source></pic-source>, else it places the img in the pic-source element. Also IE7/8 return the inner html in part upper, part lower case, IE9 returns it all in lower case.
(I’m not particularly attached to <pic-source />, it just needs to be different from <source /> so IE9 doesn’t strip it out)
Please don’t view the code in fiddle as finished, it needs to be combined into one place, and further performance tweaks need to be looked at, however it will provide a proof of concept, and more importantly show the syntax we’re proposing is usable on older/current browsers.
After checking out the etherpad with brainstorming, asking some questions in this group and seeing what Scott has done with the proposed markup using <picture> , I like the way we go. Now I clearly see the reasons why we can not re-use <img> . I see why some other proposed solutions don’t deliver what we need and how <picture> solution tries to solve some of those concerns.
But today, after the Matt’s post I realized that there is something more we should keep in mind. There are certain ways people used to interact with the images on the web. There are certain conventions. Saving images to a user’s hard-drive, maybe referencing an image in a visual editor’s “Add Image” drawer to name a couple.
I gave another though to the <picture> element on how we can deliver the responsiveness and, at the same time, let the conventions work still. Here is what I came up with:
<picture>
<source query="(min-width:420px) and (max-width: 767px)">
<img src="http://dev.null/small.jpg" alt="Alternative text for capable browsers wider than 420 but narrower than 768px" />
</source>
<source query="(min-width:768px)">
<img src="http://dev.null/large.jpg" alt="Alternative text for capable browsers wider than 768px" />
</source>
<img src="http://dev.null" alt="Alternative text for browsers not understanding CSS media queries or screens smaller than 420px" />
</picture>
So, as in the original proposal, we have <img> fallback for the browsers not supporting CSS media queries. The same <img> fallback is used for capable browsers in case none of the media queries is true. We have a set of <source> elements to reference different versions of the image. The differece is that I intend <source> to contain real <img> tag. Any browser knows how to deal with it and it is clear for any user what to expect from it. Additional advantage is the flexibility we get in supplying more information than just an image for different media queries. For example a caption for an image or alike (though it starts smelling like <figure> already).
What I like about this solution.
This can be re-used for anything, not images only. If we decide to let wider usage of this pattern, we might just easily drop <picture> and leave those <source> elements with query attributes standalone. Imagine using this for different navigational elements depending on the screen size, supplying a screenshot instead of full-size video on the smaller screens and so on.
No need to duplicate browsers’ functionality reserved for <img> tag.
Not breaking conventions users got used to when dealing with images on the web.
What I don’t like about this solution.
Duplication of the alt attribute for the images. Though it might be an advantage. You might need to supply completely different image for smaller screens (consider complex chart on a wide screen that is significantly simplified for the smaller ones) where alt text should be different for different screens.
Mixing presentation with markup by using CSS media queries. Though, pretty much any solution we came up with until now had this flaw.
Use of the new element ( <picture> ). But, as mentioned above, we can ditch it and leave standalone <source> elements instead. <source> is an existing tag. Though query attribute has to be implemented yet.
Not very elegant markup.
Maybe a little bit too much flexibility — some people can go nuts supplying different content for different resolutions. This can easily break usability of the sites.
UPDATE I don’t like that this doesn’t work in the browsers just now even if one tries to polyfill it.
Browsers should implement a mechanism to not download an <img> if it is within <source>
UPDATE This pattern is new and does not correspond to the existing usage of <source>
It doesn’t look like my account has permissions to add this page to the group navigation or link it in the sidebar, so I’ll post it here for the time being. Let me know if there’s anything you feel I should add, remove, or change!
There’s an issue with this that needs addressing. Currently there’s only ever one resource and so that’s what get’s downloaded. When we are adapting to the device’s capabilities, we’re generally doing so for performance reasons. However, when someone wants to save an asset I think it’s reasonable to ask whether they want that exact asset, or will they want the best representation of that asset?
Is this more of a browser behaviour issue or something we should tackle as HTML?
I’m loving the <picture> element proposal but I do see one problem with it in a practical sense rather than a functional sense: failing DRY principals.
In a real world use I would imagine (and please weigh in on this) that the adaption points for almost all images on any given page, or even any given website, would be the same points all the time. i.e., the design itself could have lets say 4 break points, and all the images are likewise likely to have 4 breakpoints. So repeating the same media rule on every single <picture> element is going to get tedious quickly. Imagine a gallery page with the same rules repeated over and over.
Can we get a way to set a “master” or default set of break-points, somewhat like CSS variables (constants), which are assumed in subsequent <picture> elements, but can be over-ridden on specific cases if needed?
Or is that out of scope for HTML?
I bring this up because I think it’s important to consider the principle of adapting content to the design rather than the device. It’s the design that adapts to the device and the content adapts to the design. In terms of prior stuff that works on this principle http://adaptive-images.com is intended to use the same breakpoints as the design in order to adapt content images.
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.
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.
There was a lively discussion regarding Responsive Images that took place at WhatWG recently: [ The discussion link ]
This is not to suggest that the solution proposed there should be used or even necessarily considered, but it’s probably interesting at least as a reference.
ResponsiveImagesCG/