- 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