- From: Matthew Wilcox <mail@matthewwilcox.com>
- Date: Wed, 16 May 2012 14:04:12 +0100
- To: Odin Hørthe Omdal <odinho@opera.com>
- Cc: Tim Kadlec <tim@timkadlec.com>, "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
If there was a way to do this in JS, we'd have found it. Every time we run up against the pre-fetch problem. In fact, it is only the pre-fetch problem that causes responsive images to be an issue at all. It'd be trivial to fix with JS otherwise. Also, i don't think non-pixel based layouts can be easily dismissed. It's where the whole movement is going and already pixel based MQ are described as limited and not a best practice. -Matt On 16 May 2012 13:42, Odin Hørthe Omdal <odinho@opera.com> wrote: > Tim Kadlec <tim@timkadlec.com> wrote: >> >> The lack of em support is a concern though I understand the complications >> you have brought up. >> >> Using ems for media queries (which in turn dictate layout which in turn >> dictates the image I want to load) is increasingly looking like a much wiser >> decision than using pixels. A perfect example are devices such as the Kindle >> Touch which have a much higher default font size. A real world example, and >> case study, can be found here: >> http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ > > > I don't think it is fit for this round of spec. It is in direct conflict > with preloading/prefetching. It's a different model and requires a > different fix. > > Model 1, before load: do image decision, fetch image while loading the page > Model 2, after load: load page, do image decision after layout > > srcset is using model 1, which is faster and in the same way images are > done today. I don't think you'll be able to convince vendors to ditch > that optimization. > > media queries is doing model 2. I suggest we find a way to do that with > javascript. Maybe some form of deferring image loading at all, saying > that "I will fetch image on my own". Then you can do the delayed image > loading that would need to happen in a media query world. > > Having a fix for model 1, doesn't hinder something for model 2 to come > at a later point. > > >> Now suppose that for that layout displayed in their screenshot, the header >> image was changed to be a vertical oriented phone and the size was reduced. >> In that case, I would want srcset to kick in with a different image. It >> sounds like it would not be able to accomplish this right now? > > > No, you're right about that. Or it could work in the current proposal, > but I don't really think it's worth it. > > The spec does have an algorithm for updating the image that does a new > fetch and show, but it's not required to run it. So you can't really > depend on it. But it can work. If it has already fetched a bigger > image, and has that in cache, it might not want to fetch a smaller one > when you rotate though. Why show something of worse quality than what > you already cache? > > If the intrinsic sizes are different, well, the user agent doesn't > know that until it has downloaded the image anyway. > > > IMHO that should rather be done with a model 2. That means, in the > short term: finding a way to solve it using client side javascript. > > > So in clear text: I don't think that should be supported by imgsrc. > That's a job for a media query. Model 2. > > > >> Forgive me if I'm just missing something. It's early and my coffee hasn't >> kicked in quite yet. :) > > > PS: I would be very happy if you didn't top-post, and also trimmed your > quotes so that it's easy to follow and read (I read email on my phone > when I'm out, and I love when people write emails that work nicely on > the phone). > > > -- > Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Wednesday, 16 May 2012 13:04:44 UTC