I love the 24ways time of year, it gets everyone talking (or arguing) about some interesting ideas!
The suggestions about having the HTML spec allow for multiple image sizes (perhaps through a hypothetical <picture> tag to match <video>) and about defaulting to the smaller mobile size with a JavaScript swap, reminds me of the lowsrc attribute that used to be available on the img tag in browsers of yesteryear (it was first in Navigator, then IE4 followed suit, if memory serves).
I don’t think lowsrc ever made it to the official HTML spec (it’s not in HTML 4.01, but it is in the list of “obsolete” attributes in the HTML 5 spec http://dev.w3.org/html5/spec/Overview.html#obsolete), and browser support beyond NS4 and IE4 was spotty. In hindsight it sort of made sense, especially as we’re again looking for ways to provide a pleasing experience to users with a narrow connection (in the 90s it was dial-up slowness, now it’s visual real estate and mobile device slowness). A new version would need to be implemented in a way that’s more flexible than the “low-res / hi-res” binary choice that lowsrc added, browsers would need to know which file to actually download (lowsrc-enabled browsers would always download both resources), and there would need to be browser buy-in, so it might be a long while. In the meantime I like Darren Miller’s suggestion of using data- attributes to enhance the image tag as needed, although you might run into doubled-up resource loading if you don’t have the JS firing at exactly the right time (?).
For what it’s worth, I lean towards the argument of URLs needing to be unique for the sake of REST principles, but that does get into philosophical territory (e.g. web pages are also supposed to be served up by a URI, but depending on a visitor’s capabilities, cookies, etc., they likely do get different content, ads, features, authentication, etc.) But in case someone reshuffles this technique to use unique URLs for each generated image, I think you could add the following to your .htaccess rewrite condition stack to determine whether an image for a certain display size has already been generated:
RewriteCond %{REQUEST_FILENAME} !-f
(apologies if I’m misreading how the current setup works, I haven’t tried it out yet…)
Adam Norwood
I love the 24ways time of year, it gets everyone talking (or arguing) about some interesting ideas!
The suggestions about having the HTML spec allow for multiple image sizes (perhaps through a hypothetical <picture> tag to match <video>) and about defaulting to the smaller mobile size with a JavaScript swap, reminds me of the lowsrc attribute that used to be available on the img tag in browsers of yesteryear (it was first in Navigator, then IE4 followed suit, if memory serves).
I don’t think lowsrc ever made it to the official HTML spec (it’s not in HTML 4.01, but it is in the list of “obsolete” attributes in the HTML 5 spec http://dev.w3.org/html5/spec/Overview.html#obsolete), and browser support beyond NS4 and IE4 was spotty. In hindsight it sort of made sense, especially as we’re again looking for ways to provide a pleasing experience to users with a narrow connection (in the 90s it was dial-up slowness, now it’s visual real estate and mobile device slowness). A new version would need to be implemented in a way that’s more flexible than the “low-res / hi-res” binary choice that lowsrc added, browsers would need to know which file to actually download (lowsrc-enabled browsers would always download both resources), and there would need to be browser buy-in, so it might be a long while. In the meantime I like Darren Miller’s suggestion of using data- attributes to enhance the image tag as needed, although you might run into doubled-up resource loading if you don’t have the JS firing at exactly the right time (?).
For what it’s worth, I lean towards the argument of URLs needing to be unique for the sake of REST principles, but that does get into philosophical territory (e.g. web pages are also supposed to be served up by a URI, but depending on a visitor’s capabilities, cookies, etc., they likely do get different content, ads, features, authentication, etc.) But in case someone reshuffles this technique to use unique URLs for each generated image, I think you could add the following to your .htaccess rewrite condition stack to determine whether an image for a certain display size has already been generated:
RewriteCond %{REQUEST_FILENAME} !-f
(apologies if I’m misreading how the current setup works, I haven’t tried it out yet…)