- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 30 Sep 2013 23:52:01 -0700
- To: Michael[tm] Smith <mike@w3.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>
On Sep 29, 2013, at 5:08 AM, Michael[tm] Smith wrote: > "Roy T. Fielding" <fielding@gbiv.com>, 2013-09-27 17:44 -0700: > >> Has anyone considered using URI templates [0] for this, so that the >> reference can be described once separately from the ranges? >> >> It could look something like (back of the napkin example) >> >> <img src="sunny-72-100-200-p.jpg" >> template="sunny-{minppi}-{minw}-{minh}-{orientation}.jpg" >> minppi="72 96 163 326" >> minw="30 100 500 1024" >> minh="60 200 1000 2048" >>> > > That looks a lot more author-friendly to me than the other proposals I've > seen so far. > >> Note that this would declare to the user agent the range of images >> available and the effective breakpoints on when to use each one. >> The UA chooses from among the values provided for each dimension, >> usually by picking the highest value less than or equal to the >> image's rendering context (no image is loaded if context is less >> than minw or minh). If no attribute is given defining the range of >> values, then a standard range could be used. >> >> The above example has four dimensions with 4x4x4x2 options, which >> describes 128 distinct URL references. > > That would seem to mean that on the server side an author would need to > provide 128 different images. I would think that not all the possible > combinations for values are likely to be ones that would be used in > practice, so it seems like with this syntax, you'd need to some way to > express some subset(s) of all the possible combinations. Which I guess is > where all of these proposals start to get ugly. For this specific example, there would be 128 different resources, many of which could actually be the same image. In practice, I would expect that an author would either use an automated system for providing those variations (like Photoshop does today), a service to do so automatically, or a much smaller number of variations. Having a large number of potential references is not much of a problem given that each agent will only pick one at a time, and most likely the same one per device platform. Yes, this is ugly for sparse sets. Perhaps we need two mechanisms: one for comprehensive image sets like the above, and another for a short/sparse list of variations. ....Roy
Received on Tuesday, 1 October 2013 06:52:25 UTC