W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] The src-N proposal

From: Anselm Hannemann <info@anselm-hannemann.com>
Date: Sun, 10 Nov 2013 11:23:39 +0100
Message-Id: <84D7F79A-FB57-4D5B-8CEB-49F96257B42B@anselm-hannemann.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Cc: Yoav Weiss <yoav@yoav.ws>, Bruno Racineux <bruno@hexanet.net>, Ian Hickson <ian@hixie.ch>, WHATWG <whatwg@whatwg.org>
On 09.11.2013, at 11:49, Markus Lanthaler <markus.lanthaler@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@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).

Received on Sunday, 10 November 2013 10:24:06 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:13 UTC