[whatwg] add html-attribute for "responsive images" Mathew Marquis

[Mathew Marquis]

> I think we need to decide whether markup-based solution is a workaround forced on us because there was no good solution or whether it is a solution we should pursue, if implemented properly.

To your first point: I figure we do have solutions already, even if they’re not spectacular. A completely JS-based approach is perfectly viable, if a bit wasteful on larger screens; we have one in place on BostonGlobe.com right now. I wouldn't say this is a gut reaction from a handful of developers backed into a corner, by any means.

Really, it follows the same logic that seems to have gone into the "media" aspect of <video>’s sources: if we can prevent wasteful requests in a way that predictably falls back for older browsers, why shouldn’t we? Where the source logic would only be limited by MQ it would allow us to, say, serve high-res images to higher DPI screens without incurring any cost to lower DPI screens, without requiring UA detection or server-side logic.

On the other hand: if one were to want to automate the cropping process, the various sources could be generated by server-side logic and output to the page.


> And this brings us to a very technical discussion about RESTfulness of either approaches (server-side negotiation vs. markup-based descriptors).
> 
> -- Pros of server-side negotiation:
> 
> If you look at an image as a unique resource, then representing it with a unique URL and adjusting diff crops or resolutions of the image for device-targeting based on HTTP headers is very much like using unique resource URL and altering output format based on accept headers, which is the RESTful and recommended approach.
> 
> I can see an argument that diff crops of the same image are not the same resource, but esp. in the context of targeting diff. devices, I think that's not true. If XML and JSON versions of a document are the same resource, then device-specific versions of an image should be as well.
> 
> Good food for thought, however.
> 
> Thanks,
> 
> Irakli 
>