Lol! Love your attitude Jake! Great article too :)
For what it’s worth, I have been saying for some time that there isn’t one good solution to the adaptive images problem, and we need a client-side as well as a server-side fix. I think this is pretty crafty, but I must point out a couple of fallacies in your article with regard to Adaptive Images in particular:
It sets a cookie at the top of the page which is read in subsequent requests. However, the cookie is not guaranteed to be set in time for requests on the same page, so the server may see an old value or no value at all.
In the case of AI it doesn’t matter, the cookie value will never change because the cookie value is the width of the screen, not the width of the browser. And AI has a reasonable mechanism to fall back if there isn’t a cookie at all (as documented in the older article)
The URL can only cache with vary: cookie, so the cache breaks when the cookie changes, even if the change is unrelated. Also, far-future caching is out for devices that can change width.
This i must admit I’m guessing at because I don’t understand CDNs as well as I’d like, but… the cookie won’t ever change for a given user. And, by “change width” I assume you mean “rotate to landscape” (unless you have some elastic monitors I have never seen?). Again, AI won’t break with this. AI’s cookie takes the longest screen edge and uses that as it’s width.
It depends on detecting screen width, which is rather messy on mobile devices.
I wasn’t aware of this, but looking at the evidence it’s only Android which may be getting screwy with AI in particular. At least it’s weird default of 800 isn’t too far off the 480 we’d likely want. But yeah, what a bummer – fair point :(
Responding to things other than screen width (such as DPI) means packing more information into the cookie, and a more complicated script at the top of each page.
Wrong. AI has JS available for people who have higher DPI screens, the cookie still uses a pixel value. At worst it is one extra number long. Or as I believe it’s called, a singular byte.
Other than that though, and the sheer dirtiness of your solution, I like the practicality of your approach as a current technology fix for adaptive images. I’d hate to have to use it due to how filthy it is, but it works well which is a damned impressive thing.
Another note on why I developed the server-side approach and why that is a useful thing to have as well as a client side approach: one of the design goals for AI was to not have to alter any mark-up. It was important to me that I could get a large existing body of images and code still be responsive. And I also felt that greatly simplified the CMS problem, because it no longer needed the CMS to do anything at all – which makes it easy to apply and very easy to use for people who have no code knowledge.
Also, high five for Bruce Lawsons proposed solution. That’s the kind of thing we’re needing front-end wise. You’re right again though, it does raise the issue of us potentially having three places where we have to declare width shenanigans. I can imagine that getting very tiresome.
Matt Wilcox
Lol! Love your attitude Jake! Great article too :)
For what it’s worth, I have been saying for some time that there isn’t one good solution to the adaptive images problem, and we need a client-side as well as a server-side fix. I think this is pretty crafty, but I must point out a couple of fallacies in your article with regard to Adaptive Images in particular:
In the case of AI it doesn’t matter, the cookie value will never change because the cookie value is the width of the screen, not the width of the browser. And AI has a reasonable mechanism to fall back if there isn’t a cookie at all (as documented in the older article)
This i must admit I’m guessing at because I don’t understand CDNs as well as I’d like, but… the cookie won’t ever change for a given user. And, by “change width” I assume you mean “rotate to landscape” (unless you have some elastic monitors I have never seen?). Again, AI won’t break with this. AI’s cookie takes the longest screen edge and uses that as it’s width.
I wasn’t aware of this, but looking at the evidence it’s only Android which may be getting screwy with AI in particular. At least it’s weird default of 800 isn’t too far off the 480 we’d likely want. But yeah, what a bummer – fair point :(
Wrong. AI has JS available for people who have higher DPI screens, the cookie still uses a pixel value. At worst it is one extra number long. Or as I believe it’s called, a singular byte.
Other than that though, and the sheer dirtiness of your solution, I like the practicality of your approach as a current technology fix for adaptive images. I’d hate to have to use it due to how filthy it is, but it works well which is a damned impressive thing.
Another note on why I developed the server-side approach and why that is a useful thing to have as well as a client side approach: one of the design goals for AI was to not have to alter any mark-up. It was important to me that I could get a large existing body of images and code still be responsive. And I also felt that greatly simplified the CMS problem, because it no longer needed the CMS to do anything at all – which makes it easy to apply and very easy to use for people who have no code knowledge.
Also, high five for Bruce Lawsons proposed solution. That’s the kind of thing we’re needing front-end wise. You’re right again though, it does raise the issue of us potentially having three places where we have to declare width shenanigans. I can imagine that getting very tiresome.