It’s nearly two years since I suggested a <picture> element as a strawman proposal as a way to solve the problem of responsive images, so let’s have a look at how we’re doing.
In September there was a big meetup at Mozilla’s Paris office organised by Mozilla’s Marvellous Mr Marcos who’s been very active in the Responsive Images Community Group and did the hard work of actually turning the <picture> strawman into a spec. Such is the combined allure of Marcos and Paris that a rep from Apple showed up – kudos to Edward O’Connor.
The outcome of the meeting was that <picture> isn’t a viable option. Browser makers don’t like the fact that it’s a new element that does the same as <img> (or what <img> should do if we were speccing it today), and that it depends on multiple nested children. I’d based this on the HTML5 <video> and <source> pattern, but Ian Hickson already said “we learnt with <video> and <source> that having multiple elements for selecting a resource is a huge design pitfall”.
The Paris meetup’s most immediate outcome was agreement that srcset + DPR-switching is the right initial step forward (i.e., the 2x, 3x, etc. syntax). (See Marcos’ full write-up for more fun.)
srcset was specified as part of the WHATWG specification and a draft extension to HTML5, based on Edward O’Connor’s imgset in CSS that’s already implemented in WebKit. It’s fair to say that the syntax hasn’t been received with enthusiasm by developers, as it is ugly and unintuitive. But for the simple case of sending a large image to high-dpi displays and not to 1x dpi displays, it’s simple:
<img src="normal.png" srcset="retina.png 2x" alt="otter vomiting">
Browsers with two or more device pixels per CSS pixels (“retina”) get the 2x image; other browsers, including those that don’t understand srcset get normal.png as specified in the traditional src attribute. Hurrah!
This limited version of srcset is already implemented in WebKit nightly, but not shipping, and was about to be implemented in Gecko and Blink when a proposal from Tab Atkins and John Mellor of Google called src-N made a fashionably late entrance.
It’s not the easiest syntax in the world, either, but src-N does address the three main usecases:
- devicePixelRatio based resolution switching
- viewport-size based resolution switching
- art direction
The simplest incarnation – serving high-dpi images only to browsers that can deal with them is
<img src="normal.png" src-1="normal.png 1x picHigh.png 2x" alt="narwhal regurgitating">
An explainer email shows how verbose <picture> can be for a real sites, while a blog post from Tab Explaining The Last Clause of the src-n Grammar shows a more verbose example of src-N while comparing it with its srcset analogue which is, Tab says, “fucking terrible” – much longer and harder to maintain, requiring non-trivial maths.
All the proposals are verbose and tricky. I suspect that this is simply because it’s a really hard problem, but it is one that needs solving. Tim Kadlec’s posts on Why We Need Responsive Images quantify the bandwidth that we currently waste, and wasted bandwidth costs money and slows down the site for users which has a measurable and significant impact on your sales.
Since src-N has been proposed, both Blink and Gecko have decided not to implement srcset which is currently not yet shipping in WebKit. A representative of Apple called src-N‘s use of multiple attribute “a grotesque perversion of the HTML language“, which implies they’re not eager to implement it. (We’ll ignore the irony that the company which gave us a meta tag in HTML to control presentation is accusing others of perverting HTML).
Meanwhile, the src-N explainer says “Ideally, browsers that have already implemented the basic srcset syntax would remove that as soon as possible before sites start to depend on it”, but goes on to note “it would be possible for such browsers to integrate srcset, just like src acts as a fallback”.
Adam Barth, a Blink rep, writes “I’d rather ship something that’s useful today and iterate to improve it in the future than not ship anything for a long time”, which is fair enough – but Henri Sivonen of Mozilla counters “I think srcset should be taken out of the spec ASAP before WebKit ships it and we get stuck with something that doesn’t allow iteration”. The bone of contention – is srcset subsequently extensible?
Given that src-N addresses more usecases than WebKit’s proposed dpi-switching srcset and the similarity of syntax, I wish WebKit would simply alias their nightly code and ship the minimal dpi-switching src-N given above (so src-1 instead of srcset) and argue about discuss extending it later.
But no. So, once again, impasse. Our doctors’ report: must try harder.
Added 13 November 2013: It’s been pointed out to me that srcset is also implemented in Blink, behind the “experimental features” flag. Demo. The point, however, is that it’s not shipping anywhere so no websites rely in it, and it’s not in Firefox or IE.
Added 2 January 2014: Given the impasse described above, the proposed <picture> element has been revived again and new <picture> specification is under development that combines the best features of all proposals. The most important difference from “old” <picture> is that the <source> elements control the src of the <img> element; thus, <img> is an integral part of the construct rather than simply fallback (and thus is unlikely to be omitted by authors, so “old” browsers won’t be left out.)
76 Responses on the article “Responsive images – end of year report”
It’s nowhere near being widely implemented in browsers, but I still think Ilya Grigorik’s Client Hints-based approach is the cleanest I’ve seen so far for responsive images:
http://www.igvita.com/2013/08/29/automating-dpr-switching-with-client-hints/
I don’t like any “solution” I’ve seen yet. They’re all atrocious to even look at.
Aaron, I don’t like client hints for two reasons. Firstly, previous attempts at content negotiation have failed (because browsers often lie), and secondly, not every developer has the access to the server that this would require. (In my last job, for example, I certainly didn’t.)
@Bruce, I agree that it’s not going to work for every situation (lots of people don’t have server access, as you mention). src-N/srcset would be needed to fill those gaps, for sure.
But for those of us that do have server access, it has the potential to solve the problem very elegantly, without all of the manual image resizing and markup bloat.
While content negotiation does have a spotty track record, the reasons why are generally specific to each case (see http://wiki.whatwg.org/wiki/Why_not_conneg). In the case of responsive images, it seems like a great solution to a problem where the alternatives are (IMO) labour-intensive and inefficient.
Maybe the problem is we’re trying to solve this in the markup by literally pointing to multiple files for 1 element. The syntax of srcset and src-N seems to have formalized a pattern of 1x, 2x etc. Maybe instead of literally putting all that text in an attribute we just have the regular img element with the 1x in the src with a boolean attribute that states that there are other resolutions available. If set to true and the src is “images/cat.png” the UA on a retina device would know to look for “images/2x/cat.png” and if it fails to retrieve the png it loads and works with the 1x as the default.
Not quite liking the “2x” syntax, because it’s not clear, e.g. “two times from what?”. Today, ~96ppi or even less is the norm for desktops, and is considered “1x” or the normal src attribute. But at some point in the future higher-density screen will become the majority, and then what?
I think a more verbose syntax, something *like* the picture element, cumbersome as it might seem at first, will eventually prove to be the more flexible – and desirable – option.
It’s the same thing with media queries. The reason they can be verbose and cumbersome for beginners is their flexibility. Imagine if our only available media queries where “2x” and “3x”…
I believe that the solution shouldn’t be in the markup at all. Why don’t those wizards who create the image specs come up with some backward compatible way of extending our existing image formats (primarily JPG and PNG) which load progressively as much as needed for the image in whichever context it’s being displayed using our existing tags.
Yes, I’m probably oversimplifying, and this would probably a world of hurt for browsers to implement and whatnot – but at least it’s actually a solution and not a hack; of which all the other ideas seem to be.
But as someone who builds websites in a world which clients like to manage their pages through a WYSIWYG – none of the current “solutions” slightly help the non-technical. All the technical stuff should be tucked away and handled automagically by the browser and server getting together for gentlemanly cups of tea and shaking hands on how to best display the images in their current situation.
I don’t like messing up the HTML for performance and display purposes. I thought that’s why we changed from the b and i elements to the strong and em elements. I believe that what image is displayed should be between the browser and the server. I recognize your hesitance because of past attempts at failed content negotiation, but really that’s where it should be and it could be made to work. Much better than bloated HTML.
What about browsers that have low bandwidth issues? I’m not talking just about phones or tablets but also the desktop/laptop browser. In the past I’ve had to work on a 3g connection that my phone provided because I was off site.
While we’re at it, how about differing device requirements of responsive design? A phone may need a smaller image than the desktop/laptop because of device dimensions.
What about manifest files? I would think that you would want the highest resolution images that the device can handle, but what if bandwidth is low? Do we make the user wait on a 3g or worse a 1x connection for high resolution images? If we take low resolution images because of limited bandwidth, how do we update the images when we have better bandwidth?
There still needs to be more work.
I like src-n idea. It adds flexibility to the img element and clearly has more than the 1x, 2x use case in mind. That makes if future friendly as well as currently useful.
I imagine extending the attribute to allow for portrait vs landscape orientation as well as px ratios. (src-p, src-l or h) We have Retina (at 2x) who’s to say in 2 years we won’t have another jump in resolution that would make 3x or 4x necessary. Src-n anticipates that nicely.
We already have 3x devices – Galaxy S4 and Nexus 5 are just two of them – there are others.
“Why don’t those wizards who create the image specs come up with some backward compatible way of extending our existing image formats (primarily JPG and PNG) which load progressively as much as needed”
That will only work for a number of use-cases. It will greatly reduce flexibility, because there’s virtually no control for the web developer on which type of image is display when. All the work is left to the web editor – people who are usually not too comfortable with web tech.
Your image extension would not provide in not-at-all-displaying an image in a certain viewport, as in, not even requesting the image. Nor will it be able to switch from, say, vector- to pixel-format when the other becomes more efficient at a certain breakpoint.
Then there’s the problem of the file format itself. Surely, progressive JPEG could – in theory at least – be used for this, but in practice very few programs allow any kind of control over the progressive output. Even if files would be somehow layered into smallest-smaller-normal-huge, it would mean your favorite editing program would *have* to support it fully in order to work with it, and supporting multiple images within one file is a big deal for most editing programs.
And then there’s still the human factor – editors don’t usually understand web technology. Their job is to write articles, not to understand how it works. In my experience, editors are basically morons when it comes to web tech, proven by them uploading huge files straight from the camera. This could, of course, by caught by the server, but then you’d loose all control over how the adaptive image scales down (or up) once again.
We don’t need any element. Transmission capacity of Internet will grow in future. Solution that is in this article is complicated. If human have one url with picture then he don’t want it is changed on another device, ratio and so on.
Part of me thinks this will be obsolete before it gets finalized. How soon until the majority of shipping displays are hiDPI? I think doubling or tripling the DPI of all the images on a site will be “good enough” and any advanced handling should be done server-side/proprietary and not on the client side in markup.
I’m way more interested in SVG or a vector equivalent format and a syntax that works for sizing those elements appropriately in both HTML and CSS (not pixels).
For the average programmer to add an element to adjust the granularity of an image when most all screens are clear to the naked eye seems an unnecessary , especially since technology will improve across all devices. I vote generally against adding it.
Thanks for this great recap on the state of responsive images.
I agree with Rhys and Tanny.
First, I don’t think that this is not something that should be solved with more complex markup and it points to an updated image format. Much like progressive jpg images with subset of the image denoted in the file, but in a way that the browser loads only a small metadata portion of the image and then downloads the specific image part and nothing else.
I also think that a designer or developer choosing which image a user should have or “wants” based on any criteria is power grabbing and irresponsible. Why should we decide with blanket statements that anyone with faster bandwidth want a bigger image? Or larger screens want bigger larger images? There are so many factors that it’s not up to bandwidth or screen size. There are many cases when a retina display or large screen may be on slow or expensive bandwidth, then what?
I don’t have a better idea, just don’t think that these are the best solutions. Now I tend to think like Ben that by the time this is settled it may have become a moot point.
I don’t think an otter can physically contain enough vomit to accurately depict the utter wasteland that is responsive images.
If HTML is to be kept simple, which I think it absolutely should be, no markup based solution will work. Client hints are absolutely the way to go. For sites that don’t have the ability to control their environment, the existing <img> tag is good enough.
Just quickly, your description of “retina” in the sixth paragraph is around the wrong way. It should say “Browsers with two or more device pixels per CSS pixel…”.
I like
src-N. I would have preferred the<picture>element, but at least this way we get something that covers art direction.I vote for picture. It works.
https://drupal.org/project/picture
Couldn’t we solve this in CSS? Isn’t it a issue of presentation, rather than markup?
I do agree that “1x”, “2x”, etc. are too crude to work, especially in the long run. What we have defined now as default, or “1x” or 72DPI, will likely change, also we will probably have to deal with a continuum of pixel density ratios, not discreet steps.
This can be solved with media queries, which are more versatile.
We already have media queries in CSS, only thing we would need to change would be the ability to load an image from a different source.
We would always start with the lowest pixel density image and with no change to the HTML code. Then in CSS we define where images with a higher pixel density can be found and when to use them.
Pros:
– We don’t touch HTML-Spec
– Media queries capabilities already in place
– Progressive enhancement
Cons:
– Need to update CSS standard to allow altering of src attribute of images
– Content editors can’t directly upload a set of images in one place, need to enhance for larger screens in CSS.
– In CSS we can not account for bandwidth
Questions:
– Would the browser load the initial image first, then update it as soon as he parsed the CSS? Is the CSS parsed and interpreted before that? Would we see a flicker in the image? Would that be bad?
Your thoughts on this?
really good post Bruce, this whole topic is very confusing so it’s good to get an overview of where we stand.
Given there is no accepted standard yet, and it looks likely it will take a while until there is one, if I’m using a JS responsive images technique today does it really matter if I try to use HTML from one of the current proposals? Or are data attributes just as fine for practical usage now?
best wishes,
Si
Why not just put useful info in the user agent and let the devs decide for themselves.
@Marcel thanks! Corrected my brainfart.
@simon I wouldn’t use srcset or src-* in my HTML now or assume those proposals will be implemented without changing. You might find the spec changes and your HTML no longer functions as you’d expected.
@James putting info in the User Agent string is “client hints”; see my answer above.
Another reason to not like client hints: there isn’t always a server around to respond to them. Think of, for example, mobile apps built with HTML; Firefox OS apps; local testing of HTML; HTAs on Windows; CD-based apps; Dashboard widgets; the UI for a web television; help files for applications. HTML is used in plenty of places where the HTML requested isn’t delivered over HTTP, and there’s no server around to make any sort of determination based on any user agent header.
@Stuart Langridge: This is very true. But in those cases a fallback could be used; like exactly how it currently functions.
I firmly believe the solution isn’t in the markup.
@Rhys Lloyd: the “fallback” is an image which is either too large (and downscaled) or too small (and upscaled) in various situations. I don’t see why I should be punished with worse images just because I’ve decided to write a mobile app rather than a website?
@Stuart Langridge: But if you were writing a HTML5 mobile app, then you have already greatly reduced the variance of devices/resolutions which the app will be running on. Also, if the app is installed, you don’t have the bandwidth concern. I’m all for optimisation, but I will maintain that it shouldn’t be handled by markup.
“Don’t make me think” – it applies to our users, why not to us developers as users of the technology. Leverage technology to make the smart decisions. To put that back on the developer is absurd, close-minded, and I guarantee will eventually become automated anyway as frustrated users and developers call for a better solution. An actual solution. Not a hack.
All this verbosity…
Why don’t we take a more pattern-like approach?
<img src="/path/to/foo-320-240-x1.jpg" width="320" height="240" srcpattern="/path/to/foo-{width}-{height}-x{dpr}.{format}" />
The browser would fill in the blanks in the “srcpattern”-attribute. CSS decides the width/height (in CSS pixels) and so on…
This could support serverside scaling (which hasn’t been taken too much into accoput in previous solutions – I think) and automated task (grunt and friends).
For pre-generated images there might be a need to a way to define available dpr/widths/formats – but that could be as simple as:
<img src="/path/to/foo-320-240-x1.jpg" width="320" height="240" srcpattern="/path/to/foo-{width}-{height}-x{dpr}.{format}" dpr="1, 1.33, 2" widths="320, 480, 640" formats="webp, jpg"/>
@Rhys Lloyd: what you’re proposing doesn’t make life any easier for me as a mobile HTML app developer. I still need all the separate images; it’s just that now I select between them in my build script for each platform, rather than once in the HTML.
Sorry guys you miss an important point.
Mobile Devices can show very high resolution pictures but what happen if im without wifi and have only a slow internet connection ?
I would prefer to have low quality image to load quickly and be abble to choose to switch to high quality.
Let’s focus on user needs and please keep it simple.
@keusta the src-N spec says “The choice of which image to load is left to the user agent, based on its knowledge of the screen’s pixel density, the device’s bandwidth, and whatever other factors it deems relevant to the decision.”
@Dennis Schenk: I really like your idea of pointing to the lowest resolution image and using CSS to fix this.
An additional idea would be:
<img src="myFirst-lores.png" data-pre="myFirst" data-post=".png" class="responsive">then, something like this in the CSS to dynamically overwrite the src with the right one (use your imagination, as this syntax is speculative)
@media screen and (min-resolution: 200dpi) {
img.responsive {
src: dataPre + "-hires" + dataPost;
}
}
@Dennis and @Jeff: you can already do this with the CSS content property, which is usually seen with a pseudoclass like foo:before {content: “blag”} but, by spec, can be used without a pseudoclass to replace the content of an element. Here’s my write-up of it from 2008 http://my.opera.com/ODIN/blog/css-3-image-replacement
But the problem is: all browsers being downloading the image the moment they see it in the html, so they may already have downloaded the low-res image by the time they start work on the CSS, resulting in a double-download.
Also, this method leaves no room for browsers to take intelligent decisions based on bandwidth etc.
src-n gives a list of possible images, some information about the images, and lets the browser choose the best.
@Stuart Langridge: We can already automate sprite generation (although I haven’t used it in a long time thanks to icon fonts), so for your specific mobile app development case I think automating your image generation in your build script is a better solution than making HTML more complicated.
Looking at this from a mobile-app perspective is very narrow and short-sighted.
If the images were handled server side, then the same “context loading” could not only apply for HTML images, but also images loaded via CSS and JS, without having to worry the developer about loading the correct image.
Also, let’s not forget that developers aren’t the only creators of our web. There are many, many content editors out there who only know the basics of HTML, of at all. A markup “solution” complicates this dramatically. It should be obscured and handled automagically.
In these arguments I keep coming back to the point that we have all this ability to create amazing technology, and yet we can’t seem to come up with an automated, backward compatible way for handling responsive images. It just astounds me.
@Rhys Lloyd: Automation is the word.
@Dr. Bruce Lawson: Why not a more implicit syntax like available parameters (as I suggested further up) and automate image generation (be it grunt, photoshop action or serverside) – instead explicitly listing every available image url? It’s much more DRY – and readable/writable by both machines and humans, I think.
Just to add…
Of course browser preloading won’t be able to pick up urls from my proposed syntax – as it is now. But it could be deactivated – either by recognizing the srcpattern attribute – or by using one of the proposed postpone or lazyload img attributes.
And one blaring omission from img elements: their ability to have layout before enough bytes have been loaded! Why can’t we have layout before image requests? We get a potential reflow on every image onload event. That’s a crime.
src-N looks like a versatile solution, but what urgs me is that this mass looks like another upcoming browser war, this time on the back of spec writing…
This does not help the discussion, but I have the impression that we allow the browser vendors too much say on what goes into the spec and what not. I have loads of respect for everybody involved, but originally the idea was to make the web
a) easier to code for,
b) easier to move forward quickly
c) not be depended on what ever a browser vendor comes up with.
While point b is still in happy process, point a is going to hell with all proposed solutions (sadly including picture which I liked the most so far, but seeing its monstrous dimensions in the linked mail makes me not want to use it) and point c is going to hell when I see Apple & Google fighting over syntax.
In short, lets go with src-N and its solutions, but sanitise the syntax to something that mere mortals like myself can code without coda extensions.
@Bruce: I know that one can currently ‘do’ it in CSS, with the shortcoming you mentioned – what I proposed was a change to the CSS standard, so that in certain cases, with a certain syntax, the sources get lazily-loaded, not preloaded. Else this would make no sense as you pointed out.
About the shortcoming of bandwidth: there is no reason why this information should somehow be ‘more accessible’ from HTML, but not from CSS. If a browser can make a decision based on bandwidth, it can do so in either one. Bandwidth metrics could be added to media queries, where it would fit pretty nicely imho, since bandwidth information is information about the medium or channel we are using.
Yeah, there is a challenge with older browser and their handling of such a CSS solution, but this could be solvable by the right syntax I guess.
We do everything related to responsive design in CSS, except when it comes to images, we only talk about altering HTML. Why is that?
src-1? What the hell?
This reminds me of the old days when index1.html, index2.html and index3.html were the norm.
“We do everything related to responsive design in CSS, except when it comes to images, we only talk about altering HTML. Why is that?”
I like this point a lot! To me it would make sense to keep responsive techniques grouped together. As devices and different types of connections continue to grow the responsive portion of web development could easily become a job type in itself.
It comes down to which strand of the building blocks of a website is going to be the easiest to affect change, I am guessing that getting consensus on altering the tag is going to be one of the hardest things to do. :)
> I do agree that “1x”, “2x”, etc. are too crude to work, especially in the long run. What we have defined now as default, or “1x” or 72DPI, will likely change, also we will probably have to deal with a continuum of pixel density ratios, not discreet steps.
The 72 dpi number won’t change. It is like a wildcard that means we don’t know the resolution, so place one pixel of image on one pixel of display. And 72 dpi is the zero point of the graphic arts ruler for about 50 years, including the entire Mac platform and all of desktop publishing and the Web.
The only pixel densities that make sense are whole numbers. That is the “trick” behind the way Apple did Retina. The whole thing is about graphic design math — a “high-resolution pixel” is totally made up in our minds only. If a screen has an odd pixel ratio that is as bad as being a 900×600 screen in a world of 1024×768 — nothing will look like it was designed to fit your screen. If you have to target a world of bizarre screen sizes, then you don’t use pixels and virtual pixels — you use inches. You tell a photo to show at 3×2 inches and you point to a high-res version that won’t pixelate at that size on the highest-res display. That is the “right way” to do it but it is very hard. Apple made an easy way — if you complicate it with bizarre pixel ratios that makes no sense. We basically had 1024×768 alone for many years — getting a 2x version of it is already a lot, along with 2x iPhones and 2x MacBook Pros.
HDTV to 4KTV is “@2x.” Adding support for 4KTV (aka UltraHD) to your HDTV-ready graphics is exactly like going Retina on iOS or Mac. Funky pixel ratios are not needed. If it is not an @2 or an @4 or @8 then use inches.
The reason this is all misunderstood by tech people and coders is you guys think “72dpi” and “@2x” is literal and scientific when it is just mental shorthand and a way to adapt a graphics art workflow to a set of matching high-res standard screen sizes overnight. That is why coding nerds are making the markup hard. If you want precision sizing you use inches. If you want the same old sloppy sizing on 1024×768 displays but you also want to support a matching display with 4 pixels for every 1, then you use the @2x (2x in both directions) shorthand.
So what might be needed in markup is more like this:
But what I like is just to create a “hisrc” attribute for the img tag and specify that should be an “@2x” version of the src attribute.
… and obviously a browser that is displaying on a device with a Retina display or other virtual pixels display will ignore src and use hisrc.
@media (min-width:960px){
img#special {
content: url("some/higher/res/image.jpg")
}
}
There. You’d only have to map the the CSS content rule to the image’s src attribute. Or if you don’t want that, invent some new rule that does that (“src:”, …) . Can’t be that hard, can it?
You can then invent all kinds of new media queries for dpi, bandwidth or what have you.
That said, I’m intrigued by solving the problem inside the image file format, but that’d require at least someone to write their own JPEG lib.
In a perfect world I’d solve this through content negotiation by adding new headers (to SPDY, if you you’re concerned about bloat).
Addition: Of course, you’d have to wait until the whole HTML and CSS has been loaded and parsed before you start loading images.
If that’s too much to ask, put in a new empty attribute like “responsive” on the image element, so you can tell the browser to only not pre-load these particular images, because they might be replaced by CSS.
@sush said ““We do everything related to responsive design in CSS, except when it comes to images, we only talk about altering HTML. Why is that?”
Because all browsers being downloading the image the moment they see it in the html, so they may already have downloaded the image by the time they start work on the CSS.
@Dan said “I’d solve this through content negotiation by adding new headers” – see several comments above about why conneg won’t work.
@Bruce: browser preloading is an unspecced behaviour implemented on the basis of the existing (for the most part non-RWD) websites. The upcoming postpone and lazyload attributes will foil them – src-n/srcset/whatever should too. Reasoning that any proposal that doesn’t workaround (or take into account) preloading seems odd (unless you are banking hard on the propsal’s “shimability”)?
Thank you for posting this year end summary. I was under the impression that this problem was nearly solved but it seems we’re stuck in the drawing board stage at this point.
Are there any solutions I can use _today_? Perhaps a js library while the eggheads work out something beautiful?
I haven’t read all of the comments here so sorry if this has already been mentioned, but I came across the
urloption forattr()a while back and if my understanding of it is correct, it would make responsive images as simple as:HTML:
<img src="image-base.png" data-medium="image-medium.png" data-large="image-large.png">CSS:
@media (min-width: 31em) { img[data-medium] { content: attr(data-medium url); } } etc...From the spec linked above:
Unfortunately, browser support for the
urlattribute is lacking so I created a codepen to attempt a polyfill for this… I got stuck though so if there’s anyone smarter than I then any help would be appreciated :)I agree with many others that this problem should not be solved in markup, it’s simply not sustainable. The number of images can explode if you were to take into account the many viewport/PPI combinations. Yes, it is technically possible to automate this stuff in a CMS, but it will be hard and it will take years before the world has moved to them. Furthermore, I don’t see how any of the “official” syntax proposals are any better than the current hacks, such as picturefull + RESS.
I do acknowledge we need some kind of temp solution, but we have those. Ultimately I believe we need a single image format. A single image to contain all variations, of which chunks are smartly loaded, decided by the user agent. I am aware of the many challenges for this to become a reality, but I really see no other way.
@Hamranhansenhansen
While I see can partially see your point – the Imperial system is not the measurement system to be used. HTML is not only an American thing. Use the Metric system. Nor should “the Imperial way” be catered to. Imperial needs to die out just like which W3 refuses to even give an example of what it looks like to prove a point.
http://www.w3.org/wiki/HTML/Elements/marquee
========As for this….
But what I like is just to create a “hisrc” attribute for the img tag and specify that should be an “@2x” version of the src attribute.
… and obviously a browser that is displaying on a device with a Retina display or other virtual pixels display will ignore src and use hisrc.
===========
This is not very forward thinking at all. What would you call @3x? @4x? This solves the problem “now” but not “later”. Would we have to add “ultrahisrc”, “megasuperhisrc”, etc?
We need a versatile solution that can provide hooks for shims while client and/or server features aren’t present and still make sense when they are. We need to be able to transition from what current clients and servers supports to Client hints and progressive image formats with built-in cropping data for art direction.
And the markup could as simple as what I outlined on https://gist.github.com/rasmusfl0e/6727092
Just like Ferdy says, I agree the long term solution is probably an image format which can render all necessary resolutions. An alternative, and probably more likely scenario, is that mobile internet speeds will catch up to wired speeds so that large images no longer become and issue and we can again go back to sending one full res image everywhere.
That however doesn’t solve the issue with art direction on small screens.
For today, and the foreseeable future, I think a RESS approach leveraging a responsive image service such as Pixtulate is the easiest approach (I am the founder). Pixtulate handles image scaling on the fly for any responsive layout or high resolution screen and we can crop images intelligently to support art direction.
@Rasmus suggestion is the best I have heard. All the rest of you are caught up in your own little universes pushing ideas that suit YOU rather than looking for something that will work for the people who have to use it every day such as content developers like me.
@Dave Gardner: You’re still pushing something that works for you…
I still thoroughly believe that it shouldn’t be in the markup in any way. None of my clients would ever understand any markup. HTML is supposed to be the most basic entry-level for the web – and the simplest to learn. “Dirtying” the markup is a step away from this.
Extend the image formats with an open source solution! Handle it server side. Leave the markup alone, and let our technology make the hard decisions.
@Rhys Lloyd: Video and Audio already started down this path… Maybe not for the best.
But you don’t think there’s a need for a transitional approach? We probably agree that the end goal would be a responsive image format (it may even just be an SVG-container with media queries) – but before support (server/browser/user software) has landed for it – wouldn’t it be nice if it could be shimmed at least?
That’s what I’m hoping for – hence the gist I linked above.
@Rasmus Fløe: Video hasn’t taken this path at all. We need to use 3 or 4 different formats! And that is only for the browsers, it doesn’t even account for device/screen size/resolution/bandwidth. The tag is what they were proposing the tag should be. I’m glad that idea is floundering.
The longer we stuff about trying to make shims, the longer it’s going to take for an actual solution to be devised. We’re getting around the issue now with various work arounds, and whilst not great, they’re not going to mess up our markup by implementing browser support for an interim shim before an actual solution arrives.
Focus on solving the problem. Think to the future. Whatever we devise we’re likely to be stuck with for a long time coming.
Ah great to see the progress, I agree with what Adam Barth says, – and I really want to see an implementation of this!
Our first priority needs to be encouraging lazyload and Resource Priorities.
No matter what the solution, a *usable* polyfill must come first.
Preload prevention requires a noscript tag. To support IE6/7, all the contents of the noscript tag have to be duplicated as attributes on said element, as the contents are inaccessible.
The Slimmage.js readme offers examples with and without preload. Noscript tags are a 2.4x markup increase – adding to human error likelyhood and page weight.
If we’re going to get anywhere with any syntax, we first need lazyload working in all new browsers.
But… where are all the emetic animals?
Sometimes I can’t understant what these people are thinking. Come on, srcset this way really stinks. I’ve been reading about this issue for years and the best idea so far is the proposed element. What’s wrong with nested source and img elements? Thats what HTML is all about! The fallback is there, it works, its intuitive.
Wouldn’t it be a better solution to implement the responsiveness in the image format itself instead of specifying multiple resources in the HTML. Shouldn’t it be possible to take an image format that progressively increases it’s detail depending on the amount of data loaded? The required fidelity of this image could be specified in the HTML. Just a thought.
There has been a recent discussion on the WHATWG mailing list, and seems like a modified
<picture>proposal (by Simon Pieters of Opera, iirc) finally got support by most browser vendors. You may want to update this post, or summarize the new proposal in a new post!What about:
<img src="img/original.png" set/>The ‘set’ attribute tells the browser to not download the src until the CSS has been read.
Then in the CSS you’d have:
/* min-bandwidth as a selected user preference defined in the browser */
@media all and (min-resolution: 300dpi) and (min-bandwidth: high) {
img { content: url("img/" + [src?="."] + "-300dpi-high.png"); }
}
The [src?=”.”] or something equivalent could fetch the src of the currently matched element then use the “.” as a delimiter to split the string and fetch the first result in the array. This could then be used to structure the rest of the URL in whatever arbitrary way you want. When linking to external sites perhaps there could be an unwritten convention for structuring the paths but ultimately it’d be at that particular site owners discretion.
Apologies if something similar has already been said, I only just really started to think about this last night after having read the article. It’s an interesting problem.
A few people have mentioned it, but I’ll second it – this should be in the file format, not the HTML. Imagin a JPG or PNG that contains all the necessary information to display multi-resolution images.
Adobe Fireworks uses a multi-paged PNG file format – why not implement something like that?
Obviously there’s the issue that a 1x/2x/3x display will have to download the whole image, but with some clever formatting of the file, the right bit can be streamed based on what’s requested by the browser, both based on the connection speed and the resolution (because not everyone on a crappy 2.5G connection on an iPhone 5 wants a 2x resolution image).
Anyway, that’s a dream which will never happen, so lets muck up the tidy HTML spec. Out of the srcset/src-N/picture options suggested, my ball is in the court of the picture tag. It’s based on the video and audio tag, and the source elements within can be expanded easily.
Lot of good ideas, especially from designers, and of course the big question is; How do the browser people want to handle this?
My concerns:
1. Bandwidth
2. Viewer appreciation
I’m sure we all know there will be new devices and different resolutions that we will have to deal with in the future, so just 2x will not be enough, would 2.33x or what ever work like rem?
In @media can we use a if statement to redirect to a different size image that would use a % for width.
Just my off the cuff ideas, great topics and I’m glad better minds than mine will be making these decisions.
The newest
<picture>element draft with backing by all big browser vendors can be found at http://picture.responsiveimages.org/.To know the right image size is not just a question about dppx/dpi/dpr/… (pick one and make it standard) it’s about will the user be there when it has done downloading – remember when
56k modems ruled the world and 100KB was a lot.
In order to make a proper estimate on the time of delivery we need information about the current network status but sadly no browsers make those important data available (let me know if I’m mistaken). In order to collect the data ourselves the (maybe) only way is to spend time and bandwidth and we would rather spent that on our images.
While waiting for the world to change – here is an idea for a client side solution using the noscript tag to provide information on the hi-res images and a nested fallback image.
<noscript data-src=”image@SIZEx.png”>
<img src=”image.png”>
</noscript>
Now if javascript is enabled and window.devicePixelRatio is let’s
say 2 and the bandwidth seems fine – just replace the noscript tag with an image and set the src attribute based on the the data-src (replacing SIZE) and we are happy. Using the noscript tag prevents the image from being loaded if javascript is enabled – and we only load one image :). This method can also be extended to handle lazy load etc.
A quick test: http://codepen.io/jakob-e/pen/frivb
Best,
Jakob E
I think the biggest problem is bandwidth or rather the lack of available network information provided by any browser (please tell me if I’m wrong).
No browser (to my knowledge) makes the data on current bandwidth available to the developers – we have geolocation but telling us about network seems too hard
To test the bandwidth you need to know the current situation – not 3G, 4G or… and the only way to test that is by using bandwidth.
<noscript data-src=”image@2x.png”>
<img src=”image.png”>
</noscript>
OK – where did the edit comment button go? Sorry for the not intended PS. And for H5D not having a feature to let me fix it ;)
I like what @Matt Kieran suggested.
I think the biggest problem for responsive images, or any asset linked in the mark-up, is our lack of control of when (or if) these assets are downloaded.
We should be able to inform browsers which assets should not be downloaded immediately (while still using the src attribute for our actual image).
We can then use JavaScript to make a decision on weather or not to use the default source, or make a logical decision to load the appropriate image based on our specified criteria (view-port, pixel density, etc).
A simple flag as an extra attribute for img would work really well, (or maybe even a new meta tag that can include this information globally, dunno if that would work..).
So for example: <img src=”potato.jpg” alt=”a potato” defer=”wait-for-js”>
or even just: <img src=”potato.jpg” alt=”a potato” defer>
Like this, we keep almost identical mark-up, with only a very concise flag that the browser understands.
I think this would degrade pretty gracefully too for older browsers that didn’t allow for deferring the download of assets.
They’d just get the default source, (downloading immediately of course).
Search engines would also be able to index these images, and the mark up is valid and simple.
I know mobify.js has a capturing api for this kind of thing, but I really think this should be simpler, and provided as a feature baked into the browser, and not dependant on large js libraries.
Server side solutions are OK – but not all encompassing, and will have differing dependencies for every server environment in use. Performance can also become an issue here too. It is difficult for a server to gain accurate insight into what browser you are using, viewpoint and pixel density.
This solution has got to be within the client scripting environment – It has all the resources to decide which assets are best for its particular environment, and can also be used to detect connection speed if needed.
Looks like i’m a little late to the party! – just found out about the new W3C Resource Priorities draft for lazyload and postpone:
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html
Looks like it could develop into something interesting.
Is there reason not to simply provide a src-N tag for any new ratio to be supported?
src-N is dead now. Long live srcset. Look forward to !
Just received this update from the filament group http://filamentgroup.com/lab/picturefill_2_a/?utm_source=Responsive+Design+Weekly&utm_campaign=ca05ff1258-Responsive_Design_Weekly_106&utm_medium=email&utm_term=0_df65b6d7c8-ca05ff1258-58981737
Maybe you can get their attention: Extended purpose users need user-defined elements e.g. X0-X9,XA-XZ, with some predefined as parents-and-children would be a nice touch…
I currently have commandeered DL,DT, DD, but these no longer stack like they use-to till IE8, and never did in FF and Chrome…
Ray.
I reposted the example with the correct HTML.
I read part of the documentation at http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content.html#embedded-content and my first thought was that it seems too verbose.
Consider this example:
<img sizes=”100vw” srcset=”wolf-400.jpg 400w, wolf-800.jpg 800w, wolf-1600.jpg 1600w”
src=”wolf-400.jpg” alt=”The rad wolf”>
It adds a lot of additional code only for repeating the same concept:
the browser needs to pickup a different image if the viewport is different from the default.
Why don’t you add a tag “inside” the image name?
The browser will search on the server for the correct image :
<img sizes=”100vw” srcset=”wolf-[[vw]].jpg”
src=”wolf-100.jpg” alt=”The rad wolf” >
[[vw]] will be replaced by the browser.
This approach is also compatible with future improvements, if I serve the images using a service and I decide to offer images with a greater resolution, I don’t need to change all the tags in my code.
If you want to avoid 401 error for viewport not supported by the image we can add a <viewport> element with the supported viewports:
<viewport enabled=”400 800 1600 3200″ default=”100″/>
Am I simplifying too much this topic?
What about having the following solution:
– Introduce a new image mime-type for responsive images: image/rpng, image/rjpeg. The file extension remains .jpg, .png so that the server can fallback. That image format will deliver the content of the image in a progressive manner depending on the clients capabilities.
– The content of the image would be the highest quality available.
– Bring the HTTP Servers (Apache, IIS, etc…) to understand the new mime-type and deliver the image content depending on the clients capabilities
– The client can specify to the server in which quality he wants such images delivered (low, medium, high, full), may be using a new HTTP-HEADER. In case there is no server (local app), then the image is fully loaded
– The combination of the client capabilities will result in the following image qualities that can be requested from the server: low, medium, high, full. So it is up to the client to determine what quality of images he wants to request from the server.
When the client requests for:
– a low quality image then the server delivers a limited amount of data, lest say 30%
– a medium quality image then the server delivers 50% of data
– a high quality image then the server delivers 80% of data
– the full image then the server delivers 100% of data.
Lets say the client requested initially for a low quality image because it was on a 2g connection. Then 30% of the image data got delivered. Then the user switches to a 3g connection. Then the client can detect the change automatically and request for the high quality image providing the server with a hint telling that the low quality image has already been loaded and thus avoiding to load it again. Then another 50% of data is loaded (since the client already has 30% of the data in the cache, it only needs to load the 50% up to 80%)
Now when the user switches to a WiFi connection the full image is loaded. This time only the remaining 20% of data is loaded from the server through the same mechanism.
The could be an option in the client where the user could override that default behaviour and choose to always load the low, medium, high or full image.
So recap:
1- New responsive image mime-type
2- Server to understand new image mime-type. If not then it will fallback to delivering the full image
3- Client to specify what quality it wants (low, medium, high, full)
4- Server to read what quality the client wants and return the amount of data progressive
5- Server to return data diff based on a starting point, for example high image requested and starting point is low then return only high-low data.
6- Client to request more data when the user switches to better connection.
7- User can override in the client the quality of the images to be delivered
What do you think?
Wouldn’t a more general purpose extension to .png, to include panorama zooming, be the better solution to image-resolution selection, (aside implementing something like rpi’s SPIHT)…?
Leave a Reply to Krzysztof Karski