[whatwg] The src-N proposal

Anselm Hannemann info at anselm-hannemann.com
Sun Nov 10 02:23:39 PST 2013


On 09.11.2013, at 11:49, Markus Lanthaler <markus.lanthaler at gmx.net> wrote:

> On Saturday, November 09, 2013 12:53 AM, Bruno Racineux wrote:
>> On 11/8/13 10:46 AM, "Rafael Rinaldi" <rafael.rinaldi at gmail.com> wrote:
>> 
>>> It looks complex because it tries to solve something complex. I think
>>> there¹s no way to avoid verbosity to solve such thing.
>> 
>> The only way to avoid verbosity on every <img> element would be to
>> predefine a relationship between the names/keywords of your images and
>> their respective sizes, ONCE in the <head>. The browser can then
>> substitute the img suffix to get the right image, without having to
>> spell-out the full image name every time.
> 
> Well, an alternative would be to move the complexity to the server. I very
> much doubt that webmasters are going to create all those variations manually
> anyway. And if so, it's enough to store them according a naming convention
> the server understands. There are already two proposals how this could work:
> 
>  http://tools.ietf.org/html/draft-grigorik-http-client-hints-00
>  http://tools.ietf.org/html/draft-snell-http-prefer-18
> 
> The browser then just needs to make sure that the right headers are set. We
> would to be very careful though to not destroy the cacheability of
> responses.
> 
> Of course, some form of URL templating would work as well but that probably
> would become quite complex.

While this might be a good solution if you *have* a server, we need to find a solution
that works without the server-requirement. There are tons of use-cases for respimg
where no server can be provided (e.g. a local/offline App-WebView).

Regards,
Anselm




More information about the whatwg mailing list