- From: Mathew Marquis <mat@matmarquis.com>
- Date: Mon, 6 Feb 2012 17:06:13 -0500
> 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 >
Received on Monday, 6 February 2012 14:06:13 UTC