- From: Anselm Hannemann – Novolo Designagentur <anselm@novolo.de>
- Date: Mon, 6 Feb 2012 23:03:46 +0100
Irakli, I think it is not about markup vs server-side-solution. Server-side is not a solution at all I think. But it's about wether it's markup based (which means we also could serve different content in images on different resolutions which would be a feature!) or file-based as responsive (progressively downloading) image-format in WebP or other formats. But even if WebP gets such a feature it takes time to implement this in format and in browsers which would be quite more complicated as we have the codec-problems again here. So I think we at least need a markup based solution. If we then will get a responsive file format some time it's great but we can't expect that now. --- For the element's name I think either <image> (seems to cause trouble in older browsers but not sure if we have to support them? Mean it should work well and standardized in future not now?) or <picture> would be fine. --- -Anselm > Mathew, > > thanks for raising that point. > > 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. > > 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:03:46 UTC