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

On Mon, 17 Nov 2014 20:08:17 +0100, <steve@steveclaflin.com> wrote:

> On 2014-11-11 15:11, Simon Pieters wrote:
>> On Tue, 11 Nov 2014 16:15:46 +0100, <steve@steveclaflin.com> wrote:
>
>>> Benefits would include:
>>>     availability of clearer and more verbose descriptions for the   
>>> individual images,
>>  I don't understand what this means.
>
> I don't consider the current syntax clear, due to it's terseness and  
> lack of names for individual values.

I guess this is a bug with the syntax then, but since it's shipped it's  
too late to change. Also, others have complained that picture/srcset is  
too verbose, so we can't please everyone. I think also introducing an even  
more verbose alternative as you suggest below is not a good idea. It does  
not give any new abilities, it just increases complexity and is more  
syntax for authors to learn.

> It's like the condensed form of background in CSS, which is a lot  
> clearer when it's spelled out with background-image,  
> background-position, etc.  In CSS, at least the more verbose option is  
> available.  As tag attributes, we're trying to cram all the information  
> into a single string without identifying what the values stand for.  So,  
> if that information was somewhere else, outside the img tag, like in a  
> descriptor in the head section, it could be more descriptive.
>
> Even though I see a strong analogy to @font-face, I can't come up with a  
> good parallel syntax for images, because of the necessity for criteria,  
> but something like the following is what I had in mind:
>
> @srcset {
>    name: scene1,
>    {
>      src: url(scene1.png),
>    },
>    {
>      src: url(scene1-med.png),
>      media: min-width: 600px;
>    },
>    {
>      src: url(scene1-lg.png),
>      media: min-width: 960px;
>    }
> }
> (I realize that's kind of an ugly syntax, but there's no good array  
> syntax in CSS.  I don't really like the comma-separated { }, but I can'  
> see any use for giving each candidate image a separate name. Maybe the  
> target query can be like a property name, and its property value the  
> src.  Or maybe the properties could be srcN, where N is an integer - I  
> didn't really like that suggestion for the img tag, but that's because  
> it would mean variable attribute names; here it would just be an  
> ignorable identifier.)
>
> Or, instead of CSS, a tag form like:
>
> <srcset id="scene1">
>      <candidate-image src="scene1.png">
>      <candidate-image src="scene1-med.png" media="min-width: 600px">
>      <candidate-image src="scene1-lg.png" media="min-width: 960px">
> </srcset>

These don't map to srcset, as far as I can tell. srcset doesn't have media  
queries.


> And then in an img tag:
>
> <img srcset="#scene1" src="scene1.png">
>
> So, the more "verbose part" is specific named properties instead of a  
> space-separated list of terms, and the clarity part ought to be obvious.

Personally I don't find this clear at all. :-)

>>
>>>    reusability of descriptors
>>  Is it common to use the same image sets multiple times?
>
> Usually not within the same page, although list or table where each item  
> includes an icon from some limited set of choices, might be an example.

OK. If it's not common, we shouldn't address it by complicating things.

> If I can have a descriptor in a separate place, particularly in CSS,  
> then I can link the same file into multiple pages to get reusability  
> across documents.

This is incompatible with the requirement of being able to start loading  
the right image before external CSS is available.

> And, for temporal reusability, what if I want to do image rollovers?   
> With the current syntax, I would assume that I need to set src AND those  
> big long srcset strings any time I want to swap an image.  Under this  
> approach, I'd still have to swap both src and srcset, but the srcset  
> would just be the identifier.

You could swap out the entire <img>. But depending on what you are doing,  
possibly you shouldn't be using <img> in the first place.


>> 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
>
> I think this is a far cry from namespaces - again, I see it as being  
> closer to fonts.  For me at least, cryptic strings cause a lot more  
> confusion and bugs than a little indirection.

HTML in general avoids this sort of indirection for the reasons given  
above.

-- 
Simon Pieters
Opera Software

Received on Tuesday, 18 November 2014 08:05:25 UTC