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."
Group's public email, repo and wiki activity over time
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.
If you have any questions, please contact the group on their public list: public-respimg@w3.org. Learn more about the Responsive Images Community Group.
Matt Wilcox brought this idea up a few months ago, but the issue seemed to fall off the table and was lost in other discussions. It’s something I’d like to see get some more feedback and general discussion from other developers so I’m bringing it back up. Below are some thoughts I’ve put together for adding a type attribute to source tags in the picture element.
A type attribute would allow for a native HTML way to use new image formats, which could help decrease the load of image assets, increase site performance, i.e. WebP, JPEG-XR.
The type attribute could also be a starting point for responsive image formats. As an example, a user could specify a new responsive image format which streams its data per however that magic would work and if the new responsive image format is not supported in the browser, it could fallback to the next image in the source stack, depending on which media query is active in the source list.
Since the picture element markup is very similar to the HTML5 video element, it seems to just make sense to also include type attributes just like the video element.
I’m curious if type could be an optional attribute and only needed if you are planning to use newer image formats that would need a fallback pattern. This would be ideal so developers don’t have to specify type=”image/jpg” or type=”image/png” on each source tag
Adding a type attribute seems like a very future friendly and forward thinking action.
Adding the type attribute to source tags in the picture element seems to be beneficial with no apparent drawbacks. I’m sure there are some issues so feel free to let me know what your concerns and issues/drawbacks are of adding a type attribute.
picture is tentatively slated for inclusion under the HTML5 umbrella, rather than being pushed to HTML.next. The status of the proposal can be tracked via the W3C Bugtracker. I’ll be working with Adrian Bateman and Frank Oliver from Microsoft on a formal specification in the coming weeks, and will have an update on our progress by August 16th (per https://www.w3.org/html/wg/tracker/actions/220 ).
Laura Carlson has also been working to gather feedback from the HTML WG Accessibility Task Force on the proposed markup, in addition to being tremendously helpful in navigating the standards process. Welcome to the RICG, Laura!
I’ve asked Jesse Beach to act as the Responsive Image Community Group’s primary contact with the Drupal team to help field implementation questions and feedback.
This page is to discuss the first-draft of W3C’s <picture>-element. Discussed and voted changes will be submitted to Wiki = draft.
1) Wouldn’t we drop alt attribute from picture to make use of the full alternative content inside the <picture>-wrapper? Thought we discussed this in several threads already… I personally think this makes sense.
2) Do we really need <picture> as element-name? WHATWG mailing list and its contributors seem to have spoken that img could also work…? If it would, it would be a much smarter solution.
3) Templating ways are still missing. We never discussed this to the end…
4) Does it really make sense to provide srcset along with media attribute? I think it is much better to either use srcset and let the UA detect which one to choose or provide media and fixed source to serve as the developer wants to.
If you have any questions, please contact the group on their public list: public-respimg@w3.org. Learn more about the Responsive Images Community Group.
So I was messing with my own site when this spark started (also the same time Scott was updating the repos) and I’d like to get some feedback from outside entities. To give you an idea of what I’m talking about let me show you this little snippet (pasted below) and mind you this is just for the stupid little social icons in my footer. I’ve implemented the most recent commits from Picturefill that I’d like to personally go ahead and coin as “Divfill.”
[side note : This Divfill artist formerly known as Picturefill now appends an img element within div[data-picture]. As you hopefully will see this markup pattern can get unruly very quickly if used on a larger scale.]
I’ve also created a new branch with my own fork of Picturefill where I’m putting together a real world example using this technique of Scott’s on a larger scale –with a Flickr–like layout. I hope we can use this live example and build upon it as a way to identify verboseness and at the same time indicate what’s working. I’ve done this only because a real world example is crucial to understand what we really need. This isn’t to blow the wind out of the Divfill sail. The two example images in use are just not cutting it. As they say, the proof is in the puddin’ so here comes the spoon.
Markup using div polyfill
The following is the snippet I used within my footer. I also set my fallbacks for Retina
I’ve been fairly quiet in this group for a while now. Part of that was wanting to let the dust settle on all the chaos that was surrounding this topic a few short weeks ago, and part of that was giving myself some time to digest the bits of signal that came through amidst all the “responsive images” noise.
More and more it seems that it’s a waste of effort trying to retrofit the original srcset proposal to cover all the use cases of the original picture proposal. As we attempt to do so, the srcset microsyntax grows and more and more confusing, and shares an increasing amount of overlap with media queries. To those ends, I asked Florian Rivoal — editor of the media query spec — to join the discussion on the WHATWG mailing list and offer his perspective.
Florian joined the list by posting a brilliantly thought-out compromise between the two syntax patterns. I’d like to share my thoughts on this proposal here, as I feel it combines the strengths of srcset and picture in a practical and logical way.
Let’s begin by taking a look at the proposed syntax.
The chain of events followed by the above markup pattern are:
If the picture element is unsupported, the img contained therein is shown as fallback markup.
If picture is supported, use media attributes to determine which source element best suits the user’s viewport.
Once an appropriate source element has been selected, the srcset attribute determines which image source is best suited to the user’s screen resolution. If only a single resolution is necessary, the src attribute will function as expected.
In terms of selecting a source element, this markup leverages all the strengths of media queries — the syntax created for this very purpose — to handle the “art direction” use case that Jason Grigsby has illustrated so eloquently.
However, as has been detailed at length on the WHATWG mailing list and elsewhere, device-pixel-ratio media queries are poorly suited towards these decisions. As an author, using vendor-prefixed min-device-pixel-ratio media queries in the example above would involve a massive amount of text and twice as many source elements. This could get unwieldy for authors very quickly, a concern voiced numerous times in these ongoing discussions. Further, implementation of MQ-based resolution switching is far more difficult on the UA side: a very real concern.
Once we’ve used media queries to determine the most appropriate source element, srcset’s originally intended usage becomes absolutely ideal for our purposes: simply determining the appropriate image source for a user’s resolution.
It’s worth noting that this example is, in fact, the most convoluted this element can ever be. This pattern in no way precludes the use of srcset on an img tag for simply preforming resolution switching, nor does it preclude the use of picture as originally proposed, with src in source elements rather than srcset.
Bandwidth
The dark cloud hanging over all these discussions is the concept of “bandwidth detection.” We cannot reliably make assumptions about bandwidth based on client capabilities — a MacBook Pro with a Retina display may be tethered to a 3G phone; a high-resolution mobile device is as likely to be connected to WiFi as it is an EDGE connection.
It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms.
I feel that bandwidth decisions are best left to the browser. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this.
In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. srcset affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes.
It seems srcset won’t be going anywhere, and that’s not an indictment. There is a time and a place for srcset. I feel that place is resolution switching, as it was originally intended. Our best efforts to bring srcset closer in-line with the originally proposed picture element only stand to leave us with a siloed microsyntax that inconsistently serves the purpose of media queries. With that comes further opportunity for errors by implementors and authors alike — countless new potential points of failure.
An Updated Polyfill
In order to better wrap my head around this pattern, I’ve updated Scott Jehl’s Picturefill to make use of the proposed syntax. The source code is available on GitHub, and I’ve posted a demo as well.
Next Steps
I’ve been discussing the implementation details of this pattern with several vendors recently, and the feedback has been extremely promising.
I’d love to hear everyone’s thoughts on this compromise, and through your feedback put together a set of formal proposals: a change proposal returning srcset to its original resolution-only syntax, and a proposal for picture that focuses on the “art direction” use case and optimization for client displays through media queries, excluding resolution.
The Constant Caveat
It seems I always end my posts in much the same way, but it always seems to ring true: this solution is not the ultimate solution to every problem in the “selectively loading assets” arena — nor does it have to be, right now.
Our goal is a laser-focused solution with the potential to fall in-line with other rich media elements, as we solve the greater issues one by one — issues of bandwidth detection; issues of organization. Our goal is to solve a very real and increasingly urgent problem, in a way that serves as a canvas for future enhancements. I’m confident that this syntax affords us that opportunity.
We can’t predict the future. We can only strive to be future friendly, while solving the problems of today. I’m confident this proposal does so.
Kornel Lesinski just published a new proposal on the WHATWG mailing list this morning. He proposes a new element in HTML called <pic> which is shorter to write than <picture> would be.
This solution combines the advantages of our proposal of the picture-element and the proposal of the resolution based srcset approach by the WHATWG published recently.
The syntax also can be written in a short way and in a long way. This is good for developers because normal developers can write it the common HTML-like way while advanced developers are provided with a short-syntax.
Also the syntax is able to use @media-queries as well as resolutions.
<pic>
<source src="large.jpg" media="(min-width:1024px)" width="1024" height"="300">
<source src="medium.jpg" media="(min-width:768px)" width="768" height="200">
<img src="small.jpg" width="320" height="100">
alt text
</pic>
This of course is a first proposal to which I already replied with several improvements but it looks like we finally get in the right direction where we will get the best approach we can find together. And I am super happy that this has been proposed.
Update: After being inspired by the suggestions of Florian Rivoal (editor of the CSS Media Queries spec) and Markus Ernst over on the whatwg mailinglist Respondu now supports a new hybrid format that combines picture and srcset in a way that reduces markup and increases flexibility for the best of both worlds.
I’ve developed a basic framework that allows us to implement a responsive technique (e.g. picture, srcset or any new/improved ideas), it’s called Respondu https://github.com/davidmarkclements/Respondu
One of the main features of this framework is that it defers the loading of assets (e.g. src’s etc) until it’s finished processing (this includes script tags in the body). It achieves this using the noscript technique (discovered by filament group (?)) – except instead of wrapping img’s individually we wrap the whole body and then use a cheeky hack (dynamically wrap it in a style tag) to pull the noscript contents out (for browsers that wipe noscript contents on render).
it’s relatively unintrusiveness, you simply wrap it round all your body code
extendible, you can easily create you own implementations
Once the final spec is implemented by vendors, the technique can be used as a fallback for
browsers without support for responsive, whilst also in turn falling back again for browsers without Javascript.
Currently, Respondu has picture and srcset implementations available, for instance here’s srcset:
<!DOCTYPE HTML>
<html>
<head>
<style>img {width:100%} /* use fluid layouts */</style>
<script src=js/R.js></script>
</head>
<body>
So far, I’ve tested it in Chrome, IE8, iOS Safari, and Firefox.
If anyone would like to test in other browsers (ie7, ie9, OSX Safari, Opera) please be my guest, you beautiful person.
Respondu is currently alpha as there’s a few things to do for smooth script integration (getting it to “just-work” with domready stuff), I’m totally sure the code could be tidier, and more optimized – any contributions to the code base or posted issues are invited, and warmly welcomed.
ResponsiveImagesCG/
