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
