61–70 of 79 posts
What I'd love to see is something similar for bandwidth sets, so lower bandwidth connections can be sent lower quality images. And then for both features to be made available for video tags.
Earlier quoted context omitted.
Fair enough, but that is a technical limitation which is trivial to get around: Always be wary of allowing arguments that hinge on "it's not technically possible" to shut down good ideas.
FTFY
Whilst there will be ways to automate the setting of such img srcset attributes based on the device (eg the PHP method mentioned that relies on a cookie) this sort of tailoring for specific device [characteristics] seems wrong somehow.
IMO this would be better handled by devices declaring their preferred viewport and/or pixel density just as they declare language preferences now, ie browser headers. Then the server can be set to send different images based on the header values and we don't have to worry about having a massive "srcset" attribute on each image tailoring to 500 different device variants. A server config would specify what viewport ranges to use and tell the server how to modify the images sent (or modify the path, or modify the location - eg switch an image with a folder called image.jpg and have filename tagged images for the different variants handled).
Perhaps this seems hacky too ...
In any case the SRCSET attribute proposal here looks short-sighted and hackish to me.
Earlier quoted context omitted.
wait hold on how does having a query string in a url make CDN's more difficult?
You would need to turn on caching on your query strings in order for this idea to be useful with a cdn (ie, both http://example.org/image.png?size=big and http://example.org/image.png?size=small would need to be cached by the cdn). The issue is if you use some sort of user tracking, or rss feed, or anything that appends unique data to the end of the URL (so http://example.org/image.png?size=small could become somethi…
This really feels like the wrong approach to me - like this will lead to "best viewed with iPhone 5" pages. Whilst there will be ways to automate the setting of such img srcset attributes based on the device (eg the PHP method mentioned that relies on a cookie) this sort of tailoring for specific device [characteristics] seems wrong somehow. IMO this would be better handled by devices declaring their preferred viewpo…
This really feels like the wrong approach to me - like this will lead to "best viewed with iPhone 5" pages. Whilst there will be ways to automate the setting of such img srcset attributes based on the device (eg the PHP method mentioned that relies on a cookie) this sort of tailoring for specific device [characteristics] seems wrong somehow. IMO this would be better handled by devices declaring their preferred viewpo…
Or, here's just a crazy out there thought. What if we save our images in high res progressive format, and program the browsers to stop downloading the images as soon as they've acquired enough resolution? Caching can be done with http range requests. Older user agents just end up downloading larger images than they wanted. Javascript and server script can use the JPEGtran library to retrieve lossless low res versions…
Earlier quoted context omitted.
FTFY
Not a good idea. Browsers that do not support imgset would show all three images using that syntax. A new element name like " " would be ignored by them.
imgset img{display:none;}
imgset img:first-child{display:block;}
I believe this should be moved to the stylesheet. We already have ways to determine media/viewport/device/orientation etc so adding different imgs would be a no brainer. Bonus point, less cluttered HTML.
That would mean the browser couldn't start downloading any image before it had downloaded and parsed the stylesheet. Or that it would download all images and the entire point of saving bandwidth is lost.
Or, you use the newly minted 'defer' (I just came up with that) attribute to let the browser know not to download anything until the stylesheet is parsed.