Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: What solution do you have in mind that would let you add a 'tv' breakpoint site-wide for all images that have been prepared for it, without need to update code that embeds those images? And is that really saving much effort? Wouldn't you have to revisit every page anyway to test the new layout? That following link does it: [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ Sorry, you're right. I glanced over URI template and assumed it was for media=(case: breakpoint1) in source. -- regards, Kornel Lesiński
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 17 May 2012 11:05, Kornel Lesiński kor...@geekhood.net wrote: On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: What solution do you have in mind that would let you add a 'tv' breakpoint site-wide for all images that have been prepared for it, without need to update code that embeds those images? And is that really saving much effort? Wouldn't you have to revisit every page anyway to test the new layout? That following link does it: [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ Sorry, you're right. I glanced over URI template and assumed it was for media=(case: breakpoint1) in source. -- regards, Kornel Lesiński That particular solution is, to my mind, the most flexible and useful implementation I've seen, because it's really about breakpoint management and abstraction - which is what all responsive elements need in order to work together well and be future-friendly. It does, no doubt, have some technical considerations and implications I'm not aware of. I would love to see this worked on more, I don't think there's much more I can add to it from my authors perspective, it needs work from an implementor perspective. But as a pattern, it has a lot of plus points going for it.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Thu, 17 May 2012 14:16:24 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: That particular solution is, to my mind, the most flexible and useful implementation I've seen, because it's really about breakpoint management and abstraction - which is what all responsive elements need in order to work together well and be future-friendly. It does, no doubt, have some technical considerations and implications I'm not aware of. I would love to see this worked on more, I don't think there's much more I can add to it from my authors perspective, it needs work from an implementor perspective. But as a pattern, it has a lot of plus points going for it. I'm trying to figure out how it's going to work in other situations than the happy case. What if you want to provide copypasteable code snippet with an adaptive image? (like W3C Validator badges) What if you're creating WYSIWYG editor for CMSes and want to have button for inserting adaptive images, but have no access to head? What if you want to insert a single image with custom/unique breakpoints (say an infographic prepared by an agency which used different breakpoints) on a website that already has its own breakpoints defined? I see no nice solution for case when authors put meta breakpoint in body — it'd either have re-evaluate and potentially reload images (wasted requests) or ignore the meta (annoying gotcha when HTML5 parser unexpectedly closes head or when people want to work around lack of access to the head) How do you work with URLs you have no control over? e.g. you'd have to name your breakpoints 40 and 80 to have adaptive size of gravatar.com URLs. What do you do when you have only two breakpoints for sidebar, but more for the main content? (mostly fixed-width sidebar with fluid main column) or if your page header adapts to portrait orientation, but images in main content only adapt to width? -- regards, Kornel Lesiński
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
That particular solution is, to my mind, the most flexible and useful implementation I've seen, because it's really about breakpoint management and abstraction - which is what all responsive elements need in order to work together well and be future-friendly. It does, no doubt, have some technical considerations and implications I'm not aware of. I would love to see this worked on more, I don't think there's much more I can add to it from my authors perspective, it needs work from an implementor perspective. But as a pattern, it has a lot of plus points going for it. I'm trying to figure out how it's going to work in other situations than the happy case. That's cool, it needs that level of how do I break it thinking. I'd also point out I'm not claiming this is a replacement for srcset or picture. I think it's a useful additional tool for web developers, but it is aimed at *site wide* generalised uses to make life a lot easier - I can't see a way to make it also cater to specific individual instances without fundamentally breaking the benefits of the generalisation. What if you want to provide copypasteable code snippet with an adaptive image? (like W3C Validator badges) That would not be a case this method could support fully. Srcset and picture would offer full support for this use case. That said, I'm not sure of the use case of pasting an adaptive image into another domain; we're usually adapting the image to a design on a given domain; any such image is unlikely to work properly in another context anyway (because that other context has it's own measures at that or other breakpoints). What if you're creating WYSIWYG editor for CMSes and want to have button for inserting adaptive images, but have no access to head? This is not a valid use case (to my mind). You'd not be choosing response points for individual pictures, it is the design that has response points and it's the CSS (and JS/HTML) which fit into the design's breakpoints. All a CMS does is cater to the upload a source image, create and/or associate other images for the breakpoints. What if you want to insert a single image with custom/unique breakpoints (say an infographic prepared by an agency which used different breakpoints) on a website that already has its own breakpoints defined? This is where picture and srcset are useful. However as I say: in general breakpoints are a property of a design, they are not a property of the content directly. You do present a valid case for when a breakpoint may actually be based on the content rather than the design: infographics are more sensitive to this than the general image use case (which I believe are photographs or other graphic illustration). I see no nice solution for case when authors put meta breakpoint in body — it'd either have re-evaluate and potentially reload images (wasted requests) or ignore the meta (annoying gotcha when HTML5 parser unexpectedly closes head or when people want to work around lack of access to the head) This solution does not allow for meta in the body, and nor does the HTML5 spec unless I'm mistaken? How do you work with URLs you have no control over? e.g. you'd have to name your breakpoints 40 and 80 to have adaptive size of gravatar.com URLs. I'm not sure I understand this point. However you cook it, you have no access to those images so you can't do anything with them regardless of the method of adaption, be it this method, srcset, or picture. What do you do when you have only two breakpoints for sidebar, but more for the main content? (mostly fixed-width sidebar with fluid main column) or if your page header adapts to portrait orientation, but images in main content only adapt to width? Breakpoints are not something that apply to individual components, they apply to the page as a whole? -- regards, Kornel Lesiński
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Thu, 17 May 2012 15:13:58 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: I'd also point out I'm not claiming this is a replacement for srcset or picture. I think it's a useful additional tool for web developers, but it is aimed at *site wide* generalised uses to make life a lot easier - I can't see a way to make it also cater to specific individual instances without fundamentally breaking the benefits of the generalisation. I see. So we could proceed with the spec without it, and add it later. What if you're creating WYSIWYG editor for CMSes and want to have button for inserting adaptive images, but have no access to head? This is not a valid use case (to my mind). You'd not be choosing response points for individual pictures, it is the design that has response points and it's the CSS (and JS/HTML) which fit into the design's breakpoints. OK. I see no nice solution for case when authors put meta breakpoint in body — it'd either have re-evaluate and potentially reload images (wasted requests) or ignore the meta (annoying gotcha when HTML5 parser unexpectedly closes head or when people want to work around lack of access to the head) This solution does not allow for meta in the body, and nor does the HTML5 spec unless I'm mistaken? What spec allows and what happens on the web are separate things :) HTML needs to define all error cases and be prepared for markup to be abused (lots of such cases had to be defined already). How do you work with URLs you have no control over? e.g. you'd have to name your breakpoints 40 and 80 to have adaptive size of gravatar.com URLs. I'm not sure I understand this point. However you cook it, you have no access to those images so you can't do anything with them regardless of the method of adaption, be it this method, srcset, or picture. Yes, you can. gravatar.com allows you to specify desired size: gravarar.com/avatar/hash?s=40 # gives 40x40px image gravarar.com/avatar/hash?s=80 # gives 80x80px image What do you do when you have only two breakpoints for sidebar, but more for the main content? (mostly fixed-width sidebar with fluid main column) or if your page header adapts to portrait orientation, but images in main content only adapt to width? Breakpoints are not something that apply to individual components, they apply to the page as a whole? In my designs I use it mainly for components. I don't think of pages as separate phone/tablet/desktop designs, but as fluid designs which fold and unfold component by component. Let's say my fancy header logo is quite tall, and that doesn't look well in landscape orientation, so I want to use short/wide version of the design in landscape orientation. And I have a square illustration in my content. It doesn't flip on orientation, but I want it to be 500x500px on 1000px+ screens, and 320x320px on smaller ones. In some srcset-source pseudocode I'd say: header img src=logo-tall srcset=logo-short (orientation:landscape) /header acticle img src=illustration-big srcset=illustration-small (max-width:1000px) /article How would you do that with breakpoints? -- regards, Kornel Lesiński
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 16/05/2012 00:23, Kornel Lesiński wrote: On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com wrote: The fetish for brevity is something I never understood. More understandable code is faster to write than cryptic short code. There is significant difference in verbosity for a *very common case* of serving images for high-dpi (Retina) display (which I suspect is only going to get more common): img src=lowdpi srcset=hidpi 2x vs picture source media=(min-device-pixel-ratio: 2) src=hidpi img src=lowdpi /picture It will get tiring when it'll have to be used for every image on the page. Authors couldn't be bothered to type extra markup for all vendor's prefixes in CSS. Nobody bothered with verbose SVG gradient syntax which was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters. Now there is a massive list of assumptions. People were happy for YEARS to do a: object width=420 height=315param name=movie value=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0;/paramparam name=allowFullScreen value=true/paramparam name=allowscriptaccess value=always/paramembed src=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0; type=application/x-shockwave-flash width=420 height=315 allowscriptaccess=always allowfullscreen=true/embed/object For a video. You know why? Because it worked! SVG didn't work inside HTML for a long time that's why these gradients didn't work - not because it was too long. HTML5 Doctype may be loved but people even forget using that one (case in point - codecademy HTML classes totally forget about it - WHEN teaching new people how to write code for the web). Tooling works around these issues, not making a language shorter. You learn that when you teach people to start using the web. Let's not get too excited about what the people writing specs use and like but see what makes a platform that is understandable and works.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Am i right in believing that the srcset attribute are limited to pixels? A unit that's dying out in all responsive designs? Is it extensible to em, % etc? Because that's what's used. On 16 May 2012 08:39, Chris Heilmann code...@gmail.com wrote: On 16/05/2012 00:23, Kornel Lesiński wrote: On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com wrote: The fetish for brevity is something I never understood. More understandable code is faster to write than cryptic short code. There is significant difference in verbosity for a *very common case* of serving images for high-dpi (Retina) display (which I suspect is only going to get more common): img src=lowdpi srcset=hidpi 2x vs picture source media=(min-device-pixel-ratio: 2) src=hidpi img src=lowdpi /picture It will get tiring when it'll have to be used for every image on the page. Authors couldn't be bothered to type extra markup for all vendor's prefixes in CSS. Nobody bothered with verbose SVG gradient syntax which was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters. Now there is a massive list of assumptions. People were happy for YEARS to do a: object width=420 height=315param name=movie value=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0;/paramparam name=allowFullScreen value=true/paramparam name=allowscriptaccess value=always/paramembed src=http://www.youtube.com/v/oHg5SJYRHA0?version=3amp;hl=en_USamp;rel=0; type=application/x-shockwave-flash width=420 height=315 allowscriptaccess=always allowfullscreen=true/embed/object For a video. You know why? Because it worked! SVG didn't work inside HTML for a long time that's why these gradients didn't work - not because it was too long. HTML5 Doctype may be loved but people even forget using that one (case in point - codecademy HTML classes totally forget about it - WHEN teaching new people how to write code for the web). Tooling works around these issues, not making a language shorter. You learn that when you teach people to start using the web. Let's not get too excited about what the people writing specs use and like but see what makes a platform that is understandable and works.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, 16 May 2012 10:33:05 +0200, Matthew Wilcox m...@matthewwilcox.com wrote: Am i right in believing that the srcset attribute are limited to pixels? A unit that's dying out in all responsive designs? Is it extensible to em, % etc? Because that's what's used. I'm afraid you are confusing a lot of stuff together here. You can use em and % freely in your stylesheets/CSS. The values from srcset is used to fetch the right resource during early prefetch, checked against the width and height of the viewport (and only that viewport). Having ems or % would make no sense whatsoever there, because you don't know what they mean. 50% of what? The viewport size? You would basically make it always matching. Because 50% will always be half of whatever your viewport size is... Say you writeimg srcset=mycoolpic.jpg 50%w, myotherpic.jpg 75%w If viewport is 50px wide, mycoolpic will match 25px, myotherpic will match 37.5px, so it'll pick myotherpic.jpg If viewport is 200px wide, mycoolpic will match 100px, myotherpic will match 150px, so it'll pick myotherpic.jpg If viewport is 500px wide, mycoolpic will match 250px, myotherpic will match 375px, so it'll pick myotherpic.jpg If viewport is 1000px wide, mycoolpic will match 500px, myotherpic will match 750px, so it'll pick myotherpic.jpg See the pattern? It'll always pick the one closest to 100%, no matter what. It doesn't make sense. Also note: the width of an image, and the value you write in srcset, doesn't need to have any connection at all. It's only used to match against the viewport to choose what picture the user agent will fetch. This example will make your logo a smaller mobile version when your viewport width is 600 or smaller (you should also have some media queries in your stylesheet that change the layout at that stage): img src=fallback... srcset=logo-150px.jpg, logo-50px.jpg 600w Here, the logo-50px.jpg will only be loaded if your viewport width is less than 600. It'll choose logo-150px.jpg for everything else. CSS (and the domain media queries work in), and resource fetching that works with prefetching/-loading is two totally seperate things/problems. If you make a solution that will support em/% in a meaningful way, you would have to wait for layout in order to know what size that means. So you will have slower-loading images, and ignore the we want pictures fast requirement. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
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/ 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? Forgive me if I'm just missing something. It's early and my coffee hasn't kicked in quite yet. :) -Tim On May 16, 2012, at 4:07 AM, Odin Hørthe Omdal odi...@opera.com wrote: On Wed, 16 May 2012 10:33:05 +0200, Matthew Wilcox m...@matthewwilcox.com wrote: Am i right in believing that the srcset attribute are limited to pixels? A unit that's dying out in all responsive designs? Is it extensible to em, % etc? Because that's what's used. I'm afraid you are confusing a lot of stuff together here. You can use em and % freely in your stylesheets/CSS. The values from srcset is used to fetch the right resource during early prefetch, checked against the width and height of the viewport (and only that viewport). Having ems or % would make no sense whatsoever there, because you don't know what they mean. 50% of what? The viewport size? You would basically make it always matching. Because 50% will always be half of whatever your viewport size is... Say you writeimg srcset=mycoolpic.jpg 50%w, myotherpic.jpg 75%w If viewport is 50px wide, mycoolpic will match 25px, myotherpic will match 37.5px, so it'll pick myotherpic.jpg If viewport is 200px wide, mycoolpic will match 100px, myotherpic will match 150px, so it'll pick myotherpic.jpg If viewport is 500px wide, mycoolpic will match 250px, myotherpic will match 375px, so it'll pick myotherpic.jpg If viewport is 1000px wide, mycoolpic will match 500px, myotherpic will match 750px, so it'll pick myotherpic.jpg See the pattern? It'll always pick the one closest to 100%, no matter what. It doesn't make sense. Also note: the width of an image, and the value you write in srcset, doesn't need to have any connection at all. It's only used to match against the viewport to choose what picture the user agent will fetch. This example will make your logo a smaller mobile version when your viewport width is 600 or smaller (you should also have some media queries in your stylesheet that change the layout at that stage): img src=fallback... srcset=logo-150px.jpg, logo-50px.jpg 600w Here, the logo-50px.jpg will only be loaded if your viewport width is less than 600. It'll choose logo-150px.jpg for everything else. CSS (and the domain media queries work in), and resource fetching that works with prefetching/-loading is two totally seperate things/problems. If you make a solution that will support em/% in a meaningful way, you would have to wait for layout in order to know what size that means. So you will have slower-loading images, and ignore the we want pictures fast requirement. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Tim Kadlec t...@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
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Oh, please do quote what you are answering. It's very hard to follow such a conversation like this. Matthew Wilcox m...@matthewwilcox.com wrote: 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. I could be more clear. I believe this is what you are talking about: I said: 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. When I say find a way to defer it, I mean spec a way to do it, and implement that. Something like: img defer src=blabla.jpg I understand the problem :-) 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. ... But it doesn't work. Please read my emails, and come with constructive technical feedback on why you think it *can* in fact work. I can not see a method where that would work in an non-broken way. Technical problems won't just magically go away by not acknowlegding them. And I did find a way forward for the model 2, make a way to defer the image load and find a way to load it. Maybe picture element should always defer? It actually *has to* because it uses media queries, so in fact, picture might be a solution for model 2 in the future. But @srcset is solving the other part of the equation (model 1). -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 16 May 2012 14:30, Odin Hørthe Omdal odi...@opera.com wrote: Oh, please do quote what you are answering. It's very hard to follow such a conversation like this. OK, I am not sure what format to reply to emails with - some people complain when quotes are left out entirely, other people complain when replies are in-line in the style you request, other people complain unless the whole thread is included verbatim in any reply. What's the actual WHATWG proscribed format for conducting conversations in email format? Matthew Wilcox m...@matthewwilcox.com wrote: 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. I could be more clear. I believe this is what you are talking about: I said: 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. When I say find a way to defer it, I mean spec a way to do it, and implement that. Something like: img defer src=blabla.jpg I understand the problem :-) Cool - so you're saying we have the option of being able to instruct browsers *not* to perform prefetch in certain circumstances? 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. ... But it doesn't work. Please read my emails, and come with constructive technical feedback on why you think it *can* in fact work. I can not see a method where that would work in an non-broken way. Technical problems won't just magically go away by not acknowlegding them. I am unable to give technical feedback of the required level; I'm here as an author to tell you this is how we build stuff and this is how we'd want to use images - just like we do with CSS. Just as technical problems won't go away, neither will authors use cases and requirements :) And, unfortunately, I am not skilled enough with the technical side to be able to give you answers to the problem. I'm just stating that the problem is not one that can be ignored lightly because it would mean that the proposed solution does not work with how websites are being built today. And I did find a way forward for the model 2, make a way to defer the image load and find a way to load it. Maybe picture element should always defer? It actually *has to* because it uses media queries, so in fact, picture might be a solution for model 2 in the future. But @srcset is solving the other part of the equation (model 1). -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com I'm not entirely convinced about this abstraction of model 1 and model 2. picture is flawed anyway, and srcset in the same manner, by baking the response tests into the mark-up. When it comes time to re-design there will be new breakpoints and they are not likely to match the one's in the img / picture tags. It's the major hold-up I had with picture and why I suggested looking into abstracting breakpoint conditions away from the responding element and into the head.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox m...@matthewwilcox.com wrote: What's the actual WHATWG proscribed format for conducting conversations in email format? See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F -- Mike Taylor Opera Software
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Cheers :) On 16 May 2012 15:05, Mike Taylor mi...@opera.com wrote: On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox m...@matthewwilcox.com wrote: What's the actual WHATWG proscribed format for conducting conversations in email format? See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F -- Mike Taylor Opera Software
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, 16 May 2012 03:50:21 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, May 16, 2012 at 9:20 AM, Odin Hørthe Omdal odi...@opera.com wrote: I'm not sure. What do you think? As far as I've seen, you're highly knowledgeable about video. Why do we have mediaqueries on video element? Do we have a use case page? Hehe, thanks. :-) But media queries were in video before I arrived, so I missed the whole discussion around it and how it got there. Some of the browsers that implement support for it should speak up. We have supported the media attribute since the first stable release with video (Opera 10.50) and Git blames me. However, I must say that I just added it because it was in the spec and don't remember any discussion about it. Some digging shows that it was added to the spec in http://html5.org/r/724, but I don't know why. As far as I can tell, it's mostly useless and I've never heard of it actually being used. The correct way to handle different screen sizes and bandwidth constraints is adaptive streaming. Simon Pieters has suggested simply dropping the attribute and I would not object to that. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, May 16, 2012 at 5:42 AM, Odin Hørthe Omdal odi...@opera.com wrote: Tim Kadlec t...@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. Not really. Media Queries allows 'em' to be used; it's just relative to the initial font size (which is specified by the browser, not CSS), rather than the font-size of any particular element. Since the w/h components of @srcset are basically MQs, it should work similarly. ~TJ
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, 16 May 2012 20:09:13 +0100, D. Pitchford dpitchfo...@gmail.com wrote: What standards does not do in this situation is remove the actual work effort in having to physically update each and every img's 'srcset' string with new breakpoints during a redesign, no matter how terse the 'srcset' string is. You can have all the stanadrds in place you can muster to write, but the physical work effort is not negated because of a list of guidelines that lives in a document that rarely gets followed. Another situation could involve adding an additional layer of support for Televisions, in the middle of the lifecycle of a website. srcset does not allow for a global update to all img's in a templated fashion. The work effort would need be physically updating each and every srcset across the site individually. Not exactly the most efficient use of anyone's time. (picture also has this as a downfall) This is a much larger issue than people are willing to admit at this point. The solution I've seen proposed[1] only aliases media query content, and works only on a per-page basis, so it doesn't allow automatic addition of a new image size site-wide, since you have to insert new source into every picture anyway. To me it looks like about the same amount of work as inserting new pixel size into every srcset. What solution do you have in mind that would let you add a 'tv' breakpoint site-wide for all images that have been prepared for it, without need to update code that embeds those images? And is that really saving much effort? Wouldn't you have to revisit every page anyway to test the new layout? [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ -- regards, Kornel Lesiński
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
The solution I've seen proposed[1] only aliases media query content, and works only on a per-page basis, so it doesn't allow automatic addition of a new image size site-wide, since you have to insert new source into every picture anyway. That is not true. With that particular solution you would never alter any mark-up inside the body, you would only ever need to alter the meta variables in the head - which more often than not are in a single server-side template for a website. That solution makes it trivial to adjust, add, or subtract the breakpoints of a design, and therefor images, site-wide under normal website conditions (i.e., you're using a CMS to output the website). To me it looks like about the same amount of work as inserting new pixel size into every srcset. Completely not the case. What solution do you have in mind that would let you add a 'tv' breakpoint site-wide for all images that have been prepared for it, without need to update code that embeds those images? And is that really saving much effort? Wouldn't you have to revisit every page anyway to test the new layout? That following link does it: [1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ -- regards, Kornel Lesiński
[whatwg] So if media-queries aren't for determining the media to be used what are they for?
Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... img src=face-600-200 at 1.jpeg alt= srcset=face-600-200 at 1.jpeg 600w 200h 1x, face-600-200 at 2.jpeg 600w 200h 2x, face-icon.png 200w 200h We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... I'd like to see media-queries extended to support bandwidth, svg etc., then we give developers the option to detected features and choose media types appropriately. Andy
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@gmail.com wrote: Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... img src=face-600-200 at 1.jpeg alt= srcset=face-600-200 at 1.jpeg 600w 200h 1x, face-600-200 at 2.jpeg 600w 200h 2x, face-icon.png 200w 200h We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... I'd like to see media-queries extended to support bandwidth, svg etc., then we give developers the option to detected features and choose media types appropriately. The 600w 200h bit can be directly translated into a media query - it's equivalent to (max-width: 600px) and (max-height: 200px). It's collapsed into a custom syntax for terseness. Are there good cases to use other types of media queries? I never got to join the CG, so I'm sure I missed out on lots of use-cases that were presented. ~TJ
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@gmail.com wrote: Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... img src=face-600-200 at 1.jpeg alt= srcset=face-600-200 at 1.jpeg 600w 200h 1x, face-600-200 at 2.jpeg 600w 200h 2x, face-icon.png 200w 200h We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... I'd like to see media-queries extended to support bandwidth, svg etc., then we give developers the option to detected features and choose media types appropriately. The 600w 200h bit can be directly translated into a media query - it's equivalent to (max-width: 600px) and (max-height: 200px). It's collapsed into a custom syntax for terseness. Just so I understand 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) 2) The new bit is the descriptors of pixel density (1x 2x etc). This isn't media queried because the precise mechanism by which one image is chosen over the other is left to the UA to decide based upon heuristics. Those heuristics may be secret sauces that give a browser a competitive advantage over another; they may be based on data the browser has accumulated over time (On my current Bruce's bedroom WiFi I know I have medium network speed but very low latency so I will tend to favour images with characteristic X) and so which aren't available to query with MQs because MQs are stateless; they may be based upon certain characteristics that could conceivably be available to MQs in the future (Do I support JS? Am I touch enabled?) but aren't yet. Is that accurate? I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. bruce-speaking-for-myself-not-Opera
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, May 15, 2012 at 2:46 PM, Bruce Lawson bru...@opera.com wrote: 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) [snip] I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. I think I more or less agree with you. However, when you look at MQ, literally the only things you want to decide on are width/height, and *maybe* grayscale/color. You really don't need to be generic here, so you might as well optimize the syntax to make it easier to type. I think this is too much, personally. I'd prefer more verbosity here, like: img src=foo.jpg srcset=foo-big.jpg min-width:1000px, foo-...@2.jpg min-width:1000px 2x Importantly, I think I'd like to be able to use either min or max, but @srcset's microsyntax only talks about min sizes. (I got it wrong in my previous email.) ~TJ
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, May 15, 2012 at 11:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Importantly, I think I'd like to be able to use either min or max, but @srcset's microsyntax only talks about min sizes. (I got it wrong in my previous email.) Well, it's not a media query. It *describes* the size of the image. A media query *evaluates* device capabilities. They are completely different and allow for different resource selection algorithms. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, May 15, 2012 at 3:01 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 15, 2012 at 11:56 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Importantly, I think I'd like to be able to use either min or max, but @srcset's microsyntax only talks about min sizes. (I got it wrong in my previous email.) Well, it's not a media query. It *describes* the size of the image. No it doesn't. Saying 600w next to a URL says nothing about the size of the image, just that you claim that the image at that URL is intended for screens at least 600px wide. ~TJ
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 15/05/2012 22:46, Bruce Lawson wrote: On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@gmail.com wrote: Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... img src=face-600-200 at 1.jpeg alt= srcset=face-600-200 at 1.jpeg 600w 200h 1x, face-600-200 at 2.jpeg 600w 200h 2x, face-icon.png 200w 200h We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... I'd like to see media-queries extended to support bandwidth, svg etc., then we give developers the option to detected features and choose media types appropriately. The 600w 200h bit can be directly translated into a media query - it's equivalent to (max-width: 600px) and (max-height: 200px). It's collapsed into a custom syntax for terseness. Just so I understand 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) 2) The new bit is the descriptors of pixel density (1x 2x etc). This isn't media queried because the precise mechanism by which one image is chosen over the other is left to the UA to decide based upon heuristics. Those heuristics may be secret sauces that give a browser a competitive advantage over another; they may be based on data the browser has accumulated over time (On my current Bruce's bedroom WiFi I know I have medium network speed but very low latency so I will tend to favour images with characteristic X) and so which aren't available to query with MQs because MQs are stateless; they may be based upon certain characteristics that could conceivably be available to MQs in the future (Do I support JS? Am I touch enabled?) but aren't yet. Is that accurate? I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. bruce-speaking-for-myself-not-Opera I also wonder what we do with videos? Surely they have the same issues and there is no proposal for changing the syntax there. I do not like the syntax of this. Yes it is more terse but it smacks of the horrible syntax of window.open properties and other comma separated visual attributes. From a semantic point of view this is a terrible mix of everything - something that the picture proposal with multiple sources was not. Let's not forget that this is a new use case - one that might get more complex with more UA changes in the future. Maybe we have holographic images soon with a X Y and Z position. Shoehorning this into the IMG element doesn't make much sense to me. embed is the fallback to video with various sources. img is the fallback to embed. I'd like to see picture - done like video for consistency as it is a new use case for images. Old browsers could disregard them and new ones can use mediaqueries to apply the different sources as needed. Yes, mediaqueries do not all the things we need here and browsers have bugs loading various sources instead of only one but these are things to fix in the browser engines, not add an extra use case in the spec.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Tab, maybe you think this is a good type to write the syntax but the majority of normal web developers are used to use common HTML syntax. This is why we proposed the picture element and normal attributes using media queries. Of course this means we have lot more to write but at least this is intuitive and totally clear as it uses common structure of HTML. Do you agree with this? I think it is more important that everyone understands the syntax and actually will use it instead of having a shorthand code that no one will use...? -Anselm Am 15.05.2012 um 23:56 schrieb Tab Atkins Jr.: On Tue, May 15, 2012 at 2:46 PM, Bruce Lawson bru...@opera.com wrote: 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) [snip] I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. I think I more or less agree with you. However, when you look at MQ, literally the only things you want to decide on are width/height, and *maybe* grayscale/color. You really don't need to be generic here, so you might as well optimize the syntax to make it easier to type. I think this is too much, personally. I'd prefer more verbosity here, like: img src=foo.jpg srcset=foo-big.jpg min-width:1000px, foo-...@2.jpg min-width:1000px 2x Importantly, I think I'd like to be able to use either min or max, but @srcset's microsyntax only talks about min sizes. (I got it wrong in my previous email.) ~TJ
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Am 16.05.2012 um 00:06 schrieb Chris Heilmann: On 15/05/2012 22:46, Bruce Lawson wrote: On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, May 15, 2012 at 1:42 PM, Andy Davies dajdav...@gmail.com wrote: Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... img src=face-600-200 at 1.jpeg alt= srcset=face-600-200 at 1.jpeg 600w 200h 1x, face-600-200 at 2.jpeg 600w 200h 2x, face-icon.png 200w 200h We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... I'd like to see media-queries extended to support bandwidth, svg etc., then we give developers the option to detected features and choose media types appropriately. The 600w 200h bit can be directly translated into a media query - it's equivalent to (max-width: 600px) and (max-height: 200px). It's collapsed into a custom syntax for terseness. Just so I understand 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) 2) The new bit is the descriptors of pixel density (1x 2x etc). This isn't media queried because the precise mechanism by which one image is chosen over the other is left to the UA to decide based upon heuristics. Those heuristics may be secret sauces that give a browser a competitive advantage over another; they may be based on data the browser has accumulated over time (On my current Bruce's bedroom WiFi I know I have medium network speed but very low latency so I will tend to favour images with characteristic X) and so which aren't available to query with MQs because MQs are stateless; they may be based upon certain characteristics that could conceivably be available to MQs in the future (Do I support JS? Am I touch enabled?) but aren't yet. Is that accurate? I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. bruce-speaking-for-myself-not-Opera I also wonder what we do with videos? Surely they have the same issues and there is no proposal for changing the syntax there. I do not like the syntax of this. Yes it is more terse but it smacks of the horrible syntax of window.open properties and other comma separated visual attributes. From a semantic point of view this is a terrible mix of everything - something that the picture proposal with multiple sources was not. This is what I think, too. Let's not forget that this is a new use case - one that might get more complex with more UA changes in the future. Maybe we have holographic images soon with a X Y and Z position. Shoehorning this into the IMG element doesn't make much sense to me. embed is the fallback to video with various sources. img is the fallback to embed. I'd like to see picture - done like video for consistency as it is a new use case for images. Old browsers could disregard them and new ones can use mediaqueries to apply the different sources as needed. Yes, mediaqueries do not all the things we need here and browsers have bugs loading various sources instead of only one but these are things to fix in the browser engines, not add an extra use case in the spec. And that is a reason why picture is (imo) the better option. It is far more flexible to future changes of media. I also don't think we need a now working solution but a solution that work for the next couple of years (maybe 10yrs or more). I also won't say picture is the best way to go but it is far better than the proposal that made it in some draft earlier this day. -A.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 15/05/2012 23:11, Anselm Hannemann Web Development wrote: Tab, maybe you think this is a good type to write the syntax but the majority of normal web developers are used to use common HTML syntax. This is why we proposed the picture element and normal attributes using media queries. Of course this means we have lot more to write but at least this is intuitive and totally clear as it uses common structure of HTML. Do you agree with this? I think it is more important that everyone understands the syntax and actually will use it instead of having a shorthand code that no one will use...? +1 The fetish for brevity is something I never understood. More understandable code is faster to write than cryptic short code.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, May 15, 2012 at 3:06 PM, Chris Heilmann code...@gmail.com wrote: I also wonder what we do with videos? Surely they have the same issues and there is no proposal for changing the syntax there. I do not like the syntax of this. Yes it is more terse but it smacks of the horrible syntax of window.open properties and other comma separated visual attributes. video is a special case, unfortunately. It would be difficult to avoid using source there, but we shouldn't look at it as a good example in general. Using source introduces a lot of problems that would be good to avoid if possible. From a semantic point of view this is a terrible mix of everything - something that the picture proposal with multiple sources was not. There's no semantics in here - this is all presentation and usability. This is just a very compact way to state the information that picture presented more verbosely. img srcset=foo.jpg 600w 2x is no more a terrible mix of everything than picture source src=foo.jpg media=min-width:600px resolution=2 /picture is. Let's not forget that this is a new use case - one that might get more complex with more UA changes in the future. Maybe we have holographic images soon with a X Y and Z position. Shoehorning this into the IMG element doesn't make much sense to me. We should take care not to be future-hostile, but designing for all hypothetical futures just results in muddled, hard-to-use designs. Among current MQs, there are 2/4 (depending on if you count min/max separate) queries you definitely want to use, and one that *might* be useful (and which can be added to the microsyntax cleanly). I'm not aware of proposed future MQs that would be useful to tie into this functionality, either. embed is the fallback to video with various sources. img is the fallback to embed. I'd like to see picture - done like video for consistency as it is a new use case for images. Old browsers could disregard them and new ones can use mediaqueries to apply the different sources as needed. Yes, mediaqueries do not all the things we need here and browsers have bugs loading various sources instead of only one but these are things to fix in the browser engines, not add an extra use case in the spec. See the blog post I wrote today so I'd have to stop giving this same argument over and over again. ^_^ http://www.xanthir.com/blog/b4Hv0. You simply can't make a good decision about which resolution to send to the user based on information from Media Queries. ~TJ
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Andy Davies dajdav...@gmail.com wrote: Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... Ah! What a truly great question, so simple. The answer is: no, it is not media-queries although they look like it. A big problem is that it's so easy to explain it by saying it's just like media-query max-width, rather than finding the words to illustrate that they are totally different. The *limited effect* also feels similar which doesn't help the case at all. So, even though I have a rather bad track record of explaining any thing, I'll try again: Media queries come from the client side. They allow the author of a web page to tell exactly how she want to lay out her design based on the different queries. The browser *HAS* to follow these queries. And also, I don't think (please correct me if wrong) the media query can be subset to only the stuff that's really meaningful to do at prefetch-time. The srcset proposal, on the other hand, are purely HINTS to the browser engine about the resources. They are only declarative hints that can be leveraged in a secret sauce way (like Bruce said in another mail) to always optimize image fetching and other features. If you make a new kind of browser (like e.g. Opera mini) it can have its own heuristics that make sense *for that single browser* without asking _anyone_. Without relying on web authors doing the correct thing, or changing anything or even announce to anyone what they are doing. It's opening up for innovation, good algorithms and smart uses in the future. That's the basic difference, totally different. :-) With mediaqueries, you don't know at the time when you're prefetching an image, what box it is in. So many media queries will either not make sense (so they won't work like authors intend them to), OR the browser would have to wait until it has layout for it to start fetching images. Neither of these two would actually be good, so they are in conflict. I'd also like to give an example on the smart uses in the future for imgsrc; right-click save could fetch the biggest quality image and save that one instead of the one it has currently fetched. Bruce Lawson bru...@opera.com skreiv Tue, 15 May 2012 23:46:44 +0200 Just so I understand 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) No. It only works on device-width also, and it's only a hint, so it's actually part of your part 2: 2) The new bit is the descriptors of pixel density (1x 2x etc). This isn't media queried because the precise mechanism by which one image is chosen over the other is left to the UA to decide based upon heuristics. Those heuristics may be secret sauces that give a browser a competitive advantage over another; they may be based on data the browser has accumulated over time (On my current Bruce's bedroom WiFi I know I have medium network speed but very low latency so I will tend to favour images with characteristic X) and so which aren't available to query with MQs because MQs are stateless; they may be based upon certain characteristics that could conceivably be available to MQs in the future (Do I support JS? Am I touch enabled?) but aren't yet. Is that accurate? Yeah, sounds more like it. But it applies to the whole thing. I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. Exactly. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. It's heavily optimized for the usecase that will happen most often: for retina type displays: img src=odin-in-suit.jpg srcset=odin-in-s...@2.jpg 2x bruce-speaking-for-myself-not-Opera I'm not speaking for Opera either, but we do work for Opera, and it's hard to disclaim everything always. I hope it made sense. -- Odin Hørthe Omdal (odinho/Velmont) · Opera Software
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, May 16, 2012 at 8:37 AM, Odin Hørthe Omdal odi...@opera.com wrote: Andy Davies dajdav...@gmail.com wrote: Looking at the srcset proposal it appears to be recreating aspects of media-queries in a terse less obvious form... We've already got media queries so surelt we should be using them to determine which image should be used and if media-queries don't have features we need then we should be extending them... Ah! What a truly great question, so simple. The answer is: no, it is not media-queries although they look like it. A big problem is that it's so easy to explain it by saying it's just like media-query max-width, rather than finding the words to illustrate that they are totally different. The *limited effect* also feels similar which doesn't help the case at all. So, even though I have a rather bad track record of explaining any thing, I'll try again: Media queries come from the client side. They allow the author of a web page to tell exactly how she want to lay out her design based on the different queries. The browser *HAS* to follow these queries. And also, I don't think (please correct me if wrong) the media query can be subset to only the stuff that's really meaningful to do at prefetch-time. The srcset proposal, on the other hand, are purely HINTS to the browser engine about the resources. They are only declarative hints that can be leveraged in a secret sauce way (like Bruce said in another mail) to always optimize image fetching and other features. If you make a new kind of browser (like e.g. Opera mini) it can have its own heuristics that make sense *for that single browser* without asking _anyone_. Without relying on web authors doing the correct thing, or changing anything or even announce to anyone what they are doing. It's opening up for innovation, good algorithms and smart uses in the future. That's the basic difference, totally different. :-) If that's the case, would it make sense to get rid of the @media attribute on source elements in video and replace it with @srcset? Silvia.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Silvia Pfeiffer silviapfeiff...@gmail.com skreiv Wed, 16 May 2012 00:57:48 +0200 Media queries come from the client side. They allow the author of a web page to tell exactly how she want to lay out her design based on the different queries. The browser *HAS* to follow these queries. And also, I don't think (please correct me if wrong) the media query can be subset to only the stuff that's really meaningful to do at prefetch-time. The srcset proposal, on the other hand, are purely HINTS to the browser engine about the resources. They are only declarative hints that can be leveraged in a secret sauce way (like Bruce said in another mail) to always optimize image fetching and other features. If you make a new kind of browser (like e.g. Opera mini) it can have its own heuristics that make sense *for that single browser* without asking _anyone_. Without relying on web authors doing the correct thing, or changing anything or even announce to anyone what they are doing. It's opening up for innovation, good algorithms and smart uses in the future. That's the basic difference, totally different. If that's the case, would it make sense to get rid of the @media attribute on source elements in video and replace it with @srcset? Video is at least a bit different in that you don't expect it to be fully loaded and prefetch at such an early stage as img. But I've been thinking about that since I read something like we already have media queries in source for video, but it's not really implemented and used yet. I'm not sure. What do you think? As far as I've seen, you're highly knowledgeable about video. Why do we have mediaqueries on video element? Do we have a use case page? Doing the same as whatever img ends up doing might be a good fit if the use cases are similar enough. Would be nice to be consistent if that makes sense. -- Odin Hørthe Omdal · odinho / Velmont · Opera Software
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
Odin wrote: It's heavily optimized for the usecase that will happen most often: for retina type displays: img src=odin-in-suit.jpg srcset=odin-in-s...@2.jpg 2x Okay. This is also what Ted said about the srcset proposal and it makes a lot of sense for that use case. But it seems far less suited to the use-case of art-directed image decisions i.e. allowing the author to specify which image should be displayed (based on some criteria, possibly the viewport size). Jason does a good job of differentiating both use-cases here: http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ 1. How do we enable authors so that they can display different images under different conditions based on art direction? 2. Enabling authors to provide different resolutions of images based on a variety of conditions. The srcset proposal that has been thrown into the spec looks like a good answer for that second use-case but it doesn't attempt to tackle the first use-case. Now ideally we'd find one solution that solves both use-cases but after the discussion here and in IRC I think that's looking increasingly unlikely. So if we can agree that srcset is a good solution for handling retina displays and other secret sauce conditions (like bandwidth, as Tab blogged about), can we move on to trying to find a different solution for the other use case? I *suspect* that the solution for the art-direction use-case could look almost exactly like media queries (because the use-case is so similar to common use-cases for media queries). Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com wrote: The fetish for brevity is something I never understood. More understandable code is faster to write than cryptic short code. There is significant difference in verbosity for a *very common case* of serving images for high-dpi (Retina) display (which I suspect is only going to get more common): img src=lowdpi srcset=hidpi 2x vs picture source media=(min-device-pixel-ratio: 2) src=hidpi img src=lowdpi /picture It will get tiring when it'll have to be used for every image on the page. Authors couldn't be bothered to type extra markup for all vendor's prefixes in CSS. Nobody bothered with verbose SVG gradient syntax which was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters. -- regards, Kornel Lesiński
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, 15 May 2012 23:57:48 +0100, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Media queries come from the client side. They allow the author of a web page to tell exactly how she want to lay out her design based on the different queries. The browser *HAS* to follow these queries. And also, I don't think (please correct me if wrong) the media query can be subset to only the stuff that's really meaningful to do at prefetch-time. The srcset proposal, on the other hand, are purely HINTS to the browser engine about the resources. They are only declarative hints that can be leveraged in a secret sauce way (like Bruce said in another mail) to always optimize image fetching and other features. If you make a new kind of browser (like e.g. Opera mini) it can have its own heuristics that make sense *for that single browser* without asking _anyone_. Without relying on web authors doing the correct thing, or changing anything or even announce to anyone what they are doing. It's opening up for innovation, good algorithms and smart uses in the future. That's the basic difference, totally different. :-) If that's the case, would it make sense to get rid of the @media attribute on source elements in video and replace it with @srcset? I think something like that would be perfect. In fact, I'd keep @media, because it serves some cases very well (I see dpi/bandwidth optimisation as a problem orthogonal to layout adaptation: http://geekhood.net/MediaQuery-vs-PerfQuery.png) It may be enough to add another attribute that describes image properties, and can be used either alone or with conjunction with MQs: picture source scale=1 src=low source scale=2 src=high /picture would be equivalent to: img srcset=low 1x, high 2x (I've proposed that in the RespImg community group) And combination of the two opens new possibilities: picture source scale=1 src=low-narrow media=(orientation:portrait) source scale=2 src=high-narrow media=(orientation:portrait) source scale=1 src=low-wide media=(orientation:landscape) source scale=2 src=high-wide media=(orientation:landscape) /picture -- regards, Kornel Lesiński
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Tue, May 15, 2012 at 4:23 PM, Jeremy Keith jer...@adactio.com wrote: Odin wrote: 1. How do we enable authors so that they can display different images under different conditions based on art direction? 2. Enabling authors to provide different resolutions of images based on a variety of conditions. The srcset proposal that has been thrown into the spec looks like a good answer for that second use-case but it doesn't attempt to tackle the first use-case. Now ideally we'd find one solution that solves both use-cases but after the discussion here and in IRC I think that's looking increasingly unlikely. Hm, I'm confused. The NNNw and NNNh parts of the microsyntax are precisely intending to solve the (1) case. They're more-or-less equivalent to using min-width and min-height Media Queries. Looking through the list of Media Queries, it seems that the only useful ones for art-direction style changes are the width/height ones, and maybe the monochrome or color ones. We can always add the latter to the microsyntax if necessary (their syntax in MQ is pretty weird). I'm not aware of any plans for future MQs that would be very useful here either. ~TJ
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 5/15/12 7:33 PM, Kornel Lesiński wrote: In fact, I'd keep @media, because it serves some cases very well (I see dpi/bandwidth optimisation as a problem orthogonal to layout adaptation: http://geekhood.net/MediaQuery-vs-PerfQuery.png) @media on video source is terrible for layout adaptation: it's only considered when selecting a source. So if you load the page, then turn your device so it's in landscape mode (or resize your browser window or whatever), the source won't change, even though which source matches the medium might have just changed. Is the expectation that device-adapting images will reload from the new URI in cases like the above? Or not? Both answers have some problems. :( -Boris
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On 2012-05-15, at 7:23 PM, Kornel Lesiński wrote: On Tue, 15 May 2012 23:17:54 +0100, Chris Heilmann code...@gmail.com wrote: The fetish for brevity is something I never understood. More understandable code is faster to write than cryptic short code. There is significant difference in verbosity for a *very common case* of serving images for high-dpi (Retina) display (which I suspect is only going to get more common): img src=lowdpi srcset=hidpi 2x vs picture source media=(min-device-pixel-ratio: 2) src=hidpi img src=lowdpi /picture It will get tiring when it'll have to be used for every image on the page. Authors couldn't be bothered to type extra markup for all vendor's prefixes in CSS. Nobody bothered with verbose SVG gradient syntax which was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters. -- regards, Kornel Lesiński This brings up a very good point: multiplying the number of images. I'll go one step further and suggest a hypothetical (which is not really a hypothetical): - Build out either proposals to include more sources so each are maxed out for all breakpoints, resolutions, etc. which have propagated throughout a large website. - The time has come for a redesign, and based on the new design, all breakpoints have changed from 768px to 800px, a 3x resolution has been introduced by 'X Company' and add in X as an additional workflow variable. As an author, am I to assume that I now need to manually update each and every srcset or picture to align with the new design? With either proposal this does not seem like the most efficient way for anyone to spend their time, and is opening a door to a *huge* maintenance issue. I dread the day when I have to dig through, possibly hundreds of pages, with multiple images per, to update the breakpoints and resolutions. Surely there's a better way to manage breakpoints on a global level rather than burying the specifics within the elements or attributes themselves. See the thread here: http://www.w3.org/community/respimg/2012/04/26/syntax-issue-with-displaying-high-resolution-images-in-the-picture-element-how-a-mole-hill-could-turn-into-a-mountain/ See example here from Brett Jankord: https://gist.github.com/2509534 I would hope than any solution to responsive images takes maintenance a little more serious than it has up to this point, as it seems more of an afterthought than anything. Both proposals at this point regardless of semantics, syntax, verbosity or terseness will do no one any favours, and will have huge ramifications in areas nobody is talking about. Copy/Paste from the example gist above, which I can very much see in happen in the wild: picture alt=Alt tag describing the image represented !--source src=photo-s.jpg/-- source src=photo-s.jpg/ source src=phot...@2x.jpg media=-webkit-min-device-pixel-ratio:2,-moz-min-device-pixel-ratio:2,-o-min-device-pixel-ratio: 2/1,min-device-pixel-ratio:2/ !--source src=photo-m.jpg media=min-width:321px/-- source src=photo-m.jpg media=min-width:321px/ source src=phot...@2x.jpg media=min-width:321px and -webkit-min-device-pixel-ratio:2,-moz-min-device-pixel-ratio:2,-o-min-device-pixel-ratio: 2/1,min-device-pixel-ratio:2/ !--source src=photo-l.jpg media=min-width:641px/-- source src=photo-l.jpg media=min-width:641px/ source src=phot...@2x.jpg media=min-width:641px and -webkit-min-device-pixel-ratio:2,-moz-min-device-pixel-ratio:2,-o-min-device-pixel-ratio: 2/1,min-device-pixel-ratio:2/ !--source src=photo-xl.jpg media=min-width:1281px /-- source src=photo-xl.jpg media=min-width:1281px / source src=photo...@2x.jpg media=min-width:1281px and -webkit-min-device-pixel-ratio:2,-moz-min-device-pixel-ratio:2,-o-min-device-pixel-ratio: 2/1,min-device-pixel-ratio:2 / noscriptimg src=photo-s.jpg //noscript /picture //Notes //-- Markup based off of Scott Jehl's picturefill example. Added commented source elements (needed for IE9, Android 2.1-2.3 and iOS 4.3 Safari) to demonstrate how a real life cross-browser implementation might look like. 15 lines of code for 1 image :( Granted this may be better aligned to a separate topic unto itself, but thought it needed to be documented. Cheers, D.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
On Wed, May 16, 2012 at 9:20 AM, Odin Hørthe Omdal odi...@opera.com wrote: Silvia Pfeiffer silviapfeiff...@gmail.com skreiv Wed, 16 May 2012 00:57:48 +0200 Media queries come from the client side. They allow the author of a web page to tell exactly how she want to lay out her design based on the different queries. The browser *HAS* to follow these queries. And also, I don't think (please correct me if wrong) the media query can be subset to only the stuff that's really meaningful to do at prefetch-time. The srcset proposal, on the other hand, are purely HINTS to the browser engine about the resources. They are only declarative hints that can be leveraged in a secret sauce way (like Bruce said in another mail) to always optimize image fetching and other features. If you make a new kind of browser (like e.g. Opera mini) it can have its own heuristics that make sense *for that single browser* without asking _anyone_. Without relying on web authors doing the correct thing, or changing anything or even announce to anyone what they are doing. It's opening up for innovation, good algorithms and smart uses in the future. That's the basic difference, totally different. If that's the case, would it make sense to get rid of the @media attribute on source elements in video and replace it with @srcset? Video is at least a bit different in that you don't expect it to be fully loaded and prefetch at such an early stage as img. But I've been thinking about that since I read something like we already have media queries in source for video, but it's not really implemented and used yet. Some browsers support @media in video for min/max width and height specifications. But I believe the use case is more like the one we are trying to solve with @srcset than a traditional media queries use case. I'm not sure. What do you think? As far as I've seen, you're highly knowledgeable about video. Why do we have mediaqueries on video element? Do we have a use case page? Hehe, thanks. :-) But media queries were in video before I arrived, so I missed the whole discussion around it and how it got there. Some of the browsers that implement support for it should speak up. Doing the same as whatever img ends up doing might be a good fit if the use cases are similar enough. Would be nice to be consistent if that makes sense. I'm not 100% sure I grok the difference between media queries and @srcset. I threw this question into the mix to see the reaction - maybe we need both? What would that even mean? In addition, I wonder about the adaptive streaming case where byte ranges from different files are being switched to dynamically during playback because of bandwidth change. For video, the solution seems to be: use a manifest file in your @src (such as DASH) and rely on the browser to pick between the files. Or you use javascript: http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html . An attribute like @srcset would allow listing the alternative files directly in the HTML file. That may be preferable? More questions than answers right now, but we should think consistently between audio, video and images. Cheers, Silvia.
Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?
You might remember about my proposal 9 months ago. If not you can see it here: https://gist.github.com/1158855 img src=http://cdn.url.com/img/myimage_xs.jpg; media-xs=(min-device-width:320px and max-device-width:640px) media-xs-src=http://cdn.url.com/img/myimage_xs.jpg; media-m=(min-device-width:640px and max-device-width:1024px) media-m-src=http://cdn.url.com/img/myimage_m.jpg; media-xl=(min-device-width:1024px) media-xl-src=http://cdn.url.com/img/myimage_xsl.jpg; img src=http://cdn.url.com/img/myimage_xs.jpg; media-xs-src=http://cdn.url.com/img/myimage_xs.jpg; media-m-src=http://cdn.url.com/img/myimage_m.jpg; media-xl-src=http://cdn.url.com/img/myimage_xsl.jpg; This is between the @srclist and the picture-element. It has MQ (which are optional imo, of course the browser should have a standard MQ (how ever this can look like and might feature bandwidth also)) and a sourcelist. And it features a html-common usage while being shorthand. I also believe that if the developers should ever be provided with a bandwidth API this could be handled via media-queries. The first example shows that a developer wants to specifically target specific screen sizes with a MQ while in the second it is up to the browser which one is used. At least the normal src= is thought as fallback behavior for older browsers. Doing the same as whatever img ends up doing might be a good fit if the use cases are similar enough. Would be nice to be consistent if that makes sense. I'm not 100% sure I grok the difference between media queries and @srcset. I threw this question into the mix to see the reaction - maybe we need both? What would that even mean? I don't know if we need both. Why should we? Because @media-query features are currently not enough? Standard behavior which is build in a browser won't need any of these solutions, right? Also the picture-element does not *require* a MQ. It can also be used to just serve a list of sources and let it up to the browser what to fetch. In addition, I wonder about the adaptive streaming case where byte ranges from different files are being switched to dynamically during playback because of bandwidth change. For video, the solution seems to be: use a manifest file in your @src (such as DASH) and rely on the browser to pick between the files. Or you use javascript: http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html . An attribute like @srcset would allow listing the alternative files directly in the HTML file. That may be preferable? This sounds good but too complicated for a normal developer and you have to see that we also should respect CMS implementations. I don't know (but probably only don't understand the technique correct) if this is not too complicated? More questions than answers right now, but we should think consistently between audio, video and images. That is what I totally support except there are already adaptive streaming technologies for video-formats but not for pictures (which is another topic I came up against a brick-wall). -Anselm
