W3C home > Mailing lists > Public > public-respimg@w3.org > November 2014

Re: Informing the browser of the expected size of the image

From: Simon Pieters <simonp@opera.com>
Date: Tue, 11 Nov 2014 22:11:25 +0100
To: steve@steveclaflin.com
Cc: Attiks <attiks@gmail.com>, "Nelson Menezes" <nelson@fittopage.org>, "Greg Whitworth" <gwhit@microsoft.com>, "Yoav Weiss" <yoav@yoav.ws>, Fréd\"éric Kayser\" <f.kayser@free.fr>, public-respimg@w3.org, "Simon Miles-Taylor" <smilestaylor@gmail.com>, "Ilya Grigorik" <igrigorik@google.com>
Message-ID: <op.xo6ihbudidj3kv@simons-macbook-pro.local>
On Tue, 11 Nov 2014 16:15:46 +0100, <steve@steveclaflin.com> wrote:

> Simon,
>
> Thanks for the reference to the issue.  I see that both 85 and 86 apply  
> to this discussion.
>
> My one addition to the overall discussion is that it would be nice to be  
> able to offload the specification of the image source options to a  
> separate area (outside the img or picture tag).  Then that could be  
> referenced in the picture or img tag.
>
> Again, it seems similar to defining a font.  But, I can see arguments  
> for and against using an at-rule - the other alternative would be a set  
> of tags, which of course also has issues.  An at-rule could define a  
> name (like theName), while a tag could have that as an id, and then the  
> srcset attribute would be "#theName" as a reference.

Such indirection has been proposed for media="" (and sizes=""), to be able  
to define breakpoints in a central place and use them both for <img> and  
in CSS.

> Benefits would include:
>
>    availability of clearer and more verbose descriptions for the  
> individual images,

I don't understand what this means.

>    reusability of descriptors

Is it common to use the same image sets multiple times?

I think in general indirection increases cognitive load for Web developers  
and increases complexity and causes bugs for implementors. c.f.  
https://wiki.whatwg.org/wiki/Namespace_confusion

-- 
Simon Pieters
Opera Software
Received on Tuesday, 11 November 2014 21:11:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:15 UTC