Re: [whatwg] Problems with width/height descriptors in srcset
On Wed, 16 May 2012 18:25:58 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, May 16, 2012 at 5:13 AM, Simon Pieters sim...@opera.com wrote: The width/height descriptors in srcset seem to be difficult for people to get right, even people who read the spec. * It's not clear from the syntax that it refers to the viewport size rather than the image size. * It's not clear if it's min-width or max-width. Absolutely agreed. Like several others have suggested, I think we should just go with a min-width:100px approach, which is much clearer. Though that still doesn't make it clear that it refers to the viewport size rather than the image size. Or does it? It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. ~TJ Does doing so solve any use cases? On Wed, 16 May 2012 14:13:59 +0200, Simon Pieters sim...@opera.com wrote: Also, since the fallback image participats as a candidate, but you cannot change its descriptors, you are not free to use any of the images as the fallback image. You might either want the narrowest image to be the fallback, or the widest image, or one in between, but the syntax doesn't allow choice, AFAICT. To solve this problem, I propose that we allow the src URL to be specified in srcset, and when it is, don't add src as a candidate. It would be good with a keyword inf or infinity as a width descriptor in this case so you don't need to specify 1x when you want infinity. -- Simon Pieters Opera Software
Re: [whatwg] Problems with width/height descriptors in srcset
Simon asked: It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. ~TJ Does doing so solve any use cases? Yes, absolutely. I can go through it all again, but basically having both a min-width/height and a max-width/height option gives the developers the choice of either building in a Mobile First or Desktop First way. i.e. either: Use a small image by default in src and list larger and larger images in srcset or: Use a large image by default in src and list smaller and smaller images in srcset. If you want specific examples of responsive sites currently using one or other of these techniques, I'll be able to find them for you. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Problems with width/height descriptors in srcset
On Mon, 21 May 2012 19:09:24 +0200, Jeremy Keith jer...@adactio.com wrote: Simon asked: It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. ~TJ Does doing so solve any use cases? Yes, absolutely. I can go through it all again, but basically having both a min-width/height and a max-width/height option gives the developers the choice of either building in a Mobile First or Desktop First way. i.e. either: Use a small image by default in src and list larger and larger images in srcset or: Use a large image by default in src and list smaller and smaller images in srcset. If you want specific examples of responsive sites currently using one or other of these techniques, I'll be able to find them for you. I agree that that is a use case that should be solved, but I don't see how having both min- and max- solves that. The email you just replied to had a proposal to address that use case, though: On Mon, 21 May 2012 08:28:56 +0200, Simon Pieters sim...@opera.com wrote: Also, since the fallback image participats as a candidate, but you cannot change its descriptors, you are not free to use any of the images as the fallback image. You might either want the narrowest image to be the fallback, or the widest image, or one in between, but the syntax doesn't allow choice, AFAICT. To solve this problem, I propose that we allow the src URL to be specified in srcset, and when it is, don't add src as a candidate. It would be good with a keyword inf or infinity as a width descriptor in this case so you don't need to specify 1x when you want infinity. (This even allows using one of the in between images as the fallback.) -- Simon Pieters Opera Software
Re: [whatwg] Problems with width/height descriptors in srcset
On 17 May 2012 18:59, Jeremy Keith jer...@adactio.com wrote: I much prefer Tab's suggestion: I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width I'd like to add my support for this - by using a subset of media-queries the UA can still choose the best image, whilst ambiguity is decreased (now is 600w a max or min?) and it has the upshot of being easier for developers to pick up, use and debug. Seems better for pretty much everyone!
Re: [whatwg] Problems with width/height descriptors in srcset
Am 17.05.2012 19:48 schrieb Tab Atkins Jr.: On Thu, May 17, 2012 at 10:27 AM, Jeremy Keithjer...@adactio.com wrote: Tab wrote: Absolutely agreed. Like several others have suggested, I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. Just to be clear, do you mean changing the syntax so that Nw is replaced with min-width:N? e.g. img src=small.png srcset=medium.png min-width:600px, large.png min-width: 800px or img src=large.png srcset=medium.png max-width:800px, small.png max-width: 600px Yes, you got it. Those two examples would then be functionally equivalent (give or take a single pixel) but allow developers to take a Mobile First or Desktop First approach according to their preference. Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). No, if we're aping the CSS syntax more closely, we should just use CSS units. h1img src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/h1 pimg src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/p Is em different in these 2 elements, or is it actually rem? And whatever answer, is it a problem or a feature?
Re: [whatwg] Problems with width/height descriptors in srcset
On Fri, May 18, 2012 at 2:17 AM, Markus Ernst derer...@gmx.ch wrote: h1img src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/h1 pimg src=small.png srcset=medium.png min-width:30em, large.png min-width:50em/p Is em different in these 2 elements, or is it actually rem? And whatever answer, is it a problem or a feature? It's the same in those two, but it's not really rem - it's the initial font size, just like in Media Queries. (rem is the size of an em on the root element, which depends on style data.) Not really a feature or a bug, just a necessity. ~TJ
Re: [whatwg] Problems with width/height descriptors in srcset
Odin wrote: 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. Well, right now the spec text says: omitted width descriptors and height descriptors are considered to have the value Infinity Does that mean I could ditch the 92000w and just leave it blank? img src=small.png srcset=small.png 600w, medium.png 800w, large.png Would that result in this behaviour?: Use small.png unless the viewport is less than infinite pixels wide, in which case use large.png, unless the viewport is less than 800 pixels wide, in which case use medium.png, unless the viewport is less than 600 pixels wide, in which case use small.png after all. I still *must* declare small.png twice (once in src and once again in srcset) but at least I don't have to write an arbitrarily large number for Nw). This still favours a Desktop First approach (where no duplication of image URLs is necessary) but at least a Mobile First approach is possible. Tab wrote: Absolutely agreed. Like several others have suggested, I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. Just to be clear, do you mean changing the syntax so that Nw is replaced with min-width:N? e.g. img src=small.png srcset=medium.png min-width:600px, large.png min-width: 800px or img src=large.png srcset=medium.png max-width:800px, small.png max-width: 600px Those two examples would then be functionally equivalent (give or take a single pixel) but allow developers to take a Mobile First or Desktop First approach according to their preference. Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Problems with width/height descriptors in srcset
On Thu, May 17, 2012 at 10:27 AM, Jeremy Keith jer...@adactio.com wrote: Tab wrote: Absolutely agreed. Like several others have suggested, I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. Just to be clear, do you mean changing the syntax so that Nw is replaced with min-width:N? e.g. img src=small.png srcset=medium.png min-width:600px, large.png min-width: 800px or img src=large.png srcset=medium.png max-width:800px, small.png max-width: 600px Yes, you got it. Those two examples would then be functionally equivalent (give or take a single pixel) but allow developers to take a Mobile First or Desktop First approach according to their preference. Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). No, if we're aping the CSS syntax more closely, we should just use CSS units. ~TJ
Re: [whatwg] Problems with width/height descriptors in srcset
I wrote: Well, right now the spec text says: omitted width descriptors and height descriptors are considered to have the value Infinity Does that mean I could ditch the 92000w and just leave it blank? img src=small.png srcset=small.png 600w, medium.png 800w, large.png But I know realise that, according to the spec, I *must* specify at least one value. So actually I'd have to write: img src=small.png srcset=small.png 600w, medium.png 800w, large.png 1x ...which seems to muddy the waters a bit. I actually don't care about the pixel-density of the device in this case, but I need to write 1x because I have to include at least one value. I much prefer Tab's suggestion: I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width I asked: Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). And Tab replied: No, if we're aping the CSS syntax more closely, we should just use CSS units. I agree. Seems like the sensible approach. It also allows authors who are using ems for their media queries in CSS to also use ems for their srcset declarations. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Problems with width/height descriptors in srcset
I also agree with Tab and Jeremy on this one - that makes a lot more sense to me and removes any ambiguity without being overly verbose. I asked: Related question: do we still want to keep this unit-less i.e. ditch the px from the examples above? Or, if we're going to use this CSS-like syntax anyway, allow other units of measurement (e.g. ems). And Tab replied: No, if we're aping the CSS syntax more closely, we should just use CSS units. I agree. Seems like the sensible approach. It also allows authors who are using ems for their media queries in CSS to also use ems for their srcset declarations. Jeremy
Re: [whatwg] Problems with width/height descriptors in srcset
On Thu, 17 May 2012 19:15:36 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: I also agree with Tab and Jeremy on this one - that makes a lot more sense to me and removes any ambiguity without being overly verbose. I like the less-compressed, more CSSy syntax as well. I have two concerns though: Is any media query allowed? If so, then use of min-device-pixel-ratio:2x would give inferior results to using the 2x multiplier, because 2x allows UA to choose when the 2x image is selected (taking into account bandwidth, zoom, user preference, etc.), but min-device-pixel-ratio is supposed to query a fact about the device, not a preference. Should that be discouraged, or maybe even special-cased as an alias of 2x descriptor? How do scaling factors and size queries interact? When only scaling factors are specified then selection is easy, and images could be described in any order: img srcset=imgA 1x, imgB 2x img srcset=imgB 2x, imgA 1x If first one that matches rule was applied to density descriptors, then this would surprisingly fail: img srcset=imgA 1x, imgB 2x because a 2x screen can display 1x image (or the opposite case would fail depending how you define matching of density). As soon as sizes are specified, taking into account order of the rules becomes unavoidable: img srcset=imgA min-height:100px, imgB min-width:100px on a screen that is larger than 100x100 both would match, so there needs to be some definition which one wins, e.g. the first one that matches. img srcset=imgA 1x min-height:100px, imgB 2x min-width:100px but can UA choose the second image in this case when it prefers 2x density? i.e. is the rule going to be first which matches at any density or first which matches at desired density, and failing that the first which matches at any other density? -- regards, Kornel Lesiński
Re: [whatwg] Problems with width/height descriptors in srcset
On Thu, May 17, 2012 at 11:42 AM, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 19:15:36 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: I also agree with Tab and Jeremy on this one - that makes a lot more sense to me and removes any ambiguity without being overly verbose. I like the less-compressed, more CSSy syntax as well. I have two concerns though: Is any media query allowed? If so, then use of min-device-pixel-ratio:2x would give inferior results to using the 2x multiplier, because 2x allows UA to choose when the 2x image is selected (taking into account bandwidth, zoom, user preference, etc.), but min-device-pixel-ratio is supposed to query a fact about the device, not a preference. Should that be discouraged, or maybe even special-cased as an alias of 2x descriptor? These aren't *really* media queries, they just act a whole lot like them. (They can be ignored if needed.) So no, we should just have a specific set of things that are allowed. How do scaling factors and size queries interact? When only scaling factors are specified then selection is easy, and images could be described in any order: img srcset=imgA 1x, imgB 2x img srcset=imgB 2x, imgA 1x If first one that matches rule was applied to density descriptors, then this would surprisingly fail: img srcset=imgA 1x, imgB 2x because a 2x screen can display 1x image (or the opposite case would fail depending how you define matching of density). The spec makes this clear - after filtering the list based on width/height descriptors, the UA can choose whatever density it wants, based on whatever algorithm it wants. Ordering makes no difference. (Ordering makes no difference in width/height either, for that matter.) As soon as sizes are specified, taking into account order of the rules becomes unavoidable: img srcset=imgA min-height:100px, imgB min-width:100px on a screen that is larger than 100x100 both would match, so there needs to be some definition which one wins, e.g. the first one that matches. The spec has such a definition. I can't recall what it is off the top of my head. ~TJ
Re: [whatwg] Problems with width/height descriptors in srcset
Simon wrote: The width/height descriptors in srcset seem to be difficult for people to get right, even people who read the spec. * It's not clear from the syntax that it refers to the viewport size rather than the image size. Yes, I made this mistake and so did plenty of others. As Matt Wilcox pointed out, we're used to seeing attributes describe the element they are attached to: not as tests for the viewport/device. * It's not clear if it's min-width or max-width. Yes, right now the spec contradicts itself about this. This will get resolved I'm sure, but I want to discuss what use cases the srcset draft will work for. 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). 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). 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. 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. Jeremy P.S. I'm using air-quotes around Mobile First and Desktop First because it's not really about mobile or desktop; it's about small viewports and large viewports but the terms are fairly common. -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Problems with width/height descriptors in srcset
On May 16, 2012, at 6:45 AM, Jeremy Keith wrote: Simon wrote: The width/height descriptors in srcset seem to be difficult for people to get right, even people who read the spec. * It's not clear from the syntax that it refers to the viewport size rather than the image size. Yes, I made this mistake and so did plenty of others. As Matt Wilcox pointed out, we're used to seeing attributes describe the element they are attached to: not as tests for the viewport/device. * It's not clear if it's min-width or max-width. Yes, right now the spec contradicts itself about this. This will get resolved I'm sure, but I want to discuss what use cases the srcset draft will work for. 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). 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). 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. 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. Exactly! This is one of the things I was trying to explore yesterday with the use cases around art direction and the incoherent ramblings about difficulties matching breakpoints. Thanks for documenting it in a much clearer fashion. -Jason
Re: [whatwg] Problems with width/height descriptors in srcset
Jeremy Keith jer...@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 800w 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). Likewise: 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, b...@2.png max-width:200 max-height:200 density:2 vs img src=a.jpg srcset=abc.png 800w, bcd.png 200w 200h, b...@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 know. 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
Re: [whatwg] Problems with width/height descriptors in srcset
I kinda like the syntax in the spec draft, it's short and sweet. And obvious when you know. Everything is obvious when you know. The challenge is making it obvious when you don't. Which is why using familiar patters is good. Which is why picture had a strong advantage in that regard. People will learn it from good documentation probable (heh) or hopefully quickly understand once they have browsers to test in. I would count on the majority getting this wrong time and again because the pattern is not a familiar one. And, as we all know, people don't read docs - isn't that the argument so often brought up against any advanced stuff in CSS and HTML? - Users Are Stupid? ;)
Re: [whatwg] Problems with width/height descriptors in srcset
Even i took the draft wrong and I would count me as advanced dev. How in world should a normal dev do this correct? Anselm Am 16.05.2012 um 17:05 schrieb Matthew Wilcox m...@matthewwilcox.com: I kinda like the syntax in the spec draft, it's short and sweet. And obvious when you know. Everything is obvious when you know. The challenge is making it obvious when you don't. Which is why using familiar patters is good. Which is why picture had a strong advantage in that regard. People will learn it from good documentation probable (heh) or hopefully quickly understand once they have browsers to test in. I would count on the majority getting this wrong time and again because the pattern is not a familiar one. And, as we all know, people don't read docs - isn't that the argument so often brought up against any advanced stuff in CSS and HTML? - Users Are Stupid? ;)
Re: [whatwg] Problems with width/height descriptors in srcset
On Wed, May 16, 2012 at 5:13 AM, Simon Pieters sim...@opera.com wrote: The width/height descriptors in srcset seem to be difficult for people to get right, even people who read the spec. * It's not clear from the syntax that it refers to the viewport size rather than the image size. * It's not clear if it's min-width or max-width. Absolutely agreed. Like several others have suggested, I think we should just go with a min-width:100px approach, which is much clearer. It also lets us add max-width, though that may complicate the resource choosing algorithm a bit. ~TJ
