Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 4:26 PM, Tab Atkins Jr. wrote: > On Wed, May 16, 2012 at 12:33 PM, Jacob Mather wrote: >> On Wed, May 16, 2012 at 3:26 PM, Tab Atkins Jr. wrote: >>> On Wed, May 16, 2012 at 12:12 PM, Jacob Mather wrote: Maybe this is the better question: Why does the pre-loader matter so much? >>> >>> Because it lets pages load faster. >>> >> >> Sure, but s that enough to make for a massive pile of junk-work to do >> whenever a site is redesigned? >> >> Could this not be better addressed through better/faster css >> processing? There would still be more of a delay, but I'm just trying >> to say that the trade-offs could be more than worth it. > > There are limits to what you can do, unfortunately. No matter how > fast your CSS parsing is, your CSS file should be external, which > means you have to make a request for the CSS file, wait for it to > finish, *then* parse the CSS and figure out what images to request. > That indirection is necessary for good, maintainable design, but it's > murder for page load speed. > > This is an unresolvable conflict right now, given the design of HTTP. > SPDY can help us fix this - the server can proactively start pushing > resources at the client that it knows will be needed for the page, > instead of waiting for the client to realize that it's needed and make > a request. SPDY is developing nicely (and I think is becoming HTTP > 2.0?), so this'll happen in the future, but for now we still have a > tradeoff. > > ~TJ I get that. I understand the delays and such involved. I'm just making sure it's critically looked at. At the end of the day, my CMS handles images internally, so I can just update how the image template prints out the display and I'm good to go on an update. I'm just trying to look at others who won't have it as easy. Consider WordPress Guy who has all of this code embedded, and has to go back and update every post in order to change. Consider Left Bar Girl who actually sets the same image on two different break points (i.e. big image, small image, and then big image again) because after she un-floats the left bar, the larger image is the best fit again. Perhaps that's a use case to put up on the wiki, the whole left bar deal. Why not adopt a better standard that is forward looking to SPDY?
Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 12:33 PM, Jacob Mather wrote: > On Wed, May 16, 2012 at 3:26 PM, Tab Atkins Jr. wrote: >> On Wed, May 16, 2012 at 12:12 PM, Jacob Mather wrote: >>> Maybe this is the better question: >>> >>> Why does the pre-loader matter so much? >> >> Because it lets pages load faster. >> > > Sure, but s that enough to make for a massive pile of junk-work to do > whenever a site is redesigned? > > Could this not be better addressed through better/faster css > processing? There would still be more of a delay, but I'm just trying > to say that the trade-offs could be more than worth it. There are limits to what you can do, unfortunately. No matter how fast your CSS parsing is, your CSS file should be external, which means you have to make a request for the CSS file, wait for it to finish, *then* parse the CSS and figure out what images to request. That indirection is necessary for good, maintainable design, but it's murder for page load speed. This is an unresolvable conflict right now, given the design of HTTP. SPDY can help us fix this - the server can proactively start pushing resources at the client that it knows will be needed for the page, instead of waiting for the client to realize that it's needed and make a request. SPDY is developing nicely (and I think is becoming HTTP 2.0?), so this'll happen in the future, but for now we still have a tradeoff. ~TJ
Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 3:26 PM, Tab Atkins Jr. wrote: > On Wed, May 16, 2012 at 12:12 PM, Jacob Mather wrote: >> Maybe this is the better question: >> >> Why does the pre-loader matter so much? > > Because it lets pages load faster. > Sure, but s that enough to make for a massive pile of junk-work to do whenever a site is redesigned? Could this not be better addressed through better/faster css processing? There would still be more of a delay, but I'm just trying to say that the trade-offs could be more than worth it. > >> Basing the selected image off of browser width is inherently >> backwards. The content should be informed by the layout, not by the >> browser. > > Media Queries only provide you either the browser width/height or the > device width/height. So your responsive designs are all based off > this information already. > > Content-based queries are unfortunately quite troublesome, for reasons > that have been explained before on the www-style list. > > ~TJ Responsive design at this point is primarily about the layout. There's a little bit done with the content, but generally it is just in making sure the content itself is elastic to fill the layout space given. It makes sense that content-aware queries would be difficult, as i'm sure if coded incorrectly they could go recursive and tumble over. Though, I don't think that means we should just accept a less than perfect solution because the correct one is hard.
Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 12:12 PM, Jacob Mather wrote: > Maybe this is the better question: > > Why does the pre-loader matter so much? Because it lets pages load faster. > Basing the selected image off of browser width is inherently > backwards. The content should be informed by the layout, not by the > browser. Media Queries only provide you either the browser width/height or the device width/height. So your responsive designs are all based off this information already. Content-based queries are unfortunately quite troublesome, for reasons that have been explained before on the www-style list. ~TJ
Re: [whatwg] Features for responsive Web design
I had mentioned to you before that I had this little 'niggle' of a feeling of something wrong about that, and I figured out what it is. If you move the decision of /which/ image is the correct image to the head of a document, then the content is no longer autonomous and semantic, because the content alone no longer contains everything needed to know to understand the content. On Wed, May 16, 2012 at 3:19 PM, Matthew Wilcox wrote: > On 16 May 2012 20:12, Jacob Mather wrote: >> Maybe this is the better question: >> >> Why does the pre-loader matter so much? >> >> Basing the selected image off of browser width is inherently >> backwards. The content should be informed by the layout, not by the >> browser. >> > > I do agree with you (it's all about layout rather than screen width - > it's the layout that dictates the content images and it's the screen > width that dictates the layout - there's a clear stack of dependancies > and at the moment that isn't reflected in the technology we use). > However I think the problem right now is that at the time the browser > see's the it is likely to not know the layout. The CSS hasn't > loaded yet and the layout hasn't been applied - so the image can't > know how big it needs to be. This is why I put forward the idea of > setting breakpoints in the as a tag. That is the one and > only place that other technologies can be sure will have already been > loaded.
Re: [whatwg] Features for responsive Web design
@Tab - yes I do remember, sorry. I'm being a bloody idiot.
Re: [whatwg] Features for responsive Web design
On 16 May 2012 20:12, Jacob Mather wrote: > Maybe this is the better question: > > Why does the pre-loader matter so much? > > Basing the selected image off of browser width is inherently > backwards. The content should be informed by the layout, not by the > browser. > I do agree with you (it's all about layout rather than screen width - it's the layout that dictates the content images and it's the screen width that dictates the layout - there's a clear stack of dependancies and at the moment that isn't reflected in the technology we use). However I think the problem right now is that at the time the browser see's the it is likely to not know the layout. The CSS hasn't loaded yet and the layout hasn't been applied - so the image can't know how big it needs to be. This is why I put forward the idea of setting breakpoints in the as a tag. That is the one and only place that other technologies can be sure will have already been loaded.
Re: [whatwg] Features for responsive Web design
On 16 May 2012 20:04, Tab Atkins Jr. wrote: > On Wed, May 16, 2012 at 11:55 AM, Matthew Wilcox > wrote: >> On 16 May 2012 19:47, Tab Atkins Jr. wrote: >>> On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox >>> wrote: Also, srcset does not abstract the control points away from the image itself. I have already been over why this is a problem and future-unfriendly. Breakpoints are based on a when a *design* becomes visually broken, not on the width of a device. So, when a design changes, so will the response breakpoints, and that would mean having to revisit and edit every image that's had srcset applied - unless I am missing something (which given the last day or two, I may well be). >>> >>> You're right that changing your breakpoints requires changing all the >>> @srcset declarations. An unfortunate aspect of our inability to >>> abstract away some of the functionality without breaking some of the >>> features (like being preloader-friendly). >> >> I must admit, I am still confused about the pre-loader issue. I'm not >> sure whether the plan is that we'd be able to convince vendors to >> disable it on elements containing srcset (or whatever solution >> ends up final) or whether this is something that has to be worked with >> now (in which case the variable idea seems to me the only one >> that could work). > > Given the current syntax, the idea is that browsers will be able to > preload the *correct* image from @srcset. They have all the > information necessary to make the decision at parse-time. > > I'm not entirely sure how accurate this is, though. Some better info > one way or another would be useful. Cool. That makes sense but would require the browser to update it's pre-parser behaviour I imagine (i.e., scan the whole element rather than just try as soon as the src has been read - so it's not backward compatible right now) :) >>> However, something similar to your idea certainly seems possible to >>> use in an extention of the syntax. Rather than specifying a w/h >>> component, give a 'case' component that refers to a breakpoint defined >>> elsewhere. This could even potentially extend into url-templating. >> >> That's the conclusion that was come to at the RICG too, and why >> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ >> was put forward. I haven't received promising feedback from the WHATWG >> about it though :s > > Yeah, I was purposely calling back to the post you linked above. > > I gave it some criticism here in WHATWG. > Ah, I thought you were. I'll go have another look because I think I missed it - I'm only aware of one person feeding back - but then it's the end of the day and I'm not wholey convinced I won't see your reply and then remember reading it. It's been a busy day. Cheers Tab. > ~TJ
Re: [whatwg] Features for responsive Web design
Maybe this is the better question: Why does the pre-loader matter so much? Basing the selected image off of browser width is inherently backwards. The content should be informed by the layout, not by the browser. On Wed, May 16, 2012 at 3:04 PM, Tab Atkins Jr. wrote: > On Wed, May 16, 2012 at 11:55 AM, Matthew Wilcox > wrote: >> On 16 May 2012 19:47, Tab Atkins Jr. wrote: >>> On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox >>> wrote: Also, srcset does not abstract the control points away from the image itself. I have already been over why this is a problem and future-unfriendly. Breakpoints are based on a when a *design* becomes visually broken, not on the width of a device. So, when a design changes, so will the response breakpoints, and that would mean having to revisit and edit every image that's had srcset applied - unless I am missing something (which given the last day or two, I may well be). >>> >>> You're right that changing your breakpoints requires changing all the >>> @srcset declarations. An unfortunate aspect of our inability to >>> abstract away some of the functionality without breaking some of the >>> features (like being preloader-friendly). >> >> I must admit, I am still confused about the pre-loader issue. I'm not >> sure whether the plan is that we'd be able to convince vendors to >> disable it on elements containing srcset (or whatever solution >> ends up final) or whether this is something that has to be worked with >> now (in which case the variable idea seems to me the only one >> that could work). > > Given the current syntax, the idea is that browsers will be able to > preload the *correct* image from @srcset. They have all the > information necessary to make the decision at parse-time. > > I'm not entirely sure how accurate this is, though. Some better info > one way or another would be useful. > > >>> However, something similar to your idea certainly seems possible to >>> use in an extention of the syntax. Rather than specifying a w/h >>> component, give a 'case' component that refers to a breakpoint defined >>> elsewhere. This could even potentially extend into url-templating. >> >> That's the conclusion that was come to at the RICG too, and why >> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ >> was put forward. I haven't received promising feedback from the WHATWG >> about it though :s > > Yeah, I was purposely calling back to the post you linked above. > > I gave it some criticism here in WHATWG. > > ~TJ
Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 11:55 AM, Matthew Wilcox wrote: > On 16 May 2012 19:47, Tab Atkins Jr. wrote: >> On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox >> wrote: >>> Also, srcset does not abstract the control points away from the image >>> itself. I have already been over why this is a problem and >>> future-unfriendly. Breakpoints are based on a when a *design* becomes >>> visually broken, not on the width of a device. So, when a design >>> changes, so will the response breakpoints, and that would mean having >>> to revisit and edit every image that's had srcset applied - unless I >>> am missing something (which given the last day or two, I may well be). >> >> You're right that changing your breakpoints requires changing all the >> @srcset declarations. An unfortunate aspect of our inability to >> abstract away some of the functionality without breaking some of the >> features (like being preloader-friendly). > > I must admit, I am still confused about the pre-loader issue. I'm not > sure whether the plan is that we'd be able to convince vendors to > disable it on elements containing srcset (or whatever solution > ends up final) or whether this is something that has to be worked with > now (in which case the variable idea seems to me the only one > that could work). Given the current syntax, the idea is that browsers will be able to preload the *correct* image from @srcset. They have all the information necessary to make the decision at parse-time. I'm not entirely sure how accurate this is, though. Some better info one way or another would be useful. >> However, something similar to your idea certainly seems possible to >> use in an extention of the syntax. Rather than specifying a w/h >> component, give a 'case' component that refers to a breakpoint defined >> elsewhere. This could even potentially extend into url-templating. > > That's the conclusion that was come to at the RICG too, and why > http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ > was put forward. I haven't received promising feedback from the WHATWG > about it though :s Yeah, I was purposely calling back to the post you linked above. I gave it some criticism here in WHATWG. ~TJ
Re: [whatwg] Features for responsive Web design
On 16 May 2012 19:47, Tab Atkins Jr. wrote: > On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox > wrote: >> Also, srcset does not abstract the control points away from the image >> itself. I have already been over why this is a problem and >> future-unfriendly. Breakpoints are based on a when a *design* becomes >> visually broken, not on the width of a device. So, when a design >> changes, so will the response breakpoints, and that would mean having >> to revisit and edit every image that's had srcset applied - unless I >> am missing something (which given the last day or two, I may well be). > > You're right that changing your breakpoints requires changing all the > @srcset declarations. An unfortunate aspect of our inability to > abstract away some of the functionality without breaking some of the > features (like being preloader-friendly). I must admit, I am still confused about the pre-loader issue. I'm not sure whether the plan is that we'd be able to convince vendors to disable it on elements containing srcset (or whatever solution ends up final) or whether this is something that has to be worked with now (in which case the variable idea seems to me the only one that could work). > However, something similar to your idea certainly seems possible to > use in an extention of the syntax. Rather than specifying a w/h > component, give a 'case' component that refers to a breakpoint defined > elsewhere. This could even potentially extend into url-templating. That's the conclusion that was come to at the RICG too, and why http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ was put forward. I haven't received promising feedback from the WHATWG about it though :s > This seems like a good bit of complexity for now, though. I'd prefer > to iterate on the current proposal, keeping this kind of thing in > mind. In particular, adding something like url-templating would > *massively* blow up the complexity of the feature, and delay its > implementation. I'm happy with that too, any progress is good progress and it doesn't all have to come at once. That said I won't use any solution until it has this level of abstraction: that's a criticism I brought up with too (and why I wouldn't use that either in it's current RICG form). > > ~TJ
Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox wrote: > Also, srcset does not abstract the control points away from the image > itself. I have already been over why this is a problem and > future-unfriendly. Breakpoints are based on a when a *design* becomes > visually broken, not on the width of a device. So, when a design > changes, so will the response breakpoints, and that would mean having > to revisit and edit every image that's had srcset applied - unless I > am missing something (which given the last day or two, I may well be). You're right that changing your breakpoints requires changing all the @srcset declarations. An unfortunate aspect of our inability to abstract away some of the functionality without breaking some of the features (like being preloader-friendly). However, something similar to your idea certainly seems possible to use in an extention of the syntax. Rather than specifying a w/h component, give a 'case' component that refers to a breakpoint defined elsewhere. This could even potentially extend into url-templating. This seems like a good bit of complexity for now, though. I'd prefer to iterate on the current proposal, keeping this kind of thing in mind. In particular, adding something like url-templating would *massively* blow up the complexity of the feature, and delay its implementation. ~TJ
Re: [whatwg] Features for responsive Web design
Le 15/05/12 09:28, Ian Hickson a écrit : [snip] Three comments: 1. from the point of view of an editor (I mean a wysiwyg application), this is far too complex and painful. With my BlueGriffon hat on, please trust me on that. Where is the harmony, the consistency with the multi-source video and audio elements? Why should browsers and editing tools have to deal with a different mechanism? 2. the %w and %h syntax above will clash with the necessary escaping of non-URL compliant characters and I think this is a _very_ bad idea. All examples I saw include filenames only but these are really URIs ! 3. for the same reason, because some filesystems allow whitespaces and commas and more in filenames, the latter seems to me dangerous and certainly a bad idea. I know whitespaces in URIs will be encoded but decoding srcset will then imply parsing it to extract URIs before unescaping or whitespaces will become a problem. That's really too expensive. It's much more subjective but I have an extra comment: the proposed srcset attribute is absolutely ugly. I think the srcset approach is wrong. -- W3C CSS Working Group, Co-chair
Re: [whatwg] Features for responsive Web design
Henri Sivonen wrote: The what's currently in the spec is terribly counter-intuitive in this regard. The spec has a bug where it is contradicting itself in some steps. That makes it very hard to read and confusing for those who read those steps. I can see now how it does handle the art-direction case as well. I think it's a shame that it's a different syntax to media queries but on the plus side, if it maps directly to imgset in CSS, that's good. It seems to me that Media Queries are appropriate for the art-direction case and factors of the pixel dimensions of the image referred to by src="" are appropriate for the pixel density case. Yes, the late load (or extra load). And the early load. I'm not convinced that it's a good idea to solve these two axes in the same syntax or solution. It seems to me that srcset="" is bad for the art-direction case and is bad for the pixel density case. Wll. Not too sure I agree with /all/ of that. I agree in general, but I also think that the early load model should be allowed to fetch based on viewport size straight away. If I have to choose between "loading image late, when mq etc engine has started, being very flexible" and "loading image fast, not flexible at all, just browser magic" - I'd go for the second one. Even though we want to serve small images to my mobile phone, I'd still like for it to be as fast as the browser is able to handle. But it is merely meant for different sizes of the same content image then. Only doing pixel densities feels very limiting. A bit too limiting to be useful for the non-art directed "I just want it to go fast". -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
Note that this is also my major criticism of and the reason why I would not use it in the current CG state - and why I've been looking into variables as a method of abstracting the response points away from the responding element. I think this is a very important consideration. Anything baking response points directly into an element will be hell to work with in any re-design. -Matt On 16 May 2012 13:58, Matthew Wilcox wrote: > Also, srcset does not abstract the control points away from the image > itself. I have already been over why this is a problem and > future-unfriendly. Breakpoints are based on a when a *design* becomes > visually broken, not on the width of a device. So, when a design > changes, so will the response breakpoints, and that would mean having > to revisit and edit every image that's had srcset applied - unless I > am missing something (which given the last day or two, I may well be). > > -Matt > > On 16 May 2012 13:55, Matthew Wilcox wrote: >> Chalk me up as another making that mistake. Properties on elements >> usually describe a property of the element. Not a property of >> something else (like the viewport). >> >> I'm happier than I was about srcset - but why does the spec assume >> pixels? Or does it? >> >> Use case: design breakpoints can and often are based on non-pixel >> units. em's, for example. As far as I can tell, srcset does not work >> with units other than pixels, so how could it work reliably with >> designs done in non-pixel units? >> >> -Matt >> >> On 16 May 2012 13:38, PJ McCormick wrote: On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: > > You're right. I was thinking that the values (Nh Nw Nx) described the > *image* but in fact they describe (in the case of Nh and Nw) the viewport > and (in the case of Nx) the pixel density of the screen/device. > > > > I suspect I won't be the only one to make that mistake. > > Indeed. I made the same mistake initially. The what's currently in the > spec is terribly counter-intuitive in this regard. >>> I also made the same mistake, and it took combing through all of >>> yesterday's and this morning's discussions on the topic for me to finally >>> understand it properly. And I consider myself to be a fairly competent >>> developer, not someone just starting out with HTML. >>> >>> Now that I do understand I'm honestly happier with @srcset as a concept, >>> but my problems with the syntax itself still remain. In fact, they might be >>> amplified. Surely we can refine this into a better, more easily understood >>> syntax. >>> >>> >>> >>> >>> On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen wrote: >>> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: > You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. > > I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. > I can see now how it does handle the art-direction case as well. I think it's a shame that it's a different syntax to media queries but on the plus side, if it maps directly to imgset in CSS, that's good. It seems to me that Media Queries are appropriate for the art-direction case and factors of the pixel dimensions of the image referred to by src="" are appropriate for the pixel density case. I'm not convinced that it's a good idea to solve these two axes in the same syntax or solution. It seems to me that srcset="" is bad for the art-direction case and is bad for the pixel density case. (I think the concept of dpi isn't appropriate for either case, FWIW. I think "the number of horizontal and vertical bitmap samples doubled relative to the traditional src image" works much better conceptually for Web authoring than making people do dpi math with an abstract baseline of 96 dpi. Anecdotal observation of trying to get family members to do dpi math for print publications suggests that it's hard to get educated people do dpi math right even when an "inch" is a real inch an not an abstraction.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Features for responsive Web design
Also, srcset does not abstract the control points away from the image itself. I have already been over why this is a problem and future-unfriendly. Breakpoints are based on a when a *design* becomes visually broken, not on the width of a device. So, when a design changes, so will the response breakpoints, and that would mean having to revisit and edit every image that's had srcset applied - unless I am missing something (which given the last day or two, I may well be). -Matt On 16 May 2012 13:55, Matthew Wilcox wrote: > Chalk me up as another making that mistake. Properties on elements > usually describe a property of the element. Not a property of > something else (like the viewport). > > I'm happier than I was about srcset - but why does the spec assume > pixels? Or does it? > > Use case: design breakpoints can and often are based on non-pixel > units. em's, for example. As far as I can tell, srcset does not work > with units other than pixels, so how could it work reliably with > designs done in non-pixel units? > > -Matt > > On 16 May 2012 13:38, PJ McCormick wrote: >>> >>> On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen wrote: >>> >>> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: > You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. > > I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. >>> >>> >> I also made the same mistake, and it took combing through all of >> yesterday's and this morning's discussions on the topic for me to finally >> understand it properly. And I consider myself to be a fairly competent >> developer, not someone just starting out with HTML. >> >> Now that I do understand I'm honestly happier with @srcset as a concept, >> but my problems with the syntax itself still remain. In fact, they might be >> amplified. Surely we can refine this into a better, more easily understood >> syntax. >> >> >> >> >> On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen wrote: >> >>> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: >>> > You're right. I was thinking that the values (Nh Nw Nx) described the >>> *image* but in fact they describe (in the case of Nh and Nw) the viewport >>> and (in the case of Nx) the pixel density of the screen/device. >>> > >>> > I suspect I won't be the only one to make that mistake. >>> >>> Indeed. I made the same mistake initially. The what's currently in the >>> spec is terribly counter-intuitive in this regard. >>> >>> > I can see now how it does handle the art-direction case as well. I think >>> it's a shame that it's a different syntax to media queries but on the plus >>> side, if it maps directly to imgset in CSS, that's good. >>> >>> It seems to me that Media Queries are appropriate for the >>> art-direction case and factors of the pixel dimensions of the image >>> referred to by src="" are appropriate for the pixel density case. >>> >>> I'm not convinced that it's a good idea to solve these two axes in the >>> same syntax or solution. It seems to me that srcset="" is bad for the >>> art-direction case and is bad for the pixel density case. >>> >>> (I think the concept of dpi isn't appropriate for either case, FWIW. I >>> think "the number of horizontal and vertical bitmap samples doubled >>> relative to the traditional src image" works much better conceptually >>> for Web authoring than making people do dpi math with an abstract >>> baseline of 96 dpi. Anecdotal observation of trying to get family >>> members to do dpi math for print publications suggests that it's hard >>> to get educated people do dpi math right even when an "inch" is a real >>> inch an not an abstraction.) >>> >>> -- >>> Henri Sivonen >>> hsivo...@iki.fi >>> http://hsivonen.iki.fi/ >>>
Re: [whatwg] Features for responsive Web design
Chalk me up as another making that mistake. Properties on elements usually describe a property of the element. Not a property of something else (like the viewport). I'm happier than I was about srcset - but why does the spec assume pixels? Or does it? Use case: design breakpoints can and often are based on non-pixel units. em's, for example. As far as I can tell, srcset does not work with units other than pixels, so how could it work reliably with designs done in non-pixel units? -Matt On 16 May 2012 13:38, PJ McCormick wrote: >> >> On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen wrote: >> >> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: >>> > You're right. I was thinking that the values (Nh Nw Nx) described the >>> *image* but in fact they describe (in the case of Nh and Nw) the viewport >>> and (in the case of Nx) the pixel density of the screen/device. >>> > >>> > I suspect I won't be the only one to make that mistake. >>> >>> Indeed. I made the same mistake initially. The what's currently in the >>> spec is terribly counter-intuitive in this regard. >> >> > I also made the same mistake, and it took combing through all of > yesterday's and this morning's discussions on the topic for me to finally > understand it properly. And I consider myself to be a fairly competent > developer, not someone just starting out with HTML. > > Now that I do understand I'm honestly happier with @srcset as a concept, > but my problems with the syntax itself still remain. In fact, they might be > amplified. Surely we can refine this into a better, more easily understood > syntax. > > > > > On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen wrote: > >> On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: >> > You're right. I was thinking that the values (Nh Nw Nx) described the >> *image* but in fact they describe (in the case of Nh and Nw) the viewport >> and (in the case of Nx) the pixel density of the screen/device. >> > >> > I suspect I won't be the only one to make that mistake. >> >> Indeed. I made the same mistake initially. The what's currently in the >> spec is terribly counter-intuitive in this regard. >> >> > I can see now how it does handle the art-direction case as well. I think >> it's a shame that it's a different syntax to media queries but on the plus >> side, if it maps directly to imgset in CSS, that's good. >> >> It seems to me that Media Queries are appropriate for the >> art-direction case and factors of the pixel dimensions of the image >> referred to by src="" are appropriate for the pixel density case. >> >> I'm not convinced that it's a good idea to solve these two axes in the >> same syntax or solution. It seems to me that srcset="" is bad for the >> art-direction case and is bad for the pixel density case. >> >> (I think the concept of dpi isn't appropriate for either case, FWIW. I >> think "the number of horizontal and vertical bitmap samples doubled >> relative to the traditional src image" works much better conceptually >> for Web authoring than making people do dpi math with an abstract >> baseline of 96 dpi. Anecdotal observation of trying to get family >> members to do dpi math for print publications suggests that it's hard >> to get educated people do dpi math right even when an "inch" is a real >> inch an not an abstraction.) >> >> -- >> Henri Sivonen >> hsivo...@iki.fi >> http://hsivonen.iki.fi/ >>
Re: [whatwg] Features for responsive Web design
> > On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen wrote: > > On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: >> > You're right. I was thinking that the values (Nh Nw Nx) described the >> *image* but in fact they describe (in the case of Nh and Nw) the viewport >> and (in the case of Nx) the pixel density of the screen/device. >> > >> > I suspect I won't be the only one to make that mistake. >> >> Indeed. I made the same mistake initially. The what's currently in the >> spec is terribly counter-intuitive in this regard. > > I also made the same mistake, and it took combing through all of yesterday's and this morning's discussions on the topic for me to finally understand it properly. And I consider myself to be a fairly competent developer, not someone just starting out with HTML. Now that I do understand I'm honestly happier with @srcset as a concept, but my problems with the syntax itself still remain. In fact, they might be amplified. Surely we can refine this into a better, more easily understood syntax. On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen wrote: > On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: > > You're right. I was thinking that the values (Nh Nw Nx) described the > *image* but in fact they describe (in the case of Nh and Nw) the viewport > and (in the case of Nx) the pixel density of the screen/device. > > > > I suspect I won't be the only one to make that mistake. > > Indeed. I made the same mistake initially. The what's currently in the > spec is terribly counter-intuitive in this regard. > > > I can see now how it does handle the art-direction case as well. I think > it's a shame that it's a different syntax to media queries but on the plus > side, if it maps directly to imgset in CSS, that's good. > > It seems to me that Media Queries are appropriate for the > art-direction case and factors of the pixel dimensions of the image > referred to by src="" are appropriate for the pixel density case. > > I'm not convinced that it's a good idea to solve these two axes in the > same syntax or solution. It seems to me that srcset="" is bad for the > art-direction case and is bad for the pixel density case. > > (I think the concept of dpi isn't appropriate for either case, FWIW. I > think "the number of horizontal and vertical bitmap samples doubled > relative to the traditional src image" works much better conceptually > for Web authoring than making people do dpi math with an abstract > baseline of 96 dpi. Anecdotal observation of trying to get family > members to do dpi math for print publications suggests that it's hard > to get educated people do dpi math right even when an "inch" is a real > inch an not an abstraction.) > > -- > Henri Sivonen > hsivo...@iki.fi > http://hsivonen.iki.fi/ >
Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith wrote: > You're right. I was thinking that the values (Nh Nw Nx) described the *image* > but in fact they describe (in the case of Nh and Nw) the viewport and (in the > case of Nx) the pixel density of the screen/device. > > I suspect I won't be the only one to make that mistake. Indeed. I made the same mistake initially. The what's currently in the spec is terribly counter-intuitive in this regard. > I can see now how it does handle the art-direction case as well. I think it's > a shame that it's a different syntax to media queries but on the plus side, > if it maps directly to imgset in CSS, that's good. It seems to me that Media Queries are appropriate for the art-direction case and factors of the pixel dimensions of the image referred to by src="" are appropriate for the pixel density case. I'm not convinced that it's a good idea to solve these two axes in the same syntax or solution. It seems to me that srcset="" is bad for the art-direction case and is bad for the pixel density case. (I think the concept of dpi isn't appropriate for either case, FWIW. I think "the number of horizontal and vertical bitmap samples doubled relative to the traditional src image" works much better conceptually for Web authoring than making people do dpi math with an abstract baseline of 96 dpi. Anecdotal observation of trying to get family members to do dpi math for print publications suggests that it's hard to get educated people do dpi math right even when an "inch" is a real inch an not an abstraction.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Features for responsive Web design
Tab wrote: > I suspect this is simply confusion about the proposal - @srcset > handles the "art-directed" case same as , just with a > somewhat more compact microsyntax rather than using MQs directly. You're right. I was thinking that the values (Nh Nw Nx) described the *image* but in fact they describe (in the case of Nh and Nw) the viewport and (in the case of Nx) the pixel density of the screen/device. I suspect I won't be the only one to make that mistake. I can see now how it does handle the art-direction case as well. I think it's a shame that it's a different syntax to media queries but on the plus side, if it maps directly to imgset in CSS, that's good. Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Features for responsive Web design
2012-05-16 10:19 Europe/Helsinki: Tab Atkins Jr.: > On Wed, May 16, 2012 at 12:14 AM, Mikko Rantalainen > wrote: >> I think that the correct syntax would be >> >> >> >> because the author assumes that the image will be rendered as 300x150. > > No, the "w" and "h" parameters have no effect on the image's size at > all. They're solely used to help pick an image. > > To have the image rendered at 300x150, just *send* a 300x150 image. > (Or, if the resolution parameter is "2x", send a 600x300 image, etc.) Okay, I had just misunderstood the relation between "w", "h" and "x" parameters. So we have following (if I've understood correctly): "w": minimum viewport width in CSS pixels for this image "h": minimum viewport width in CSS pixels for this image "x": the scaling value from CSS pixels to image data pixels I think that's fine. Perhaps allow "ppi" or "dpi" instead of x, too? -- Mikko
Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 12:14 AM, Mikko Rantalainen wrote: > 2012-05-16 03:26 Europe/Helsinki: Tab Atkins Jr.: >> On Tue, May 15, 2012 at 5:15 PM, Jason Grigsby wrote: >>> In the @srcset syntax, I *think* I would end up with something like this: >>> >>> >> srcset="a-rectangle.png 300w 150h 1x, >>> a-square.png 100w 100h 1x"> >> >> Nope, what you want is this: >> >> >> >> Use "a-square.png" by default, and "a-rectangle.png" only if the >> window is at least 600px wide. >> >> I agree that the syntax doesn't make this obvious - it's *too* >> compact, so there's no redundant indicators of what the "w" number >> means. > > I think that the correct syntax would be > > > > because the author assumes that the image will be rendered as 300x150. > > I agree that the @srcset can handle the "art-directed" use case as well, > but one needs to specify media-query-like value for the "w" parameter > and then compute the "x" parameter to match the expected size of the > image. In many cases, the "x" parameter will have a non-integer value. > Not as simple as most authors would want but I think that's acceptable. No, the "w" and "h" parameters have no effect on the image's size at all. They're solely used to help pick an image. To have the image rendered at 300x150, just *send* a 300x150 image. (Or, if the resolution parameter is "2x", send a 600x300 image, etc.) ~TJ
Re: [whatwg] Features for responsive Web design
2012-05-16 03:26 Europe/Helsinki: Tab Atkins Jr.: > On Tue, May 15, 2012 at 5:15 PM, Jason Grigsby wrote: >> In the @srcset syntax, I *think* I would end up with something like this: >> >> > srcset="a-rectangle.png 300w 150h 1x, >> a-square.png 100w 100h 1x"> > > Nope, what you want is this: > > > > Use "a-square.png" by default, and "a-rectangle.png" only if the > window is at least 600px wide. > > I agree that the syntax doesn't make this obvious - it's *too* > compact, so there's no redundant indicators of what the "w" number > means. I think that the correct syntax would be because the author assumes that the image will be rendered as 300x150. I agree that the @srcset can handle the "art-directed" use case as well, but one needs to specify media-query-like value for the "w" parameter and then compute the "x" parameter to match the expected size of the image. In many cases, the "x" parameter will have a non-integer value. Not as simple as most authors would want but I think that's acceptable. I think that the "k" parameter for the size in kilobytes should be included in the spec. Even if it weren't used for bandwidth responsive use by UAs, it could be used for other stuff (for example, computing the amount of bytes that the full page still requires and as a result, being able to display accurate progress bar for page loading). -- Mikko
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 5:15 PM, Jason Grigsby wrote: > > On May 15, 2012, at 4:51 PM, Tab Atkins Jr. wrote: > >> I suspect this is simply confusion about the proposal - @srcset >> handles the "art-directed" case same as , just with a >> somewhat more compact microsyntax rather than using MQs directly. (On >> the plus side, the slightly-special processing of the microsyntax >> ensures that at least one image will be chosen no matter what, while >> it's unclear how an MQ-based solution will work if none of the MQs >> match.) >> >> Given that @srcset was generated as a solution to the use-cases that >> the CG brought up, it would be difficult to justify it if it didn't >> handle those cases. ^_^ > > I understand that @srcset is intended to also address art direction. I fear > that my attempts to explain the art direction need haven’t been sufficient > and thus it seems like @srcset supports it, but really doesn’t. BUT because I > find @srcset confusing, I can’t tell if my impression is correct or if I just > don’t get @srcset. > > The key thing I’m trying to wrap my mind around is that I will want to make a > layout change at a certain viewport width. Say that layout change also means > that I’m going to go from images that are rectangular to thumbnails that are > square. > > That layout change may happen at 600px. The thumbnails are 100x100. The > images used above the 600px breakpoint are 300x150. > > In the @srcset syntax, I *think* I would end up with something like this: > > srcset="a-rectangle.png 300w 150h 1x, > a-square.png 100w 100h 1x"> Nope, what you want is this: Use "a-square.png" by default, and "a-rectangle.png" only if the window is at least 600px wide. I agree that the syntax doesn't make this obvious - it's *too* compact, so there's no redundant indicators of what the "w" number means. > With a viewport width of 400px, the media query I defined to modify my layout > would take affect. The layout would thus assume a square image. But @srcset > would pick the rectangle image because both images are smaller than the > viewport and the algorithm that Hixie defined says, “then of the remaining > images pick the widest one, if any have a width, tie-breaking by picking the > tallest one”. With the fixed example, at a window width of 400px, the rectangle image would be thrown out and we'd use the square. ~TJ
Re: [whatwg] Features for responsive Web design
On May 15, 2012, at 4:51 PM, Tab Atkins Jr. wrote: > I suspect this is simply confusion about the proposal - @srcset > handles the "art-directed" case same as , just with a > somewhat more compact microsyntax rather than using MQs directly. (On > the plus side, the slightly-special processing of the microsyntax > ensures that at least one image will be chosen no matter what, while > it's unclear how an MQ-based solution will work if none of the MQs > match.) > > Given that @srcset was generated as a solution to the use-cases that > the CG brought up, it would be difficult to justify it if it didn't > handle those cases. ^_^ I understand that @srcset is intended to also address art direction. I fear that my attempts to explain the art direction need haven’t been sufficient and thus it seems like @srcset supports it, but really doesn’t. BUT because I find @srcset confusing, I can’t tell if my impression is correct or if I just don’t get @srcset. The key thing I’m trying to wrap my mind around is that I will want to make a layout change at a certain viewport width. Say that layout change also means that I’m going to go from images that are rectangular to thumbnails that are square. That layout change may happen at 600px. The thumbnails are 100x100. The images used above the 600px breakpoint are 300x150. In the @srcset syntax, I *think* I would end up with something like this: With a viewport width of 400px, the media query I defined to modify my layout would take affect. The layout would thus assume a square image. But @srcset would pick the rectangle image because both images are smaller than the viewport and the algorithm that Hixie defined says, “then of the remaining images pick the widest one, if any have a width, tie-breaking by picking the tallest one”. This is where the disconnect on the art direction side happens. From a layout perspective, we’ve making decision based on viewport size (or whatever other media query we want, but primarily viewport size). But from the img tag perspective, we’re selecting images by comparing image size to viewport. It seems to me that the differences in these comparisons will inevitably cause problems for the art direction use case because they will be out of sync. -Jason
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 4:43 PM, Kornel Lesiński wrote: > On Tue, 15 May 2012 19:25:23 +0100, Matthew Wilcox > wrote: > >> I think there's a fundamental mis-match in the mental model of how >> authors work and what they want. I'm pretty sure we're all shooting >> for the same "be more efficient" goal, but I think that here on the >> mailing list that's being approached from an angle that has not >> considered how authors actually want to do this. >> >> We work with designs that re-arrange content and sometimes call for >> different images of the same semantic meaning. That is *not* the same >> use case as simply sending a different version of the same image. >> Srcset only addresses that one type of use, and that is why authors >> feel it's flawed. It doesn't do what we need, and never can because >> srcset is based on the assumptin that a UA can somehow pick an >> appropriate resource to load - when it can't possibly know about the >> authors use of that resource at that time. > > > There's very good article about the two cases: > > http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ > > srcset is not very good for "art-directed" case, while is perfect > for it. > > is not very good for resolution/bandwidth optimisation, while > srcset is perfect for it. > > > I think those are simply two different problems that just happen to be > called "adaptive images". We should recognized that they're separate and > design separate solutions for them. A single solution can't do both well, > since there's a fundamental difference between author-controlled and > UA-controlled decision. I suspect this is simply confusion about the proposal - @srcset handles the "art-directed" case same as , just with a somewhat more compact microsyntax rather than using MQs directly. (On the plus side, the slightly-special processing of the microsyntax ensures that at least one image will be chosen no matter what, while it's unclear how an MQ-based solution will work if none of the MQs match.) Given that @srcset was generated as a solution to the use-cases that the CG brought up, it would be difficult to justify it if it didn't handle those cases. ^_^ ~TJ
Re: [whatwg] Features for responsive Web design
On Tue, 15 May 2012 19:25:23 +0100, Matthew Wilcox wrote: I think there's a fundamental mis-match in the mental model of how authors work and what they want. I'm pretty sure we're all shooting for the same "be more efficient" goal, but I think that here on the mailing list that's being approached from an angle that has not considered how authors actually want to do this. We work with designs that re-arrange content and sometimes call for different images of the same semantic meaning. That is *not* the same use case as simply sending a different version of the same image. Srcset only addresses that one type of use, and that is why authors feel it's flawed. It doesn't do what we need, and never can because srcset is based on the assumptin that a UA can somehow pick an appropriate resource to load - when it can't possibly know about the authors use of that resource at that time. There's very good article about the two cases: http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ srcset is not very good for "art-directed" case, while is perfect for it. is not very good for resolution/bandwidth optimisation, while srcset is perfect for it. I think those are simply two different problems that just happen to be called "adaptive images". We should recognized that they're separate and design separate solutions for them. A single solution can't do both well, since there's a fundamental difference between author-controlled and UA-controlled decision. -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 10:06 AM, Tab Atkins Jr. wrote: > >> For two, I'm not sure that it's particularly obvious that when you say > >> "2x", you should make sure your image was saved as 196dpi. You have > >> to already know what the default resolution is. > > > > You don't have to. The resolution of the image is ignored. > > If you don't set your image's resolution appropriately, you'll get > unexpected sizing effects. > I think the terms are confused, since we use "resolution" to refer to both image dimensions and DPI, which are very different things. We might want to avoid the term in a discussion that involves both. The DPI is ignored by browsers, of course; it's the dimensions vs. the scale factor that you have to get right. It would probably help readability a lot if you're allowed to use ratios, eg. 300/96 to mean 3.125. -- Glenn Maynard
Re: [whatwg] Features for responsive Web design
On May 15, 2012, at 8:06 AM, Tab Atkins Jr. wrote: > On Tue, May 15, 2012 at 9:28 AM, Ian Hickson wrote: >> On Thu, 10 May 2012, Tab Atkins Jr. wrote: >> >> 3.125x isn't particularly difficult to specify. > > I actually didn't even realize that 300dpi is 3.125 times 96dpi. > > Regardless, I think being able to specify "300dpi" is easier than > using a calculator. On the other hand, checking for an integer X factor is easier than checking for an integer multiple of 96dpi, for authors who would like to avoid the ugly visual artifacts of non-integral scaling. Which I hope is all of them. It's easier to tell that 3.125x is a bad idea than with 300dpi. Regards, Maciej
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 8:19 PM, Matthew Wilcox wrote: > Um, the fact of the matter is we don't want to ensure they have the > same ratio. It is exactly why we want to swap images sometimes - the > aspect ratio no longer fits the design being applied at the given > breakpoint. I think you misunderstand the scenario I'm talking about. You do want to vary the aspect-ratio based on screen-size breakpoints. For example, you may want to go from a 1024x300 image to a 600x200 image when the window is less than 1024px wide. You *don't* want to vary the aspect-ratio when you're just selecting different resolutions. As far as I know, there's no use-case for actually giving *different images* when you just select on resolution (after you've already decided which to use based on breakpoints). I'm ready to be corrected, but I haven't seen anything against this assumption yet. ~TJ
Re: [whatwg] Features for responsive Web design
I think there's a fundamental mis-match in the mental model of how authors work and what they want. I'm pretty sure we're all shooting for the same "be more efficient" goal, but I think that here on the mailing list that's being approached from an angle that has not considered how authors actually want to do this. We work with designs that re-arrange content and sometimes call for different images of the same semantic meaning. That is *not* the same use case as simply sending a different version of the same image. Srcset only addresses that one type of use, and that is why authors feel it's flawed. It doesn't do what we need, and never can because srcset is based on the assumptin that a UA can somehow pick an appropriate resource to load - when it can't possibly know about the authors use of that resource at that time. -Matt On 15 May 2012 19:19, Matthew Wilcox wrote: > Um, the fact of the matter is we don't want to ensure they have the > same ratio. It is exactly why we want to swap images sometimes - the > aspect ratio no longer fits the design being applied at the given > breakpoint. > > > > On 15 May 2012 18:48, Jason Grigsby wrote: >> On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote: >> >>> On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby wrote: Are you saying that all of the image source listed in srcset would have the same aspect ratio? In the example Hixie provided, face-icon.png is a different ratio. Another way to read this could be that you’re fine so long as your sources with different densities (e.g., 1x, 2x, etc) always have the same ratio. If so, I’m unclear on how that solves the problem when you have images that need different cropping like the Nokia example which is vertical in one case and horizontal in another. >>> >>> That's what I'm saying. Authors *can* ensure that, within a >>> particular breakpoint, their multi-res images all have the same ratio. >>> It's a good idea, since the *intention* is that the multi-res >>> versions are all exact same image, just at different resolutions. >>> >>> If you don't do that, you get unpredictable results, but you asked for that. >>> >>> If you *do* do that, then you know what your aspect ratio will be, and >>> you can predict which breakpoint will be chosen and pair that with MQs >>> to adjust the rest of your layout. >> >> Hmm… Doesn’t that then mean the solution to the use case is simply “don’t do >> it”? Or am I missing something? >> >> BTW, I know things are a little heated on irc right now so please read my >> questions as sincere attempts to understand how this would work and not as >> attempts to be obstinate. :-) >> >> -Jason
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 2:28 AM, Ian Hickson wrote: > Now I'm not sure what to do about the bandwidth one. It's very hard for a > user agent to estimate its bandwidth availability -- it depends on the > server, and the network location of the server, almost as much as on the > location of the client; it depends on the current network congestion, it > ... > It's tricky, but not necessarily impossible. Brainstorming a bit, it could be useful to specify the file size, eg. where the images are, say, JPEG q12, q10 and q4. This allows the browser to save bandwidth with a much lower quality loss than you'd see by using a lower-resolution image. (In principle, it could also download the LQ version first, then after the rest of the site has loaded and the page is usable, go back and start downloading a better version, replacing the image in-place invisibly to scripts. You sort-of get this with progressive JPEGs, but you can't get any control over it with HTTP.) This assumes the image quality is roughly linearly comparable; it probably wouldn't make sense to mix JPEG and PNG images like this. The heuristics for figuring out which size to use would be up to implementations. For example, if historical network statistics tell you your connection is at best 100k/sec, you probably don't want the HQ image; if you're at 3 MB/sec, the HQ one is probably fine. It might be that this is too hard a problem to ever work well enough to be useful--that is, if you think the QoI will never actually be good enough. -- Glenn Maynard
Re: [whatwg] Features for responsive Web design
Um, the fact of the matter is we don't want to ensure they have the same ratio. It is exactly why we want to swap images sometimes - the aspect ratio no longer fits the design being applied at the given breakpoint. On 15 May 2012 18:48, Jason Grigsby wrote: > On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote: > >> On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby wrote: >>> Are you saying that all of the image source listed in srcset would have the >>> same aspect ratio? In the example Hixie provided, face-icon.png is a >>> different ratio. >>> >>> Another way to read this could be that you’re fine so long as your sources >>> with different densities (e.g., 1x, 2x, etc) always have the same ratio. If >>> so, I’m unclear on how that solves the problem when you have images that >>> need different cropping like the Nokia example which is vertical in one >>> case and horizontal in another. >> >> That's what I'm saying. Authors *can* ensure that, within a >> particular breakpoint, their multi-res images all have the same ratio. >> It's a good idea, since the *intention* is that the multi-res >> versions are all exact same image, just at different resolutions. >> >> If you don't do that, you get unpredictable results, but you asked for that. >> >> If you *do* do that, then you know what your aspect ratio will be, and >> you can predict which breakpoint will be chosen and pair that with MQs >> to adjust the rest of your layout. > > Hmm… Doesn’t that then mean the solution to the use case is simply “don’t do > it”? Or am I missing something? > > BTW, I know things are a little heated on irc right now so please read my > questions as sincere attempts to understand how this would work and not as > attempts to be obstinate. :-) > > -Jason
Re: [whatwg] Features for responsive Web design
On May 15, 2012, at 9:54 AM, Tab Atkins Jr. wrote: > On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby wrote: >> Are you saying that all of the image source listed in srcset would have the >> same aspect ratio? In the example Hixie provided, face-icon.png is a >> different ratio. >> >> Another way to read this could be that you’re fine so long as your sources >> with different densities (e.g., 1x, 2x, etc) always have the same ratio. If >> so, I’m unclear on how that solves the problem when you have images that >> need different cropping like the Nokia example which is vertical in one case >> and horizontal in another. > > That's what I'm saying. Authors *can* ensure that, within a > particular breakpoint, their multi-res images all have the same ratio. > It's a good idea, since the *intention* is that the multi-res > versions are all exact same image, just at different resolutions. > > If you don't do that, you get unpredictable results, but you asked for that. > > If you *do* do that, then you know what your aspect ratio will be, and > you can predict which breakpoint will be chosen and pair that with MQs > to adjust the rest of your layout. Hmm… Doesn’t that then mean the solution to the use case is simply “don’t do it”? Or am I missing something? BTW, I know things are a little heated on irc right now so please read my questions as sincere attempts to understand how this would work and not as attempts to be obstinate. :-) -Jason
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 6:42 PM, Jason Grigsby wrote: > Are you saying that all of the image source listed in srcset would have the > same aspect ratio? In the example Hixie provided, face-icon.png is a > different ratio. > > Another way to read this could be that you’re fine so long as your sources > with different densities (e.g., 1x, 2x, etc) always have the same ratio. If > so, I’m unclear on how that solves the problem when you have images that need > different cropping like the Nokia example which is vertical in one case and > horizontal in another. That's what I'm saying. Authors *can* ensure that, within a particular breakpoint, their multi-res images all have the same ratio. It's a good idea, since the *intention* is that the multi-res versions are all exact same image, just at different resolutions. If you don't do that, you get unpredictable results, but you asked for that. If you *do* do that, then you know what your aspect ratio will be, and you can predict which breakpoint will be chosen and pair that with MQs to adjust the rest of your layout. ~TJ
Re: [whatwg] Features for responsive Web design
On May 15, 2012, at 7:58 AM, Tab Atkins Jr. wrote: > On Tue, May 15, 2012 at 4:51 PM, Jason Grigsby wrote: >> On May 15, 2012, at 12:28 AM, Ian Hickson wrote: * Example 2: On the Nokia Browser site where it describes the Meego browser, the Nokia Lumia is show horizontally on wide screens. As the screen narrows, the Nokia Lumia is then shown vertically and cropped. Bryan and Stephanie Rieger, the designers of the site, have talked about how on a wide screen, showing the full phone horizontally showed the browser best, but on small screens, changing the img to vertical made more sense because it allowed the reader to still make out the features of the browser in the image. >>> >>> >>src="landscape.png" >>>srcset="vertical-cropped.png 500w"> >> >> I don’t think srcset adequately addresses this use case. One thing to notice >> about the Nokia site is that the placement of text around the image is also >> changing as the image changes. Decisions are being made about whether to >> float text to the right or have it inline below the image. >> >> This is consistent with the idea of content first or content out responsive >> design. Breakpoints aren’t determined by device widths, but instead by where >> the layout--which in this case means the image and text--start looking >> awkward.[1] >> >> The challenge for srcset in this use case is that if the UA selects the >> image automatically, the author will not be able to judge when the layout >> looks awkward because there will be no way to anticipate which image the UA >> will select. >> >> Selection of what image is appropriate for a given layout at a specific >> breakpoint is not possible with srcset. This is possible for background >> images in CSS which makes srcset feel like a step backwards in this regard. >> >> Bear in mind, I’m not talking about selections of images based on pixel >> density, resolution, bandwidth, etc., which I will readily concede only the >> UA can make an intelligent decision abut. But instead selection of images >> based on decisions about what looks best at each breakpoint in a design >> which only the author can decide. > > That's actually fine. The max-width and max-height information > conveyed in @srcset is *not* used in a "do what you think is best" > manner. It's a very explicit filter. Thanks for responding Tab. I’ve read your comments five or six times now and am not certain I understand it fully. Sorry if I’m being dense here. :-) > You only get the "do what you think is best" behavior when deciding > between resolutions, and those only have an effect on layout if you > mess up your ratios *and* do auto-sizing (it only has an effect on the > intrinsic size, which auto-sizing uses). As long as you keep your > ratios lined up (like 1000@1, 2000@2, etc.) all of the images will > auto-size in the same way. Are you saying that all of the image source listed in srcset would have the same aspect ratio? In the example Hixie provided, face-icon.png is a different ratio. Another way to read this could be that you’re fine so long as your sources with different densities (e.g., 1x, 2x, etc) always have the same ratio. If so, I’m unclear on how that solves the problem when you have images that need different cropping like the Nokia example which is vertical in one case and horizontal in another. > So, since you can predict which size of image will get chosen, you can > pair that with ordinary Media Queries to predictably adjust the rest > of your layout. I’ve honestly been trying to figure out how such a pairing would work since we srcset was proposed and just don’t get it. The two seem very different because the media query only checks the viewport size and then takes specific action whereas srcset compares viewport to image size and grabs the largest image that fits. You end up tying image width to breakpoint width to make it work which means your image may be larger than it needs to be to fit the design. Again, I find it very clear how srcset would work for image resolution/density use cases, but get utterly confused about how it would work in the use case above. If everyone gets it, can someone send me a note outside the list to explain it? I don’t want to bog down the list by my lack of understanding if it clear to everyone else. -Jason
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 9:28 AM, Ian Hickson wrote: > On Thu, 10 May 2012, Tab Atkins Jr. wrote: >> >> That all said, I don't like the "2x" notation. It's declaring "this >> image's resolution is twice that of a normal image". This has two >> problems. For one, we already have a unit that means that - the dppx >> unit. Using "2dppx" is identical to the meaning of "2x". Since >> image-set() is newer than the dppx unit, we should change it to use >> instead. > > dppx is pretty ugly. I agree with hober's "2x" design. > >> For two, I'm not sure that it's particularly obvious that when you say >> "2x", you should make sure your image was saved as 196dpi. You have >> to already know what the default resolution is. > > You don't have to. The resolution of the image is ignored. If you don't set your image's resolution appropriately, you'll get unexpected sizing effects. >> As well, I think that values like 300dpi are pretty common, and they >> don't map to integral 'x' values. If people say "screw it" and use >> "3x", this'll be slightly wrong and I think will cause ugly blurring. >> If we make this take , people can just use the dpi unit. > > 3.125x isn't particularly difficult to specify. I actually didn't even realize that 300dpi is 3.125 times 96dpi. Regardless, I think being able to specify "300dpi" is easier than using a calculator. ~TJ
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 4:51 PM, Jason Grigsby wrote: > On May 15, 2012, at 12:28 AM, Ian Hickson wrote: >>> * Example 2: On the Nokia Browser site where it describes the Meego >>> browser, the Nokia Lumia is show horizontally on wide screens. As the >>> screen narrows, the Nokia Lumia is then shown vertically and cropped. >>> Bryan and Stephanie Rieger, the designers of the site, have talked about >>> how on a wide screen, showing the full phone horizontally showed the >>> browser best, but on small screens, changing the img to vertical made >>> more sense because it allowed the reader to still make out the features >>> of the browser in the image. >> >> > src="landscape.png" >> srcset="vertical-cropped.png 500w"> > > I don’t think srcset adequately addresses this use case. One thing to notice > about the Nokia site is that the placement of text around the image is also > changing as the image changes. Decisions are being made about whether to > float text to the right or have it inline below the image. > > This is consistent with the idea of content first or content out responsive > design. Breakpoints aren’t determined by device widths, but instead by where > the layout--which in this case means the image and text--start looking > awkward.[1] > > The challenge for srcset in this use case is that if the UA selects the image > automatically, the author will not be able to judge when the layout looks > awkward because there will be no way to anticipate which image the UA will > select. > > Selection of what image is appropriate for a given layout at a specific > breakpoint is not possible with srcset. This is possible for background > images in CSS which makes srcset feel like a step backwards in this regard. > > Bear in mind, I’m not talking about selections of images based on pixel > density, resolution, bandwidth, etc., which I will readily concede only the > UA can make an intelligent decision abut. But instead selection of images > based on decisions about what looks best at each breakpoint in a design which > only the author can decide. That's actually fine. The max-width and max-height information conveyed in @srcset is *not* used in a "do what you think is best" manner. It's a very explicit filter. You only get the "do what you think is best" behavior when deciding between resolutions, and those only have an effect on layout if you mess up your ratios *and* do auto-sizing (it only has an effect on the intrinsic size, which auto-sizing uses). As long as you keep your ratios lined up (like 1000@1, 2000@2, etc.) all of the images will auto-size in the same way. So, since you can predict which size of image will get chosen, you can pair that with ordinary Media Queries to predictably adjust the rest of your layout. ~TJ
Re: [whatwg] Features for responsive Web design
On May 15, 2012, at 12:28 AM, Ian Hickson wrote: >> * Example 2: On the Nokia Browser site where it describes the Meego >> browser, the Nokia Lumia is show horizontally on wide screens. As the >> screen narrows, the Nokia Lumia is then shown vertically and cropped. >> Bryan and Stephanie Rieger, the designers of the site, have talked about >> how on a wide screen, showing the full phone horizontally showed the >> browser best, but on small screens, changing the img to vertical made >> more sense because it allowed the reader to still make out the features >> of the browser in the image. > > src="landscape.png" >srcset="vertical-cropped.png 500w"> I don’t think srcset adequately addresses this use case. One thing to notice about the Nokia site is that the placement of text around the image is also changing as the image changes. Decisions are being made about whether to float text to the right or have it inline below the image. This is consistent with the idea of content first or content out responsive design. Breakpoints aren’t determined by device widths, but instead by where the layout--which in this case means the image and text--start looking awkward.[1] The challenge for srcset in this use case is that if the UA selects the image automatically, the author will not be able to judge when the layout looks awkward because there will be no way to anticipate which image the UA will select. Selection of what image is appropriate for a given layout at a specific breakpoint is not possible with srcset. This is possible for background images in CSS which makes srcset feel like a step backwards in this regard. Bear in mind, I’m not talking about selections of images based on pixel density, resolution, bandwidth, etc., which I will readily concede only the UA can make an intelligent decision abut. But instead selection of images based on decisions about what looks best at each breakpoint in a design which only the author can decide. -Jason [1] http://adactio.com/journal/5425/
Re: [whatwg] Features for responsive Web design
That's one of the major advantages of Adaptive Images (the PHP/JS
solution) and what people most like about it when they give me
feedback - it's all automatic with no custom HTML and it does all
image generation itself.
Yes, the vast majority of people who are going to put images into
websites are not web-developers but people using some CMS. The only
way these people are going to get multiple versions of the same image
is if the CMS can do it either automatically through re-sizing (as AI
does) or through providing upload fields for each breakpoint size.
The problem for end users (CMS users) is one of asset creation -
that's not a problem which can be solved by us in the scope of this
work - but we *do* need to consider this with whatever we end up
implementing. It is *highly* likely that the majority of use cases any
adaptive HTML mechanism will be applied to will have assets reference
through some automated image creation facility - as opposed to
hand-created.
That's why setting path variables is good. It's very likely that any
CMS is going to dump images into folders based on their fitting into a
design breakpoint: exactly as Adaptive Images does now. The number of
uses where people will manually create images at all sizes to
non-predictable paths are competitively tiny.
One-off responsiveness (one image element on a page, which is unique
in terms of adaption points) is where may be useful. For
general responsiveness, the meta variable method is much more
appropriate and efficient.
-Matt
On 15 May 2012 12:51, Shane Hudson wrote:
> I agree Matt. I have gone back to basics to define exactly what we are all
> needing and look to see if there are any ways we have not yet thought of.
>
> Ian's explaination of srcset makes me feel more comfortable with it than the
> original draft did, however I do believe it is the wrong way to go. There is
> a lot of repetition and very little room for expansion, the syntax also
> means that every img tag will look horrendous as more sizes develop.
>
> As I say, I am going to be writing a detailed reply shortly.
>
> I do have one question though… since the majority of images on the web are
> uploaded by general users (through the use of a CMS or image uploader such
> as flickr or Facebook), does anyone yet have a solution in which the user
> does not have to manually create the separate files? I may be missing
> something very simple here, but we do not want to be changing the user
> experience, a script will need to be able to convert a single image into the
> different sizes. I might be wrong in thinking a general image resizer would
> not work for this?
>
>
>
> Shane Hudson (Website Developer - www.ShaneHudson.net)
>
> 07794746595
>
> @ShaneHudson / +Shane Hudson
>
> On Tuesday, 15 May 2012 at 11:22, Matthew Wilcox wrote:
>
> I do not see much potential for srcset. The result of asking the
> author community was overwhelmingly negative, indirection or no
> indirection.
>
> To be clear, I don't see how indirection of this level can be an
> issue, under those terms anything you write in CSS to effect a HTML
> element is already "indirect" - to the extent of being in a different
> file entirely.
>
> -Matt
>
> On 15 May 2012 11:13, Matthew Wilcox wrote:
>
> Constraints on where assets are placed and named? I do not follow your
> reasoning here: You put them in the folder that's used for that design
> breakpoint:
>
> /anything/{whatever}/this/can/be/anything.jpg
>
> I've seen no objections about that aspect in the Community Group
> thread, where a number of authors have given feedback.
>
>
>
> It addresses pixel density because it uses media queries and they
> address pixel density. Any media query should be valid, so it's not
> just
>
>
>
> you could use
>
>
>
> for example. MQ are by far the most flexible way of dealing with
> reacting to device constraints.
>
> What is set is the path to look for the image. This is *exactly* how
> this works in CSS already for background-images and all authors are
> familiar with this - you don't set the pixel density of an image, you
> detect the device pixel density and change the path of the image you
> send over CSS. Have a look at how almost any site is built and you'll
> see *paths* change, not *image names*. http://enochs.co.uk is one
> example.
>
>
> Requiring access to head is not much of an issue, and has not been
> raised by anyone commenting on the CG thread. Web designs tend to be
> 3-7 breakpoints that are shared site-wide. The actual design of each
> page may not be, but the breakpoints are. This is why site's with many
> types of page can all share the same list of CSS assets to load:
>
>
>
>
>
> href="/assets/css/screen.320.css" />
> href="/assets/css/screen.480.css" />
> href="/assets/css/screen.750.css" />
> href="/assets/css/screen.960.css" />
>
> We are proposing nothing different than that, but to set variables
> rather than to load a particular CSS file.
>
> If it wo
Re: [whatwg] Features for responsive Web design
I do not see much potential for srcset. The result of asking the
author community was overwhelmingly negative, indirection or no
indirection.
To be clear, I don't see how indirection of this level can be an
issue, under those terms anything you write in CSS to effect a HTML
element is already "indirect" - to the extent of being in a different
file entirely.
-Matt
On 15 May 2012 11:13, Matthew Wilcox wrote:
> Constraints on where assets are placed and named? I do not follow your
> reasoning here: You put them in the folder that's used for that design
> breakpoint:
>
> /anything/{whatever}/this/can/be/anything.jpg
>
> I've seen no objections about that aspect in the Community Group
> thread, where a number of authors have given feedback.
>
>
>
> It addresses pixel density because it uses media queries and they
> address pixel density. Any media query should be valid, so it's not
> just
>
>
>
> you could use
>
>
>
> for example. MQ are by far the most flexible way of dealing with
> reacting to device constraints.
>
> What is set is the path to look for the image. This is *exactly* how
> this works in CSS already for background-images and all authors are
> familiar with this - you don't set the pixel density of an image, you
> detect the device pixel density and change the path of the image you
> send over CSS. Have a look at how almost any site is built and you'll
> see *paths* change, not *image names*. http://enochs.co.uk is one
> example.
>
>
> Requiring access to head is not much of an issue, and has not been
> raised by anyone commenting on the CG thread. Web designs tend to be
> 3-7 breakpoints that are shared site-wide. The actual design of each
> page may not be, but the breakpoints are. This is why site's with many
> types of page can all share the same list of CSS assets to load:
>
>
>
>
>
> href="/assets/css/screen.320.css" />
> href="/assets/css/screen.480.css" />
> href="/assets/css/screen.750.css" />
> href="/assets/css/screen.960.css" />
>
> We are proposing nothing different than that, but to set variables
> rather than to load a particular CSS file.
>
> If it works for authors using CSS, why should it not also work for
> setting image paths?
>
>
>
> -Matt
>
> On 15 May 2012 10:57, Anne van Kesteren wrote:
>> On Tue, May 15, 2012 at 11:38 AM, Matthew Wilcox
>> wrote:
>>> Please, have you taken a look at the latest idea?
>>>
>>> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
>>
>> It was quoted and replied to in the email you just replied to.
>>
>> It has many problems. It adds a level of indirection, it imposes
>> constraints on where the resources are located and how they are named,
>> it requires access to the element for adding an image in a blog
>> post, and it makes processing of URLs conditional on information
>> provided elsewhere. These are all significant issues.
>>
>> I also do not see how it addresses the pixel density use case. You
>> cannot use a media query for that because a media query queries the
>> pixel density of the device, it does not *set* the pixel density of
>> the resource.
>>
>>
>> --
>> Anne — Opera Software
>> http://annevankesteren.nl/
>> http://www.opera.com/
Re: [whatwg] Features for responsive Web design
Constraints on where assets are placed and named? I do not follow your
reasoning here: You put them in the folder that's used for that design
breakpoint:
/anything/{whatever}/this/can/be/anything.jpg
I've seen no objections about that aspect in the Community Group
thread, where a number of authors have given feedback.
It addresses pixel density because it uses media queries and they
address pixel density. Any media query should be valid, so it's not
just
you could use
for example. MQ are by far the most flexible way of dealing with
reacting to device constraints.
What is set is the path to look for the image. This is *exactly* how
this works in CSS already for background-images and all authors are
familiar with this - you don't set the pixel density of an image, you
detect the device pixel density and change the path of the image you
send over CSS. Have a look at how almost any site is built and you'll
see *paths* change, not *image names*. http://enochs.co.uk is one
example.
Requiring access to head is not much of an issue, and has not been
raised by anyone commenting on the CG thread. Web designs tend to be
3-7 breakpoints that are shared site-wide. The actual design of each
page may not be, but the breakpoints are. This is why site's with many
types of page can all share the same list of CSS assets to load:
We are proposing nothing different than that, but to set variables
rather than to load a particular CSS file.
If it works for authors using CSS, why should it not also work for
setting image paths?
-Matt
On 15 May 2012 10:57, Anne van Kesteren wrote:
> On Tue, May 15, 2012 at 11:38 AM, Matthew Wilcox
> wrote:
>> Please, have you taken a look at the latest idea?
>>
>> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
>
> It was quoted and replied to in the email you just replied to.
>
> It has many problems. It adds a level of indirection, it imposes
> constraints on where the resources are located and how they are named,
> it requires access to the element for adding an image in a blog
> post, and it makes processing of URLs conditional on information
> provided elsewhere. These are all significant issues.
>
> I also do not see how it addresses the pixel density use case. You
> cannot use a media query for that because a media query queries the
> pixel density of the device, it does not *set* the pixel density of
> the resource.
>
>
> --
> Anne — Opera Software
> http://annevankesteren.nl/
> http://www.opera.com/
Re: [whatwg] Features for responsive Web design
On Tue, May 15, 2012 at 11:38 AM, Matthew Wilcox wrote: > Please, have you taken a look at the latest idea? > > http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ It was quoted and replied to in the email you just replied to. It has many problems. It adds a level of indirection, it imposes constraints on where the resources are located and how they are named, it requires access to the element for adding an image in a blog post, and it makes processing of URLs conditional on information provided elsewhere. These are all significant issues. I also do not see how it addresses the pixel density use case. You cannot use a media query for that because a media query queries the pixel density of the device, it does not *set* the pixel density of the resource. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Features for responsive Web design
Please, have you taken a look at the latest idea?
http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
It solves many issues:
1) works with pre-fetch
2) is not verbose
3) is backward compatible with current browsers
4) is aimed for future-proofing - a re-design later with new or
different breakpoints would result in no edits to the mark-up
5) Avoids repetition and excessive processing of multiple media tests
I'd greatly appreciate more feedback on this approach at the Community Group.
Kind regards,
Matt Wilcox
On 15 May 2012 08:28, Ian Hickson wrote:
> On Wed, 25 Jan 2012, Matthew Wilcox wrote:
>> On 24 January 2012 23:26, Ian Hickson wrote:
>> > On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
>> > >
>> > > As we now have the possibility of creating fluid and responsive
>> > > layouts in several ways we have a problem with images.
>> > >
>> > > There's currently no good feature to implement something like
>> > > responsive images which adapt to the different device-resolutions.
>> > > We only can implement one image with one resolution scaling-up and
>> > > down.
>> >
>> > You can do adaptive sites using media queries.
>> >
>> >
>> > My Site
>> >
>> > // CSS
>> > @media (min-width: 320px and max-width: 640px) {
>> > h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
>> > }
>> > @media (min-width: 640px and max-width: 1024px) {
>> > h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
>> > }
>> > @media (min-width: 1024px) {
>> > h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
>> > }
>>
>> This is of no use to content images - which are the real problem. CSS
>> supplied images are not an issue.
>
> Fair enough.
>
>
> Looking at the feedback on these threads over the past few months (I
> didn't quote it all here, but thank you to everyone for making very good
> points, both here on the list and on numerous blog posts and documents on
> the Web, referenced from these threads), it seems there are three main
> axes that control what image one might want to use on a page, assuming
> that one is rendering to a graphical display:
>
> - the size of the viewport into which the image is being rendered
>
> - the pixel density of the display device
>
> - the network bandwidth available to the page to obtain resources
>
> Now I'm not sure what to do about the bandwidth one. It's very hard for a
> user agent to estimate its bandwidth availability -- it depends on the
> server, and the network location of the server, almost as much as on the
> location of the client; it depends on the current network congestion, it
> depends on the other things the browser is doing; it depends on whether
> the user is about to go through a tunnel or is about to switch to wifi; it
> depends on whether the user is roaming out of network or is on an OC48
> network pipe. It's hugely variable. It's not clear to me how to
> characterise it, either. It's also something that's changing very rapidly.
> On the more modern mobile networks, the real problem seems to be latency,
> not bandwidth; once you've actually kicked off a download, you can get the
> data very fast, it just takes forever to kick it off. That kind of problem
> is better solved by something like SPDY than by downloading smaller
> images. Downloading smaller images also screws up zooming images, which
> happens a lot more on mobile than on desktop.
>
> A number of people proposed solutions that are variants on the
> / mechanism, where you have an abundance of elements to
> replace the lonely . Looking at the examples of this, though, I could
> not get over how verbose the result is. If we're expecting this to be
> common -- which I think we are -- then really can't be asking authors to
> be providing dense collections of media queries, switch-statement like
> lists of URLs, and so forth, with each image.
>
> Nor can we ask authors to provide a default and then have an external CSS
> file give alternatives. The syntax is different (and in some proposals
> actually already possible today), but the fundamental problem still
> exists: it's way too much work for just inserting an image in a page.
>
> Another proposal that various people advocated is a header that the
> servers can use to determine what content to use. Besides a wide number of
> problems that people pointed out with this on the thread (such as the
> privacy issues due to fingerprinting, the many ways that such information
> gets abused, the high aggregate bandwidth cost, the difficulties with
> using headers in offline scenarios, etc), the biggest problem with this
> idea, IMHO, is that authors have shown that HTTP headers are simply a
> non-starter. Content-Type headers are perenially wrong, Accept headers are
> mishandled all over the place, adding Origin headers has caused
> compatibility issues... HTTP headers are a disaster. If there's ever an
> option t
[whatwg] Features for responsive Web design
On Wed, 25 Jan 2012, Matthew Wilcox wrote:
> On 24 January 2012 23:26, Ian Hickson wrote:
> > On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
> > >
> > > As we now have the possibility of creating fluid and responsive
> > > layouts in several ways we have a problem with images.
> > >
> > > There's currently no good feature to implement something like
> > > responsive images which adapt to the different device-resolutions.
> > > We only can implement one image with one resolution scaling-up and
> > > down.
> >
> > You can do adaptive sites using media queries.
> >
> >
> > My Site
> >
> > // CSS
> > @media (min-width: 320px and max-width: 640px) {
> > h1::before { content: url(http://cdn.url.com/img/myimage_xs.jpg) }
> > }
> > @media (min-width: 640px and max-width: 1024px) {
> > h1::before { content: url(http://cdn.url.com/img/myimage_m.jpg) }
> > }
> > @media (min-width: 1024px) {
> > h1::before { content: url(http://cdn.url.com/img/myimage_xsl.jpg) }
> > }
>
> This is of no use to content images - which are the real problem. CSS
> supplied images are not an issue.
Fair enough.
Looking at the feedback on these threads over the past few months (I
didn't quote it all here, but thank you to everyone for making very good
points, both here on the list and on numerous blog posts and documents on
the Web, referenced from these threads), it seems there are three main
axes that control what image one might want to use on a page, assuming
that one is rendering to a graphical display:
- the size of the viewport into which the image is being rendered
- the pixel density of the display device
- the network bandwidth available to the page to obtain resources
Now I'm not sure what to do about the bandwidth one. It's very hard for a
user agent to estimate its bandwidth availability -- it depends on the
server, and the network location of the server, almost as much as on the
location of the client; it depends on the current network congestion, it
depends on the other things the browser is doing; it depends on whether
the user is about to go through a tunnel or is about to switch to wifi; it
depends on whether the user is roaming out of network or is on an OC48
network pipe. It's hugely variable. It's not clear to me how to
characterise it, either. It's also something that's changing very rapidly.
On the more modern mobile networks, the real problem seems to be latency,
not bandwidth; once you've actually kicked off a download, you can get the
data very fast, it just takes forever to kick it off. That kind of problem
is better solved by something like SPDY than by downloading smaller
images. Downloading smaller images also screws up zooming images, which
happens a lot more on mobile than on desktop.
A number of people proposed solutions that are variants on the
/ mechanism, where you have an abundance of elements to
replace the lonely . Looking at the examples of this, though, I could
not get over how verbose the result is. If we're expecting this to be
common -- which I think we are -- then really can't be asking authors to
be providing dense collections of media queries, switch-statement like
lists of URLs, and so forth, with each image.
Nor can we ask authors to provide a default and then have an external CSS
file give alternatives. The syntax is different (and in some proposals
actually already possible today), but the fundamental problem still
exists: it's way too much work for just inserting an image in a page.
Another proposal that various people advocated is a header that the
servers can use to determine what content to use. Besides a wide number of
problems that people pointed out with this on the thread (such as the
privacy issues due to fingerprinting, the many ways that such information
gets abused, the high aggregate bandwidth cost, the difficulties with
using headers in offline scenarios, etc), the biggest problem with this
idea, IMHO, is that authors have shown that HTTP headers are simply a
non-starter. Content-Type headers are perenially wrong, Accept headers are
mishandled all over the place, adding Origin headers has caused
compatibility issues... HTTP headers are a disaster. If there's ever an
option to solve a problem without HTTP headers, we should take it, IMHO.
On Tue, 7 Feb 2012, Kornel LesiÅ~Dski wrote:
>
> You could just say "I've got these image sizes available, choose which
> one suits you best", and browser would pick one that makes most sense.
> You (and every other web developer) wouldn't have to write and maintain
> code for computation of bandwidth/latency/battery/screen
> size/density/zoom/cpu speed/memory tradeoffs. With so many variables I'm
> afraid that average developer wouldn't make better choices than mobile
> browsers themselves can.
Indeed.
One thing I noticed when looking at the proposals is that they all
conveyed a lot of information:
- a list of files, each
