> 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 >
