W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2012

Re: [whatwg] Problems with width/height descriptors in srcset

From: Odin Hørthe Omdal <odinho@opera.com>
Date: Wed, 16 May 2012 16:52:23 +0200
To: whatwg@lists.whatwg.org
Message-ID: <op.weeoxlhw49xobu@odinho-fido.oslo.osa>
Jeremy Keith <jeremy@adactio.com> wrote:
> If I'm taking a "Mobile First" approach to development, then srcset will  
> meet my needs *if* Nw and Nh refer to min-width and min-height.
> In this example, I'll just use Nw to keep things simple:
> <img src="small.png" srcset="medium.png 600w, large.png 800w">
> (Expected behaviour: use small.png unless the viewport is wider than 600  
> pixels, in which case use medium.png unless the viewport is wider than  
> 800 pixels, in which case use large.png).

Or you can do it "Desktop First" with the same behaviour:

   <img src="large.png" srcset="small.png 0w, medium.png 600w, large.png  

the 0 in srcset would have to override the implict 0 that large got in
src. But that should be easy.

> If, on the other hand, Nw and Nh refer to max-width and max-height, I  
> *have to* take a "Desktop First" approach:
> <img src="large.png" srcset="medium.png 800w, small.png 600w">
> (Expected behaviour: use large.png unless the viewport is narrower than  
> 800 pixels, in which case use narrow.png unless the viewport is narrower  
> than 600 pixels, in which case use small.png).


   <img src="small.png" srcset="medium.png 800w, small.png 600w,
   large.png 92000w">

I really admit that the 92000w looks really ugly. And if you have a
viewport that is wider than 92,000 px it will choose the small.png.

Maybe it should have a Infinite marker for that case. Can't think of a
beautiful solution there.

> One of the advantages of media queries is that, because they support  
> both min- and max- width, they can be used in either use-case: "Mobile  
> First" or "Desktop First".
> Because the srcset syntax will support *either* min- or max- width (but  
> not both), it will therefore favour one case at the expense of the  
> either.

But making them bigger and more verbose will make them that for every
single element you're adding in @srcset. Hardly something to sing about.

   <img src="a.jpg"
     srcset="abc.png max-width:800,
         bcd.png max-width:200 max-height:200,
         bcd@2.png max-width:200 max-height:200 density:2">


   <img src="a.jpg"
     srcset="abc.png 800w,
     	bcd.png 200w 200h,
     	bcd@2.png 200w 200h x2">

The other problem with my straw man proposal is that it kinda looks like
CSS, but it isn't ("max-width: 200" wouldn't work e.g.) so authors would
get that wrong much more often.

And... Okay, my straw man is just horrible. It'd be better if someone
could come up with a real alternate proposal though? I kinda like the
syntax in the spec draft, it's short and sweet. And obvious when you

People will learn it from good documentation probable (heh) or hopefully
quickly understand once they have browsers to test in. It might be hard
learning all this from a spec and scattered emails - that's what spec
people are used to, but not so with webdevs. Dev Opera and MDN would
probably have good texts on it where people actually look stuff up.

> Both use-cases are valid. Personally, I happen to use the "Mobile First"  
> approach, but that doesn't mean that other developers shouldn't be able  
> to take a "Desktop First" approach if they want. By the same logic, I  
> don't much like the idea of srcset forcing me to take a "Desktop First"  
> approach.

I am sympathetic to the idea, but right now I don't know how to.

If we can't find something that's preferable (concise, easy to read etc)
and can do both - I would however prefer that it put most weight on how
the image tag is mostly used on the web today. And allowing sites to
mobile enable their images by adding smaller images to srcset.

Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Wednesday, 16 May 2012 14:53:03 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:42 UTC