Re: [whatwg] Features for responsive Web design
If it is really necessary to support this case then perhaps both the image width and the the native pixel breakpoints could be specified in the srcset. Then srcset=low.jpg 10w 20w, hi.jpg 20w 40w, huge.jpg 30w would mean: low.jpg is 10 pixels wide and use it if the native pixel width of the image box is less than or equal to 20, hi.jpg is 20 pixels wide and use it if the native pixel width of the image box is less than or equal to 40, huge.jpg is 30 pixels wide and use it if the native pixel width of the image box is less than greater than 40 pixles The default break points could be the image sizes, and would typically not be needed. The first image could be the 1x density image, allowing the browser to determine the image box size if not otherwise specified and this could be done before loading the image. This approach may be more natural for a fluid design. cheers Fred Date: Thu, 18 Oct 2012 08:31:57 +0200 From: i...@anselm-hannemann.com To: freda...@live.com CC: whatwg@lists.whatwg.org; odi...@opera.com Subject: Re: [whatwg] Features for responsive Web design Am Donnerstag, 18. Oktober 2012 um 04:05 schrieb Fred Andrews: This is good point. Could I just clarify my understanding with an example: Given a thumbnail image with srcset: srcset=low.jpg 20w, hi.jpg 40w, huge.jpg 80w The webpage may want to have the browser scale the 20w image to say 50px without the browser deciding that the 40w image is more appropriate? Perhaps it would be realistic for this case to simply not be supported. srcset cannot support this case. This is one case (of many) why we suggested picture-element. Authors have the alternative option of using an encoding with a lower quality to reduce the image file size, rather than supplying a low resolution image that the browser scales up. Perhaps when the file size is far more important than image quality a single image would suffice anyway. I don't think that is an answer for such a problem. It is how you would solve it today. Not how you want to solve it. Cheers -Anselm cheers Fred To: whatwg@lists.whatwg.org (mailto:whatwg@lists.whatwg.org) Date: Mon, 15 Oct 2012 18:40:21 +0200 From: odi...@opera.com (mailto:odi...@opera.com) Subject: Re: [whatwg] Features for responsive Web design On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst derer...@gmx.ch (mailto:derer...@gmx.ch) wrote: This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w What about an image gallery, when you have 25 thumbnails on one page? I'm not sure how this will work in cases where you don't want the image to be the max size your screen can handle. Even the common case of having an article picture that is not 100% of the screen width will be hard to do in a responsive non-fluid way with predefined breakpoints. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
Am Donnerstag, 18. Oktober 2012 um 04:05 schrieb Fred Andrews: This is good point. Could I just clarify my understanding with an example: Given a thumbnail image with srcset: srcset=low.jpg 20w, hi.jpg 40w, huge.jpg 80w The webpage may want to have the browser scale the 20w image to say 50px without the browser deciding that the 40w image is more appropriate? Perhaps it would be realistic for this case to simply not be supported. srcset cannot support this case. This is one case (of many) why we suggested picture-element. Authors have the alternative option of using an encoding with a lower quality to reduce the image file size, rather than supplying a low resolution image that the browser scales up. Perhaps when the file size is far more important than image quality a single image would suffice anyway. I don't think that is an answer for such a problem. It is how you would solve it today. Not how you want to solve it. Cheers -Anselm cheers Fred To: whatwg@lists.whatwg.org (mailto:whatwg@lists.whatwg.org) Date: Mon, 15 Oct 2012 18:40:21 +0200 From: odi...@opera.com (mailto:odi...@opera.com) Subject: Re: [whatwg] Features for responsive Web design On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst derer...@gmx.ch (mailto:derer...@gmx.ch) wrote: This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w What about an image gallery, when you have 25 thumbnails on one page? I'm not sure how this will work in cases where you don't want the image to be the max size your screen can handle. Even the common case of having an article picture that is not 100% of the screen width will be hard to do in a responsive non-fluid way with predefined breakpoints. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
This is good point. Could I just clarify my understanding with an example: Given a thumbnail image with srcset: srcset=low.jpg 20w, hi.jpg 40w, huge.jpg 80w The webpage may want to have the browser scale the 20w image to say 50px without the browser deciding that the 40w image is more appropriate? Perhaps it would be realistic for this case to simply not be supported. Authors have the alternative option of using an encoding with a lower quality to reduce the image file size, rather than supplying a low resolution image that the browser scales up. Perhaps when the file size is far more important than image quality a single image would suffice anyway. cheers Fred To: whatwg@lists.whatwg.org Date: Mon, 15 Oct 2012 18:40:21 +0200 From: odi...@opera.com Subject: Re: [whatwg] Features for responsive Web design On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst derer...@gmx.ch wrote: This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w What about an image gallery, when you have 25 thumbnails on one page? I'm not sure how this will work in cases where you don't want the image to be the max size your screen can handle. Even the common case of having an article picture that is not 100% of the screen width will be hard to do in a responsive non-fluid way with predefined breakpoints. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
On Thu, 11 Oct 2012 20:07:04 +0200, Markus Ernst derer...@gmx.ch wrote: This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w What about an image gallery, when you have 25 thumbnails on one page? I'm not sure how this will work in cases where you don't want the image to be the max size your screen can handle. Even the common case of having an article picture that is not 100% of the screen width will be hard to do in a responsive non-fluid way with predefined breakpoints. -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
From: m...@apple.com ... My point is, that any device-specific notation, such as 2x, forces the author to make decisions that the browser should actually make. The author does not know if in a few years the image will be viewed with 1.5x or 3x or 7x or whatever devices. This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w Where 200w is the actual image width and not the viewport width. Like that every browser can decide which source to load based on the display, and available bandwidth or user setting or whatever. The benefit of declaring a scale factor is that the browser can rescale each version of the image to be a consistent size in CSS pixels. Declaring the width of the image does not tell the browser how much that version should be scaled. The browser could guess based on ratios between the different specified widths, but it seems like that would make the problem you describe worse - the author would still have to understand device pixel densities but would only be able to specify them to the browser in a mysterious and indirect way. This does seem to be an important point. Would the follow be a correction understanding of your point: if there are a range of images each with a different declared size and the CSS pixel size of the image is not constrained then the browser must use the image pixel size to determine the CSS pixel size and without knowing the density then this can not be done uniquely? Perhaps the 1x density image could be placed first in the list, and then the densities would all be defined. Having the widths declared may have an advantage when the CSS pixel size of the image is known before the image is loaded because in this case the appropriate image can be determined without needing to load an image to read the size. Alternatively perhaps rather than interpreting the density multiplier as a media query, it could be viewed as a density scaling factor, with the 1x scaling image being the default hint for a 1x density display. The browser would then be free to choose to use any available image as necessary and may reload a different image if the image box size changes or upon zooming. Then again, perhaps I have misunderstood your point. For fluid design the elements are typically designed to adapt to the available size and having to include media query viewport widths in the srcset is equally problematic - a designer knows the images sizes but does not want to be thinking about the viewport widths. A fluid design would probably have little or no media queries based on the viewport width. cheers Fred
Re: [whatwg] Features for responsive Web design
On Sat, 2012-10-13 at 06:04 +, Fred Andrews wrote: From: m...@apple.com ... My point is, that any device-specific notation, such as 2x, forces the author to make decisions that the browser should actually make. The author does not know if in a few years the image will be viewed with 1.5x or 3x or 7x or whatever devices. This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w Where 200w is the actual image width and not the viewport width. Like that every browser can decide which source to load based on the display, and available bandwidth or user setting or whatever. The benefit of declaring a scale factor is that the browser can rescale each version of the image to be a consistent size in CSS pixels. Declaring the width of the image does not tell the browser how much that version should be scaled. The browser could guess based on ratios between the different specified widths, but it seems like that would make the problem you describe worse - the author would still have to understand device pixel densities but would only be able to specify them to the browser in a mysterious and indirect way. This does seem to be an important point. Would the follow be a correction understanding of your point: if there are a range of images each with a different declared size and the CSS pixel size of the image is not constrained then the browser must use the image pixel size to determine the CSS pixel size and without knowing the density then this can not be done uniquely? Perhaps the 1x density image could be placed first in the list, and then the densities would all be defined. Having the widths declared may have an advantage when the CSS pixel size of the image is known before the image is loaded because in this case the appropriate image can be determined without needing to load an image to read the size. Alternatively perhaps rather than interpreting the density multiplier as a media query, it could be viewed as a density scaling factor, with the 1x scaling image being the default hint for a 1x density display. The browser would then be free to choose to use any available image as necessary and may reload a different image if the image box size changes or upon zooming. Then again, perhaps I have misunderstood your point. For fluid design the elements are typically designed to adapt to the available size and having to include media query viewport widths in the srcset is equally problematic - a designer knows the images sizes but does not want to be thinking about the viewport widths. A fluid design would probably have little or no media queries based on the viewport width. cheers Fred Just using the image dimensions isn't enough to for a browser to determine what might be best used on a low bandwidth connection. A JPEG image of the same pixel size could be saved out with varying degrees of compression. This won't matter in the case of interlaced images (although that penalises higher bandwidth connections). One alternative would be to 'lie' to the srcset declaration by saying an image is a pixel or two shorter in one dimension to trick it into downloading the better resource. The other alternative might be to include a (rough) file size in the srcset declaration: srcset=low.jpg 200w 500B, hi.jpg 200w 1k, huge.jpg 200w 2k It does have a problem, namely that this sort of information isn't always known (a CMS that doesn't deal with images, images source via file repositories, images being updated after any HTML is created, etc) but in cases like that the file size could just be omitted (it is only a hint anyway). -- Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Features for responsive Web design
On Oct 11, 2012, at 11:07 AM, Markus Ernst derer...@gmx.ch wrote: Am 11.10.2012 18:36 schrieb Ian Hickson: On Thu, 11 Oct 2012, Markus Ernst wrote: IMHO as an author, the bandwidth use case is not solved in a future proof manner It's not solved at all. I didn't attempt to solve it. Before we can solve it, we need to figure out how to do so, as discussed here (search for bandwidth one): http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html It looks like my English is not perfectly understandable, I am sorry I am not a native English speaker. I did not try to state the use case was solved. I have been following the discussion in this list quite closely. My point is, that any device-specific notation, such as 2x, forces the author to make decisions that the browser should actually make. The author does not know if in a few years the image will be viewed with 1.5x or 3x or 7x or whatever devices. This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w Where 200w is the actual image width and not the viewport width. Like that every browser can decide which source to load based on the display, and available bandwidth or user setting or whatever. The benefit of declaring a scale factor is that the browser can rescale each version of the image to be a consistent size in CSS pixels. Declaring the width of the image does not tell the browser how much that version should be scaled. The browser could guess based on ratios between the different specified widths, but it seems like that would make the problem you describe worse - the author would still have to understand device pixel densities but would only be able to specify them to the browser in a mysterious and indirect way. - Maciej
Re: [whatwg] Features for responsive Web design
Am 10.10.2012 20:36 schrieb Ian Hickson: On Wed, 10 Oct 2012, Tim Kadlec wrote: That's actually exactly why it's better _not_ to plan for it. We can't design features for problems we don't understand. It's better to wait until we have real problems before fixing them. You may not be able to predict every future problem, but surely you need to keep it in mind as you create solutions for today, right? Sure, that's why for example the srcset= syntax is extensible and already supports arbitrary densities, not just 1x and 2x. Tim's objection does not only apply to the spec, but also to the code that can be written according to that spec. IMHO as an author, the bandwidth use case is not solved in a future proof manner, if I have to indicate pixel densities (or other device properties) that I serve images for, because I have no idea what devices will be available in a few years. I would have to change my code when new devices with other characteristics occur. I'd rather indicate some properties of the image files, such as pixel width or heigth, and/or KB size, and let the device resp. browser decide which one of the set it considers most appropriate for the browsing situation.
Re: [whatwg] Features for responsive Web design
On Thu, 11 Oct 2012, Mark Callow wrote: On 2012/10/10 12:29, Ian Hickson wrote: On Wed, 10 Oct 2012, Mark Callow wrote: I don't know what the browser on the SH-10D is doing, (It's running Android 4.0) but, given the physical size (4.5), if they were making the css pixels smaller, the content would be unreadable. I expect they are actually using 3x. Can you obtain a screenshot of this page in the device's browser? http://junkyard.damowmow.com/513 (Should be power+voldown to get a screen shot.) I don't have one of these phones. I went to the Docomo shop on the way home yesterday and was able to view the page on it but could not get or send a screenshot. Thanks for trying! The size of the black rectangle relative to the cats image looks slightly smaller than on my PC and I'd say the right edge of it is further to the left of the image than on my PC but overall the result is broadly similar. The ratio of the box to the image shouldn't change, what matters is the number of pixels in the screenshot that are used to actualy drow the box. Regular text on web pages is very small. It really isn't practical to read it without zooming in. So I suspect they are using 2x thus making CSS pixels smaller. There's probably a certain amount of chicken egg here. How much content would break on devices with a 3:1 device:css ratio? That concern probably stops device makers setting 3x even when they really should. There's no compatibility risk with changing the density ratio; the only risk is that images on pages look a bit more fuzzy, but that happens with 2x anyway, so moving to 3x doesn't affect that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Features for responsive Web design
On Thu, 11 Oct 2012, Markus Ernst wrote: IMHO as an author, the bandwidth use case is not solved in a future proof manner It's not solved at all. I didn't attempt to solve it. Before we can solve it, we need to figure out how to do so, as discussed here (search for bandwidth one): http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Features for responsive Web design
On Oct 11, 2012, at 12:36 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 11 Oct 2012, Markus Ernst wrote: IMHO as an author, the bandwidth use case is not solved in a future proof manner It's not solved at all. I didn't attempt to solve it. Before we can solve it, we need to figure out how to do so, as discussed here (search for bandwidth one): http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html The RICG has proposed a solution to dealing with the overarching issue of bandwidth; it’s described in the following post: http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ In the interest of keeping relevant information on the list, I’ll repost the relevant section here: It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms. I feel that bandwidth decisions are best left to the browser. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this. In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. srcset affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes.
Re: [whatwg] Features for responsive Web design
On Thu, 11 Oct 2012, Mathew Marquis wrote: On Oct 11, 2012, at 12:36 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 11 Oct 2012, Markus Ernst wrote: IMHO as an author, the bandwidth use case is not solved in a future proof manner It's not solved at all. I didn't attempt to solve it. Before we can solve it, we need to figure out how to do so, as discussed here (search for bandwidth one): http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html The RICG has proposed a solution to dealing with the overarching issue of bandwidth; it’s described in the following post: http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ In the interest of keeping relevant information on the list, I’ll repost the relevant section here: It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms. I feel that bandwidth decisions are best left to the browser. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this. In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. srcset affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes. How does this address the points in the e-mail I cited above? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Features for responsive Web design
On Oct 11, 2012, at 1:10 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 11 Oct 2012, Mathew Marquis wrote: On Oct 11, 2012, at 12:36 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 11 Oct 2012, Markus Ernst wrote: IMHO as an author, the bandwidth use case is not solved in a future proof manner It's not solved at all. I didn't attempt to solve it. Before we can solve it, we need to figure out how to do so, as discussed here (search for bandwidth one): http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html The RICG has proposed a solution to dealing with the overarching issue of bandwidth; it’s described in the following post: http://www.w3.org/community/respimg/2012/06/18/florians-compromise/ In the interest of keeping relevant information on the list, I’ll repost the relevant section here: It would assume a great deal if authors were to make this decision for the users. It would add a point of failure: we would be taking the bandwidth information afforded us by the browser, and selectively applying that information. Some of us may do it wrong; some of us may find ourselves forced to make a decision as to whether we account for users with limited bandwidth or not. To not account for it would be, in my opinion, untenable — I’ve expressed that elsewhere, in no uncertain terms. I feel that bandwidth decisions are best left to the browser. The decision to download high vs. standard resolution images should be made by user agents, depending on the bandwidth available — and further, I believe there should be a user settable preference for “always use standard resolution images,” “always use high resolution images,” ”download high resolution as bandwidth permits,” and so on. This is the responsibility of browser implementors, and they largely seem to be in agreement on this. In discussing the final markup pattern, we have to consider the above. Somewhere, that markup is going to contain a suggestion, rather than an imperative. srcset affords us that opportunity: a new syntax _designed_ to be treated as such. I wouldn’t want to introduce that sort of variance to the media query spec — a syntax long established as a set of absolutes. How does this address the points in the e-mail I cited above? Where you were stating that you personally had yet to propose a solution to the issue of bandwidth, I thought it might bear mentioning that there has been a fair amount of discussion around the issue. I apologize if I’ve diverged too far from the original topic.
Re: [whatwg] Features for responsive Web design
Am 11.10.2012 18:36 schrieb Ian Hickson: On Thu, 11 Oct 2012, Markus Ernst wrote: IMHO as an author, the bandwidth use case is not solved in a future proof manner It's not solved at all. I didn't attempt to solve it. Before we can solve it, we need to figure out how to do so, as discussed here (search for bandwidth one): http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html It looks like my English is not perfectly understandable, I am sorry I am not a native English speaker. I did not try to state the use case was solved. I have been following the discussion in this list quite closely. My point is, that any device-specific notation, such as 2x, forces the author to make decisions that the browser should actually make. The author does not know if in a few years the image will be viewed with 1.5x or 3x or 7x or whatever devices. This is why I'd humbly suggest to put information on the image in @srcset rather than info on the device and media. Such as: srcset=low.jpg 200w, hi.jpg 400w, huge.jpg 800w Where 200w is the actual image width and not the viewport width. Like that every browser can decide which source to load based on the display, and available bandwidth or user setting or whatever.
Re: [whatwg] Features for responsive Web design
On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 9 Oct 2012, Mark Callow wrote: On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Can you elaborate? How many device pixels per CSS pixel do browsers on those devices use? Are they just making CSS pixels smaller, or are they actually using 3x? http://www.zdnet.com/google-nexus-10-tablet-to-have-higher-res-display-than-ipad-705466/ appears to be 299dpi http://www.iclarified.com/entry/index.php?enid=3 appears to be 440dpi These devices aren't out yet, but I suspect browsers would be more-or-less as high-dpi as possible. This page lists several devices with physical DPI higher than 288 (3x the nominal CSS dpi) but none with a CSS pixel ratio greater than 2x. (To be fair, the data is incomplete and may be inaccurate, though to my knowledge the entries for Apple devices are all correct). So it's not a given that the cited hardware dpi values would lead to higher CSS pixel ratios in the corresponding software. Regards, Maciej
Re: [whatwg] Features for responsive Web design
On Oct 10, 2012, at 4:14 AM, Maciej Stachowiak m...@apple.com wrote: On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 9 Oct 2012, Mark Callow wrote: On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Can you elaborate? How many device pixels per CSS pixel do browsers on those devices use? Are they just making CSS pixels smaller, or are they actually using 3x? http://www.zdnet.com/google-nexus-10-tablet-to-have-higher-res-display-than-ipad-705466/ appears to be 299dpi http://www.iclarified.com/entry/index.php?enid=3 appears to be 440dpi These devices aren't out yet, but I suspect browsers would be more-or-less as high-dpi as possible. This page lists several devices with physical DPI higher than 288 (3x the nominal CSS dpi) but none with a CSS pixel ratio greater than 2x. (To be fair, the data is incomplete and may be inaccurate, though to my knowledge the entries for Apple devices are all correct). So it's not a given that the cited hardware dpi values would lead to higher CSS pixel ratios in the corresponding software. No, but we do know that things are continuing to trend towards higher PPI displays, and that at some point that may lead to a higher CSS pixel ratio. As a member of the jQuery Mobile project I’ve seen this for myself with the test devices we’re receiving constantly—every new screen is sharper than the last. In fairness, no, we can’t predict the future one way or the other. That’s exactly why it’s better to plan for it than not.
Re: [whatwg] Features for responsive Web design
On Wed, 10 Oct 2012, Mathew Marquis wrote: In fairness, no, we can’t predict the future one way or the other. That’s exactly why it’s better to plan for it than not. That's actually exactly why it's better _not_ to plan for it. We can't design features for problems we don't understand. It's better to wait until we have real problems before fixing them. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Features for responsive Web design
That's actually exactly why it's better _not_ to plan for it. We can't design features for problems we don't understand. It's better to wait until we have real problems before fixing them. You may not be able to predict every future problem, but surely you need to keep it in mind as you create solutions for today, right? For example, if all it takes is one higher resolution or one more feature to come along before a solution becomes unwieldy doesn't that imply the solution isn't a particularly strong one and is instead merely a stopgap? We can't be too bold with our predictions, but we do have to build with the future in mind or else condemn ourselves to a perpetual game of catch-up. Take care, Tim - http://twitter.com/tkadlec http://timkadlec.com http://implementingresponsivedesign.com
Re: [whatwg] Features for responsive Web design
On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Features for responsive Web design
On Tue, 9 Oct 2012, Mark Callow wrote: On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Can you elaborate? How many device pixels per CSS pixel do browsers on those devices use? Are they just making CSS pixels smaller, or are they actually using 3x? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Features for responsive Web design
On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 9 Oct 2012, Mark Callow wrote: On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Can you elaborate? How many device pixels per CSS pixel do browsers on those devices use? Are they just making CSS pixels smaller, or are they actually using 3x? http://www.zdnet.com/google-nexus-10-tablet-to-have-higher-res-display-than-ipad-705466/ appears to be 299dpi http://www.iclarified.com/entry/index.php?enid=3 appears to be 440dpi These devices aren't out yet, but I suspect browsers would be more-or-less as high-dpi as possible. ~TJ
Re: [whatwg] Features for responsive Web design
On 2012/10/10 6:49, Tab Atkins Jr. wrote: On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 9 Oct 2012, Mark Callow wrote: On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) With the current displays, it's just not that big a deal, IMHO. If by 3x you mean displays whose dpi is 3x that of CSS pixels (96dpi), they already exist in retail products. I saw 2 last week. Can you elaborate? How many device pixels per CSS pixel do browsers on those devices use? Are they just making CSS pixels smaller, or are they actually using 3x? http://www.zdnet.com/google-nexus-10-tablet-to-have-higher-res-display-than-ipad-705466/ appears to be 299dpi One of the devices I saw last week is a 10 display with 299dpi; I strongly suspect it is the one that will be used in this Nexus tablet. The other device is already on sale. A Sharp SH-10D smartphone sold by NTT Docomo. It has a 329 dpi display. http://www.iclarified.com/entry/index.php?enid=3 appears to be 440dpi These devices aren't out yet, but I suspect browsers would be more-or-less as high-dpi as possible. I don't know what the browser on the SH-10D is doing, (It's running Android 4.0) but, given the physical size (4.5), if they were making the css pixels smaller, the content would be unreadable. I expect they are actually using 3x. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Features for responsive Web design
Some of the e-mails on this thread were cross-posted to multiple mailing lists. Please remember not to cross-post when posting to this list. On Wed, 5 Sep 2012, Fred Andrews wrote: I have always been comfortable with the 'x' part of srcset, but the w and h part felt somewhat wrong to me. What you'd really want to consider when deciding which image to pick isn't the size of the viewport itself, but the size available for the image once the rest of the layout is taken into account. Yeah. That's how I originally designed srcset=, actually, but it was pointed out to me that that's impossible to implement because at the time the browsers need to pick an image, they haven't yet gotten the style sheet so they don't know what the layout will be. (Note that the media-query-based solutions have the same problem.) If people are really concerned about this latency then they can inline the style so that the image layout size is known before other resources are available Browser vendors don't seem emenable to this design, unfortunately. (Without good reason; it turns out that the people who care about latency are more often the users than Web authors -- Web authors often do things that are unnecessarily slow.) - this may just be the image CSS pixel size and many of these proposals require this to be included anyway. It will also help with backwards compatibility to have the style available. For example: img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The dimensions here are in image pixels, not CSS pixels. The set would include the 'src' image to give the declared image pixel size. The byte size and perhaps height could be optional. Inlining the style here doesn't help. You don't know how many pixels em means at the time of parsing. In other cases, browsers could either delay loading the image or lookup the 'src' image in the set to obtain the declared image pixel size and use this to speculatively load an image (once the image viewport size is finalized the browser could then decide if a higher resolution image is needed and load it then if necessary). Browsers will need to be prepared to reload a higher resolution image anyway in case of zooming in. Zooming in post-load is a rare case compared to the case of an image being sized differently, though. On Wed, 22 Aug 2012, John Mellor wrote: ... So for example 1280.jpg 4x means that this image is 4 times larger than the given intrinsic width of 320px. So sure, it would be suitable for display on a hypothetical 4x display at 320px width; but the browser also knows that it would be suitable for display on a 2x display at 640px width, a 1.5x display at 853px width, and a 1x display at 1280px width. This isn't accurate. A trivial example of it not being accurate is a 1000 device pixel image that consists of a horiontal double-headed arrow labeled Five Hundred CSS Pixels. That image is _only_ applicable in a 500 CSS pixel double-density environment. If you sed it in a 250 CSS pixel quad-density environment, it would be wrong. This example may miss the point. If an image is to be scaled to 500 CSS pixels then this can be specified independently of the image pixel dimensions. The browser may even decide to download a much smaller image that is labeled Five Hundred CSS Pixels and scale it to the require CSS pixel size for the benefit of low bandwidth devices. Having both features seems like a lot of complexity. It's not clear to me that it is needed in practice. The art direction use case can be entirely orthogonal. It should be handled with the w/h descriptors as currently specified. What I'm proposing would operate after any w/h descriptors have narrowed down the set of allowable images, and let the browser choose between the remaining images more intelligently in the case of flexible-size images, where currently the browser has no idea which to use. Could you give a real example of this kind of thing? I'd love to study what kinds of images we're talking about here. None of the examples people posted when we were designing srcset= were like this. Here's an example of a webpage with images that scale and for which the aspect ratio of the image frame changes fluidly to fit the window width: http://london.msn.co.uk/ That's an interesting page design, thanks. For this one you really want the image whose dot width is the _device_ CSS pixel width multiplied by the device density, assuming you don't care about zooming, but do care about resizing. If you care about zooming more than latency, you really just want the highest-res image. In practice you'd probably have a medium-size image for legacy cases, a low-size image for phones, and a high-size image for high-density big devices,
Re: [whatwg] Features for responsive Web design
On Oct 5, 2012, at 6:09 PM, Ian Hickson i...@hixie.ch wrote: Some of the e-mails on this thread were cross-posted to multiple mailing lists. Please remember not to cross-post when posting to this list. On Wed, 5 Sep 2012, Fred Andrews wrote: I have always been comfortable with the 'x' part of srcset, but the w and h part felt somewhat wrong to me. What you'd really want to consider when deciding which image to pick isn't the size of the viewport itself, but the size available for the image once the rest of the layout is taken into account. Yeah. That's how I originally designed srcset=, actually, but it was pointed out to me that that's impossible to implement because at the time the browsers need to pick an image, they haven't yet gotten the style sheet so they don't know what the layout will be. (Note that the media-query-based solutions have the same problem.) If people are really concerned about this latency then they can inline the style so that the image layout size is known before other resources are available Browser vendors don't seem emenable to this design, unfortunately. (Without good reason; it turns out that the people who care about latency are more often the users than Web authors -- Web authors often do things that are unnecessarily slow.) - this may just be the image CSS pixel size and many of these proposals require this to be included anyway. It will also help with backwards compatibility to have the style available. For example: img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The dimensions here are in image pixels, not CSS pixels. The set would include the 'src' image to give the declared image pixel size. The byte size and perhaps height could be optional. Inlining the style here doesn't help. You don't know how many pixels em means at the time of parsing. In other cases, browsers could either delay loading the image or lookup the 'src' image in the set to obtain the declared image pixel size and use this to speculatively load an image (once the image viewport size is finalized the browser could then decide if a higher resolution image is needed and load it then if necessary). Browsers will need to be prepared to reload a higher resolution image anyway in case of zooming in. Zooming in post-load is a rare case compared to the case of an image being sized differently, though. On Wed, 22 Aug 2012, John Mellor wrote: ... So for example 1280.jpg 4x means that this image is 4 times larger than the given intrinsic width of 320px. So sure, it would be suitable for display on a hypothetical 4x display at 320px width; but the browser also knows that it would be suitable for display on a 2x display at 640px width, a 1.5x display at 853px width, and a 1x display at 1280px width. This isn't accurate. A trivial example of it not being accurate is a 1000 device pixel image that consists of a horiontal double-headed arrow labeled Five Hundred CSS Pixels. That image is _only_ applicable in a 500 CSS pixel double-density environment. If you sed it in a 250 CSS pixel quad-density environment, it would be wrong. This example may miss the point. If an image is to be scaled to 500 CSS pixels then this can be specified independently of the image pixel dimensions. The browser may even decide to download a much smaller image that is labeled Five Hundred CSS Pixels and scale it to the require CSS pixel size for the benefit of low bandwidth devices. Having both features seems like a lot of complexity. It's not clear to me that it is needed in practice. The art direction use case can be entirely orthogonal. It should be handled with the w/h descriptors as currently specified. What I'm proposing would operate after any w/h descriptors have narrowed down the set of allowable images, and let the browser choose between the remaining images more intelligently in the case of flexible-size images, where currently the browser has no idea which to use. Could you give a real example of this kind of thing? I'd love to study what kinds of images we're talking about here. None of the examples people posted when we were designing srcset= were like this. Here's an example of a webpage with images that scale and for which the aspect ratio of the image frame changes fluidly to fit the window width: http://london.msn.co.uk/ That's an interesting page design, thanks. For this one you really want the image whose dot width is the _device_ CSS pixel width multiplied by the device density, assuming you don't care about zooming, but do care about resizing. If you care about zooming more than latency, you really just want the highest-res image. In practice you'd probably have a medium-size image for legacy cases, a low-size image for phones, and a
Re: [whatwg] Features for responsive Web design
On Sep 5, 2012, at 12:07 AM, Fred Andrews freda...@live.com wrote: ... I have always been comfortable with the 'x' part of srcset, but the w and h part felt somewhat wrong to me. What you'd really want to consider when deciding which image to pick isn't the size of the viewport itself, but the size available for the image once the rest of the layout is taken into account. Yeah. That's how I originally designed srcset=, actually, but it was pointed out to me that that's impossible to implement because at the time the browsers need to pick an image, they haven't yet gotten the style sheet so they don't know what the layout will be. (Note that the media-query-based solutions have the same problem.) If people are really concerned about this latency then they can inline the style so that the image layout size is known before other resources are available - this may just be the image CSS pixel size and many of these proposals require this to be included anyway. That's not really a viable solution. Many authors take little care i making their pages load fast, but browser implementors still consider it important to load them fast. It will also help with backwards compatibility to have the style available. For example: img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The dimensions here are in image pixels, not CSS pixels. The set would include the 'src' image to give the declared image pixel size. The byte size and perhaps height could be optional. The layout size of that img element is not computable until all external stylesheets have loaded, as you have written it. In other cases, browsers could either delay loading the image or lookup the 'src' image in the set to obtain the declared image pixel size and use this to speculatively load an image (once the image viewport size is finalized the browser could then decide if a higher resolution image is needed and load it then if necessary).Browsers will need to be prepared to reload a higher resolution image anyway in case of zooming in. Speculatively loading the wrong image does not strike me as an implementation approach that we'd be interested in. Page loading performance is very important to users, and therefore to browser implementors. I think it's important to avoid defeating important existing optimizations when adding new features. Regards, Maciej
Re: [whatwg] Features for responsive Web design
From: m...@apple.com ... I have always been comfortable with the 'x' part of srcset, but the w and h part felt somewhat wrong to me. What you'd really want to consider when deciding which image to pick isn't the size of the viewport itself, but the size available for the image once the rest of the layout is taken into account. Yeah. That's how I originally designed srcset=, actually, but it was pointed out to me that that's impossible to implement because at the time the browsers need to pick an image, they haven't yet gotten the style sheet so they don't know what the layout will be. (Note that the media-query-based solutions have the same problem.) If people are really concerned about this latency then they can inline the style so that the image layout size is known before other resources are available - this may just be the image CSS pixel size and many of these proposals require this to be included anyway. That's not really a viable solution. Many authors take little care i making their pages load fast, but browser implementors still consider it important to load them fast. Yes, the load time is important, and if the images is chosen based only on media queries than it can be loaded immediately. However the loaded images may not be an appropriate resolution - too small with not enough detail or too larger slowing page load. It will also help with backwards compatibility to have the style available. For example: img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The dimensions here are in image pixels, not CSS pixels. The set would include the 'src' image to give the declared image pixel size. The byte size and perhaps height could be optional. The layout size of that img element is not computable until all external stylesheets have loaded, as you have written it. Actually, the image width is '10em' in this example, without having to load any style sheets! The browser can immediately determine the image to use and load it in this particular case. I understand your point though. The layout size of the img element can even change after loading all resources as the user zooms or interacts with the content. Currently there is only one image choice, and it may be too large which would delay loading or too small and lack detail. The latency caused by style sheet loading is something accepted long ago. Pages that need the faster load times, such as landing pages, are going to inline the style, and perhaps even images. Websites for which visitors are expected to browse many pages would have common style sheets that would be cached and available immediately after the first visit. In other cases, browsers could either delay loading the image or lookup the 'src' image in the set to obtain the declared image pixel size and use this to speculatively load an image (once the image viewport size is finalized the browser could then decide if a higher resolution image is needed and load it then if necessary).Browsers will need to be prepared to reload a higher resolution image anyway in case of zooming in. Speculatively loading the wrong image does not strike me as an implementation approach that we'd be interested in. Page loading performance is very important to users, and therefore to browser implementors. I think it's important to avoid defeating important existing optimizations when adding new features. Consider that it will give the layout engine the image size before the images are loaded, because the sizes are declared inline. This could significantly reduce layout delays. Knowing the layout earlier could help make better decisions about image load order. Further, the layout engine may well be able to load a smaller lower resolution images, reducing load times. Page load times could be faster than they currently are by firstly loading the lowest resolution images - and it would even be more practical to inline these in data: URLs. Users may well prefer to have pages load faster with low resolution images and accept the delay waiting to higher resolution images to load. There do appear to be opportunities to achieve even faster page load times, and a better user experience. Perhaps you could take another look at the issues and opportunities. cheers Fred
Re: [whatwg] Features for responsive Web design
Fred Andrews writes: From: m...@apple.com img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The layout size of that img element is not computable until all external stylesheets have loaded, as you have written it. Actually, the image width is '10em' in this example, without having to load any style sheets! And how big is 10em? 1em is dependent on the font-size of the parent element of the img, which may be set by an external style-sheet. The browser can immediately determine the image to use and load it in this particular case. You see how easy it would be for authors to get this wrong, even if they knew they had to put image sizes in-line in order to have good performance and tried to do that. That you, the promoter of the feature, can't even get it right suggests that it would also be hard for authors to do so. Cheers Smylers -- New series of TV puzzle show 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/onlyconnect
Re: [whatwg] Features for responsive Web design
From: smyl...@stripey.com ... img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The layout size of that img element is not computable until all external stylesheets have loaded, as you have written it. Actually, the image width is '10em' in this example, without having to load any style sheets! And how big is 10em? 1em is dependent on the font-size of the parent element of the img, which may be set by an external style-sheet. Good point, thanks. But I don't think this weakens any of the technical points. Having the image sizes declared inline can only help speed the layout computation and allows the browser to use higher resolution images when needed. The browser can immediately determine the image to use and load it in this particular case. You see how easy it would be for authors to get this wrong, even if they knew they had to put image sizes in-line in order to have good performance and tried to do that. That you, the promoter of the feature, can't even get it right suggests that it would also be hard for authors to do so. If authors can get the URL right then they can get the sizes right. Web browser developer tools could warn if a mismatch is found - which is not something that could be done to correct incorrect media queries. There is likely a better syntax, and there have been lots of ideas proposed. John Mellor proposed the syntax: img srcset=320x120, 320.jpg 1x, 640.jpg 2x, 1280.jpg 4x, 2560.jpg 8x which has less values and thus less opportunity for user error. Would this help? If you have a better proposal to address the issue then please put it forward? Note that media queries can not solve this problem because the image layout size depends on styling, but media queries should be usable with any solution. cheers Fred
Re: [whatwg] Features for responsive Web design
On Sep 6, 2012, at 7:26 AM, Simon Pieters wrote:
On Wed, 05 Sep 2012 19:45:41 +0200, Mathew Marquis m...@matmarquis.com
wrote:
I can say for my own part: manipulating strings is far more difficult than
manipulating the value of individual attributes. It’s hard to imagine a
situation where I’d prefer to muck through a space/comma separated string
rather than a set of independent elements and attributes. Unless the plan is
to include an API similar to classList, though it would then be occupied by
a set of strings describing disparate information.
The implementation complexity for multiple elements is much greater compared
to an attribute (or even several attributes, so long as it's just one
element) plus an API. See
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035784.html and
search for it doesn't involve multiple elements. in
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html
for why.
Given `srcset=img2.jpg 2x 300w, img3.jpg 600w 2x`, I can only envision a
classList-style API returning something like one of the following:
1) [ img2.jpg, 2x, 300w, img3.jpg, 600w, 2x ]
This obviously isn’t ideal where authors will have no idea what information
is being manipulated without keeping constant tabs on the current index as
compared to the string in the markup. Even if the order of these separate
concerns were normalized, the inclusion or omission of any individual aspect
of a rule would mean a flurry of `console.log`s in order to figure out which
index represented which concern — or careful counting of spaces in one’s
markup, which certainly seems error-prone to me. I know I would certainly
make mistakes, there.
2) [ img2.jpg 2x 300w, img3.jpg 600w 2x ]
We’re still left parsing space-seperated strings for relevant information,
albeit smaller ones.
3) [ { src:img2.jpg, x:2, w:300 }, { src:img3.jpg, x:2, w:600 } ]
Except as host objects so that setting the properties actually updates the
attribute. (src= can also be exposed in the same API.)
I don’t feel there’s much of a case to be made in favor of writing regular
expressions to parse and manipulate strings, rather than manipulating
elements and attributes — though, as always, I’m happy to reach out to the
author community and ask. If I’m completely off-base here — and I may well
be — I’d certainly be interested in reading more about the plans for an API.
(3) above doesn't need regexps.
After a quick read through the existing spec for `source`, it seems we wouldn’t
be forced to manipulate `source` elements and attributes themselves in order to
reevaluate the most appropriate `source` for a given `picture` element. We
would instead be setting the `src` on the `picture` element itself.
http://dev.w3.org/html5/spec/single-page.html#the-source-element
Given the parity between JavaScript’s `matchMedia` and `media` attributes, and
given `devicePixelRatio` for determining the appropriate resolution, it would
make it simple to determine the most appropriate source before setting it on
the `picture` element: then, we need only access one element in the DOM, set a
relevant value within a single attribute, and we’re finished. This makes
_setting_ values an equally trivial task with either solution—though if the
author is inclined towards making layout decisions based on `em`s (an
increasingly common practice), those values will have to be converted to
pixel-based values in order to work with the extended `srcset` syntax.
In terms of retrieving information from either element, the previous discussion
stands: we’re left parsing a single string or tapping into a highly-specific
API attached to `img` in the case of the extended `srcset` syntax, or accessing
standalone elements and attributes in the case of `picture`. The latter
certainly seems easier from an authorship perspective; I’m curious as to how
much more complication is involved in implementing an API on `img`, to cater to
the extended `srcset.`
--
Simon Pieters
Opera Software
Re: [whatwg] Features for responsive Web design
On Wed, 05 Sep 2012 19:45:41 +0200, Mathew Marquis m...@matmarquis.com
wrote:
I can say for my own part: manipulating strings is far more difficult
than manipulating the value of individual attributes. It’s hard to
imagine a situation where I’d prefer to muck through a space/comma
separated string rather than a set of independent elements and
attributes. Unless the plan is to include an API similar to classList,
though it would then be occupied by a set of strings describing
disparate information.
The implementation complexity for multiple elements is much greater
compared to an attribute (or even several attributes, so long as it's just
one element) plus an API. See
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035784.html
and search for it doesn't involve multiple elements. in
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0070.html
for why.
Given `srcset=img2.jpg 2x 300w, img3.jpg 600w 2x`, I can only envision
a classList-style API returning something like one of the following:
1) [ img2.jpg, 2x, 300w, img3.jpg, 600w, 2x ]
This obviously isn’t ideal where authors will have no idea what
information is being manipulated without keeping constant tabs on the
current index as compared to the string in the markup. Even if the order
of these separate concerns were normalized, the inclusion or omission of
any individual aspect of a rule would mean a flurry of `console.log`s in
order to figure out which index represented which concern — or careful
counting of spaces in one’s markup, which certainly seems error-prone to
me. I know I would certainly make mistakes, there.
2) [ img2.jpg 2x 300w, img3.jpg 600w 2x ]
We’re still left parsing space-seperated strings for relevant
information, albeit smaller ones.
3) [ { src:img2.jpg, x:2, w:300 }, { src:img3.jpg, x:2, w:600 } ]
Except as host objects so that setting the properties actually updates the
attribute. (src= can also be exposed in the same API.)
I don’t feel there’s much of a case to be made in favor of writing
regular expressions to parse and manipulate strings, rather than
manipulating elements and attributes — though, as always, I’m happy to
reach out to the author community and ask. If I’m completely off-base
here — and I may well be — I’d certainly be interested in reading more
about the plans for an API.
(3) above doesn't need regexps.
--
Simon Pieters
Opera Software
Re: [whatwg] Features for responsive Web design
... I have always been comfortable with the 'x' part of srcset, but the w and h part felt somewhat wrong to me. What you'd really want to consider when deciding which image to pick isn't the size of the viewport itself, but the size available for the image once the rest of the layout is taken into account. Yeah. That's how I originally designed srcset=, actually, but it was pointed out to me that that's impossible to implement because at the time the browsers need to pick an image, they haven't yet gotten the style sheet so they don't know what the layout will be. (Note that the media-query-based solutions have the same problem.) If people are really concerned about this latency then they can inline the style so that the image layout size is known before other resources are available - this may just be the image CSS pixel size and many of these proposals require this to be included anyway. It will also help with backwards compatibility to have the style available. For example: img style=width: 10em src=image-320x200.jpg set=image-320x200.jpg 320 200 10k, image-640x400.jpg 640 400 40k, image-1280x800.jpg 1280 800 150k The dimensions here are in image pixels, not CSS pixels. The set would include the 'src' image to give the declared image pixel size. The byte size and perhaps height could be optional. In other cases, browsers could either delay loading the image or lookup the 'src' image in the set to obtain the declared image pixel size and use this to speculatively load an image (once the image viewport size is finalized the browser could then decide if a higher resolution image is needed and load it then if necessary).Browsers will need to be prepared to reload a higher resolution image anyway in case of zooming in. Because of that, I was interested in proposals involving an (optional) defer attribute, which let you wait until layout can inform the decision. Then, given accurate meta-data on the images's sizes and density, it would be possible to pick the optimum one. But of course, this means waiting, so this isn't generally acceptable and must be opt it. And I can't put my finger on exactly how that would work either. If this is something people want to do, it's easy enough to script. If it turns out that people are often trading the performance for this effect, we can definitely look into adding it as a supported feature, but I think (or rather, browser vendors seem to think) it's more likely that the performance matters more than the convenience. This does seem like a good complementary idea. Perhaps it should be only a hint and not restrict browsers from speculate loading an image. ... On Wed, 22 Aug 2012, John Mellor wrote: ... So for example 1280.jpg 4x means that this image is 4 times larger than the given intrinsic width of 320px. So sure, it would be suitable for display on a hypothetical 4x display at 320px width; but the browser also knows that it would be suitable for display on a 2x display at 640px width, a 1.5x display at 853px width, and a 1x display at 1280px width. This isn't accurate. A trivial example of it not being accurate is a 1000 device pixel image that consists of a horiontal double-headed arrow labeled Five Hundred CSS Pixels. That image is _only_ applicable in a 500 CSS pixel double-density environment. If you sed it in a 250 CSS pixel quad-density environment, it would be wrong. This example may miss the point. If an image is to be scaled to 500 CSS pixels then this can be specified independently of the image pixel dimensions. The browser may even decide to download a much smaller image that is labeled Five Hundred CSS Pixels and scale it to the require CSS pixel size for the benefit of low bandwidth devices. ... The art direction use case can be entirely orthogonal. It should be handled with the w/h descriptors as currently specified. What I'm proposing would operate after any w/h descriptors have narrowed down the set of allowable images, and let the browser choose between the remaining images more intelligently in the case of flexible-size images, where currently the browser has no idea which to use. Could you give a real example of this kind of thing? I'd love to study what kinds of images we're talking about here. None of the examples people posted when we were designing srcset= were like this. Here's an example of a webpage with images that scale and for which the aspect ratio of the image frame changes fluidly to fit the window width: http://london.msn.co.uk/ The point might be that the CSS pixel size of the image viewport can be entirely orthogonal to the required image pixel size. This website could benefit from a set of images with the same aspect ratio but different image resolutions. It could also benefit from some JS to center and scale these images to keep them centered on points of interest (to avoid
Re: [whatwg] Features for responsive Web design
Ian Hickson i...@hixie.ch schrieb am Tue, 4 Sep 2012 19:47:38 + (UTC): (regarding picture) I don't understand why it's more intuitive and easier. It seems way more unwieldly. Personally, I consider picture with source to be very similar to using ATOM enclosures in podcasting. The relation – there are several sub-resources that represent (more or less) one logical resource – directly maps to a container element with other elements in it. Having source elements would also allow to support future image formats while still having a fallback via content-type. […] Manipulating picture from script would be a huge pain -- you'd have to be manipulating lots of elements and attributes. Well, is manipulating audio or video from script a huge pain? I actually have one use case that would benefit from having separate elements instead of an attribute – replacing source elements with links to their content for accessability purposes. I did something like this when I hacked elinks to (badly) support HTML5 media elements http://blog.dieweltistgarnichtso.net/html5-media-elements-in-elinks. Consider that any attribute microsynthax would introduce a burden on programmatic DOM manipulation, as the attribute would have to be parsed separately. „Do X for every source child element“ is cognitively cheap in comparison to maintaining a mental model of the attribute in question – different from other mental models used in HTML – in your working memory. Furthermore, introducing an API would not help the use case of just parsing HTML in, say, Python, to programatically download all images from a page (or something like that). Anyway, with your proposal, would this be valid, to address the bandwidth-only use case?: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x […] Would also like to see if there's a way of using srcset to hint to the UA that it can skip the image under low throughput conditions e.g. GPRS. Same would apply to image-set in CSS This reminds me that ATOM enclosures have a byte length. Surfing via mobile, I certainly know that I would like images to show if they can be downloaded in a reasonable time – but I want to skip 5MB photos. […] On Wed, 8 Aug 2012, Florian Rivoal wrote: 1) Your syntax (almost, see point 2) replicates the behavior of max-width and and max-height Media Queries, but doesn't give access to other existing and future media queries, some of which may actually be useful. For example: a) using the 'monocrhome' MQ to serve gray scale images to black-and-white printers or e-ink displays. Displaying a color image on a monochrome display does not always work well, as two different colors of similar luminosity would be impossible to distinguish in a monochrome environment. I expect this need to grow together with the increasing popularity of HTML based ebooks. Is this a real use case or a theoretical one? Until we didn't support it, nobody once mentioned that it was a use case they cared about -- they only mentioned dimensions as being the issue. There seem to be quite some web devices that use black-and-white epaper. In a world in which people optimize content for mobile, tablets and accessability, I would certainly consider this when making a site. http://www.youtube.com/watch?v=zXZDn2Ia9js b) Microsoft is proposing a MQ which lets you detect that the UA has been put in hight contrast mode (for accessibility reasons), and that your content should follow along. Wouldn't it be better if content would be high-contrast always? Making things optional may lead to fragmentation, consider media container formats where streaming is optional and Ogg. Having a slight contrast problem myself, I can attest to the fact that my eyes do not have support for media queries. Gray-on-grey text and graphics need to die. […] 3) you syntax is terser, which is in generally a good thing, but I think it crosses the limit, as a large number of people have expressed confusion as to w and h were min or max, for example. The extra verbosity of my syntax gets you an extra bit of clarity, admittedly at the cost of having multiple elements. I agree that there's a small learning curve, but it seems pretty easy to understand. Do we really want to trade the small learning curve for a perpetuity of verbosity? As a programmer using Python, I am would argue for the latter. If markup is easier to read and understand for humans, people make fewer errors. Certainly, in uncommon cases (I consider p a common case) verbosity is helpful for both learning and readability. Fundamentally, a multiple-element solution here is simply a non-starter, IMHO. The pros of the multielement solution with verbose media queries are about the same in magnitude as the pros of the one-attribute solution with terse syntax, but the cons of the terse syntax are small whereas the cons of the multiple-element syntax are immense. For the multi-element
Re: [whatwg] Features for responsive Web design
On Sep 4, 2012, at 3:47 PM, Ian Hickson wrote: [...] On Thu, 24 May 2012, Florian Rivoal wrote: picture source srcset=normal.jpg 1x, highres.jpg 2x source media=(max-width:768px) srcset=ipad.jpg 1x, ipad3.jpg 2x source media=(max-width:320px) srcset=iphone.jpg 1x, iphone4.jpg 2x img src=normal.jpg /picture I don't understand why this is better than: img src=normal.jpg srcset=highres.jpg 2x, ipad.jpg 768w 1x, ipad3.jpg 768w 2x, iphone.jpg 320w 1x, iphone4.jpg 320w 2x alt=... ...which as far as I can tell does exactly the same thing. It is better because art direction and bandwidth use cases can be solved differently in an appropriate manner: - For the bandwidth use case, no MQ is needed, but only some information on the sources available to let the UA decide which source to load. - For the art direction use case OTOH, the picture element is more intuitive to handle and also easier to script, as sources can be added or removed via DOM. I don't understand why it's more intuitive and easier. It seems way more unwieldly. I’m not sure how exactly to prove to you that developers find the extended syntax unintuitive apart from continuing to point out the things that developers themselves have said on the topic, and I’m still not certain how the way it “feels” trumps the sentiments that you’ve read for yourself. I suppose we’ve reached an impasse. Whether it's easier for script is hard for me to say, because I don't really understand what scripts are going to be doing here. Can you elaborate? What will scripts need to do here? If it is harder to script, we can always provide a dedicated API. Manipulating picture from script would be a huge pain -- you'd have to be manipulating lots of elements and attributes. I can say for my own part: manipulating strings is far more difficult than manipulating the value of individual attributes. It’s hard to imagine a situation where I’d prefer to muck through a space/comma separated string rather than a set of independent elements and attributes. Unless the plan is to include an API similar to classList, though it would then be occupied by a set of strings describing disparate information. Given `srcset=img2.jpg 2x 300w, img3.jpg 600w 2x`, I can only envision a classList-style API returning something like one of the following: 1) [ img2.jpg, 2x, 300w, img3.jpg, 600w, 2x ] This obviously isn’t ideal where authors will have no idea what information is being manipulated without keeping constant tabs on the current index as compared to the string in the markup. Even if the order of these separate concerns were normalized, the inclusion or omission of any individual aspect of a rule would mean a flurry of `console.log`s in order to figure out which index represented which concern — or careful counting of spaces in one’s markup, which certainly seems error-prone to me. I know I would certainly make mistakes, there. 2) [ img2.jpg 2x 300w, img3.jpg 600w 2x ] We’re still left parsing space-seperated strings for relevant information, albeit smaller ones. I don’t feel there’s much of a case to be made in favor of writing regular expressions to parse and manipulate strings, rather than manipulating elements and attributes — though, as always, I’m happy to reach out to the author community and ask. If I’m completely off-base here — and I may well be — I’d certainly be interested in reading more about the plans for an API.
Re: [whatwg] Features for responsive Web design
Whether it's easier for script is hard for me to say, because I don't really understand what scripts are going to be doing here. Can you elaborate? What will scripts need to do here? Manipulating picture from script would be a huge pain -- you'd have to be manipulating lots of elements and attributes. No more than the already accepted syntax and structure for video. Not that one would really be manipulating tons of elements and attributes but swapping out sources for things like a photo gallery and the like are things that will happen. We should expect the general use cases for script manipulation that exist today for img will naturally migrate to picture if it indeed becomes the new standard. Picture is going to broaden device support scope. If the functionality exists with img as it stands, those use cases should be at least considered in part or in whole for the base scope for picture. As a developer, I cannot stress enough the wasted time that would result from the act of parsing through the srcset syntax. Even with library support, understanding and properly manipulating to initiate a change for something like a photo gallery is unnecessary when compared to the proposed specs inspiration, the video element. I would think it is easier for the js library folks and purists alike to deal with a set of child nodes in js than bloated property lists where additional parsing requirements will result in additional script that ultimately negatively affects bandwidth on lower bandwidth devices. Trading one evil for another isn't in my opinion the goal of the proposed picture element.
Re: [whatwg] Features for responsive Web design
On Mon, 27 Aug 2012 12:05:00 +0100, Chaals McCathieNevile w...@chaals.com wrote: While it's unlikely that screen resolution will go above 2x in the near future, should we be taking into account the zooming of specific elements that might result in the need for larger artwork? (take icons, that can scale all the way up to 512px or above) Or outdoor screens that are 4m x 8m, carrying the same content meant for a TV display and a message to your mobile. Use cases: + emergency information provision, where the sign is acting as a server providing information to all devices that can connect). + providing advertising, local information that can be rendered on large outdoor screens, tv-size screens, and for customers. Those are fine use-cases, but I don't see how do they need anything special in relation to zooming/pixel density. It seems to me that despite large physical size, outdoor screens are not unusual, because due to larger viewing distance the actual perceived size and pixel density isn't very different from normal screens. For example the famous display ads in Piccadilly Circus in London have easily noticeable pixels, so they're merely a 1x screen, not even 2x yet. -- regards, Kornel
Re: [whatwg] Features for responsive Web design
On Wed, Sep 5, 2012 at 1:45 PM, Mathew Marquis m...@matmarquis.com wrote:
I can say for my own part: manipulating strings is far more difficult than
manipulating the value of individual attributes. It’s hard to imagine a
situation where I’d prefer to muck through a space/comma separated string
rather than a set of independent elements and attributes. Unless the plan is
to include an API similar to classList, though it would then be occupied by
a set of strings describing disparate information.
I agree, string manipulation is *not* what we want here.
Given `srcset=img2.jpg 2x 300w, img3.jpg 600w 2x`, I can only envision a
classList-style API returning something like one of the following:
1) [ img2.jpg, 2x, 300w, img3.jpg, 600w, 2x ]
This obviously isn’t ideal where authors will have no idea what information
is being manipulated without keeping constant tabs on the current index as
compared to the string in the markup. Even if the order of these separate
concerns were normalized, the inclusion or omission of any individual aspect
of a rule would mean a flurry of `console.log`s in order to figure out which
index represented which concern — or careful counting of spaces in one’s
markup, which certainly seems error-prone to me. I know I would certainly
make mistakes, there.
2) [ img2.jpg 2x 300w, img3.jpg 600w 2x ]
We’re still left parsing space-seperated strings for relevant information,
albeit smaller ones.
I don’t feel there’s much of a case to be made in favor of writing regular
expressions to parse and manipulate strings, rather than manipulating
elements and attributes — though, as always, I’m happy to reach out to the
author community and ask. If I’m completely off-base here — and I may well
be — I’d certainly be interested in reading more about the plans for an API.
Might I propose an option 3 (which is in no way a vote of support for
Hixies suggested srcset, I like the proposed video-like syntax far
more):
[{ image: 'img2.jpg', density: '2x', query: '300w' }, { image:
'img3.jpg', density: '2x', query: '600w' }]
If the values are actually keyed to something predictable, we might
stand some chance of actually reading/manipulating them without having
to determine which value is which if they are out of order (it stand
to reason the browser would have done this already, so…)
Cheers,
Aaron
Aaron Gustafson
Principal
Easy Designs, LLC
@aarongustafson
Re: [whatwg] Features for responsive Web design
Mathew Marquis m...@matmarquis.com schrieb am Wed, 5 Sep 2012 13:45:41 -0400: […] I’m not sure how exactly to prove to you that developers find the extended syntax unintuitive apart from continuing to point out the things that developers themselves have said on the topic, and I’m still not certain how the way it “feels” trumps the sentiments that you’ve read for yourself. I suppose we’ve reached an impasse. I would suggest doing an actual study on web devs who do not participate in this discussion, but I have no idea how to do usability studies in a proper, scientific way (not asking suggestive questions etc.). -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Features for responsive Web design
Aaron Gustafson aa...@easy-designs.net schrieb am Wed, 5 Sep 2012
18:42:37 -0400:
[…]
Might I propose an option 3 (which is in no way a vote of support for
Hixies suggested srcset, I like the proposed video-like syntax far
more):
[{ image: 'img2.jpg', density: '2x', query: '300w' }, { image:
'img3.jpg', density: '2x', query: '600w' }]
If the values are actually keyed to something predictable, we might
stand some chance of actually reading/manipulating them without having
to determine which value is which if they are out of order (it stand
to reason the browser would have done this already, so…)
Still, this would mean that existing DOM-like node-based data
structures could not be used easily – even if filled through HTML5lib –
because there would be no obvious mapping for such fractal complexity.
--
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net
Re: [whatwg] Features for responsive Web design
On Wed, Sep 5, 2012 at 7:01 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Aaron Gustafson aa...@easy-designs.net schrieb am Wed, 5 Sep 2012
18:42:37 -0400:
[…]
Might I propose an option 3 (which is in no way a vote of support for
Hixies suggested srcset, I like the proposed video-like syntax far
more):
[{ image: 'img2.jpg', density: '2x', query: '300w' }, { image:
'img3.jpg', density: '2x', query: '600w' }]
If the values are actually keyed to something predictable, we might
stand some chance of actually reading/manipulating them without having
to determine which value is which if they are out of order (it stand
to reason the browser would have done this already, so…)
Still, this would mean that existing DOM-like node-based data
structures could not be used easily – even if filled through HTML5lib –
because there would be no obvious mapping for such fractal complexity.
Agreed. It’s not ideal by any means, but it would be a teensy bit
better than the options mentioned IMHO.
Cheers,
Aaron
Aaron Gustafson
Principal
Easy Designs, LLC
@aarongustafson
Re: [whatwg] Features for responsive Web design
On Wed, Sep 5, 2012 at 12:45 PM, Mathew Marquis m...@matmarquis.com wrote:
I’m not sure how exactly to prove to you that developers find the extended
syntax unintuitive apart from continuing to point out the things that
developers themselves have said on the topic, and I’m still not certain how
the way it “feels” trumps the sentiments that you’ve read for yourself. I
suppose we’ve reached an impasse.
I'm a developer, and I don't find it difficult or confusing at all.
Manipulating XML-like data with bits of information spread across elements
is definitely a pain.
Given `srcset=img2.jpg 2x 300w, img3.jpg 600w 2x`, I can only envision a
classList-style API returning something like one of the following:
That's simple.
// img.srcsetList[0].path == img2.jpg
// img.srcsetList[0].density == 2
// img.srcsetList[0].width == 300
// img.srcsetList[0].height == null
// img.srcsetList[1].path == img3.jpg
// img.srcsetList[1].density == 2
// img.srcsetList[1].width == 600
// img.srcsetList[1].height == null
img.srcsetList.push(new SrcSetItem({path: img4.jpg, width: 1200}));
img.srcsetList.splice(1); // and other array operations
On Wed, Sep 5, 2012 at 6:01 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Still, this would mean that existing DOM-like node-based data
structures could not be used easily – even if filled through HTML5lib –
because there would be no obvious mapping for such fractal complexity.
Fractal complexity? Please don't be dramatic; this is embarrassingly
simple.
--
Glenn Maynard
Re: [whatwg] Features for responsive Web design
On Sep 4, 2012, at 12:47 , Ian Hickson i...@hixie.ch wrote: On Thu, 7 Jun 2012, Mark Callow wrote: IIRC Kodak's PhotoCD image format had this characteristic. The first part is a low res. image, the second is the differences between the low res. image zoomed to the high res. size and the actual high res. image. Such formats certainly would make a lot of this simpler! supported in JPEG 2000 (for files in resolution progression order), FWIW David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Features for responsive Web design
Glenn Maynard gl...@zewt.org schrieb am Wed, 5 Sep 2012 19:01:19 -0500: […] On Wed, Sep 5, 2012 at 6:01 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Still, this would mean that existing DOM-like node-based data structures could not be used easily – even if filled through HTML5lib – because there would be no obvious mapping for such fractal complexity. Fractal complexity? Please don't be dramatic; this is embarrassingly simple. Often, solutions that can be considered “simple” for emitters of data externalize costs, burdening consumers – especially when “simple” prevents using off-the-shelf components like XML parsers (if a site returns JSON in a case where ATOM might suffice) or DOM structures. Usually, data is (way) more often consumed than generated. Can you elaborate how you would use Python's ElementTree (or a similar data structure) with srcset in an “embarrassingly simple” way? http://docs.python.org/library/xml.etree.elementtree.html -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Features for responsive Web design
On Wed, Sep 5, 2012 at 7:49 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Often, solutions that can be considered “simple” for emitters of data externalize costs, burdening consumers – especially when “simple” prevents using off-the-shelf components like XML parsers (if a site returns JSON in a case where ATOM might suffice) or DOM structures. The creators (emitters) of HTML are predominantly human authors, and the consumers of HTML are predominantly web browsers. It's *much* more important that the format be convenient for authors than for browsers. Also, experience showed long ago that over-normalizing data in the style of XML leads to bloated, hard to author, hard to manipulate data. Usually, data is (way) more often consumed than generated. You're mixing up number of times consumed with number of times someone writes a parser. There are an inconceivably larger number of people authoring HTML than writing HTML parsers. -- Glenn Maynard
Re: [whatwg] Features for responsive Web design
On Thu, 7 Jun 2012, Mark Callow wrote: On 06/06/2012 21:36, Henri Sivonen wrote: More to the point, the important characteristic is being able to stop downloading *quarter* way through the file and get results that are as good as if the full-size file had been down sampled with both dimensions halved and that size had been sent as the full file. (I am not aware of a bitmap format suitable for photographs that has this characteristic. I am aware that JPEG 2000 does not have this characteristic. I believe interlaced PNGs have that characteristic, but they aren't suitable for photographs, due to the lossless compression.) IIRC Kodak's PhotoCD image format had this characteristic. The first part is a low res. image, the second is the differences between the low res. image zoomed to the high res. size and the actual high res. image. Such formats certainly would make a lot of this simpler! On Wed, 8 Aug 2012, Markus Ernst wrote: - Use picture for the art direction use case. - Remove the MQ except the pixel density from @srcset, and make @srcset available in both img and source: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x picture alt= source src=mobile.jpg srcset=low.jpg 0.5x, mobile.jpg 1x, mobile-hd.jpg 2x source src=large.jpg media=min-width: 600px srcset=large.jpg 1x, large-high.jpg 2x img src=mobile.jpg /picture I don't understand why this is better than: img src=large.jpg alt= srcset=low.jpg 600w 0.5x, mobile.jpg 600w 1x, mobile-hd.jpg 600w 2x, large-high.jpg 2x It seems to me that srcset as specified does exactly the same thing, but more succintly. [...] On Thu, 24 May 2012, Florian Rivoal wrote: picture source srcset=normal.jpg 1x, highres.jpg 2x source media=(max-width:768px) srcset=ipad.jpg 1x, ipad3.jpg 2x source media=(max-width:320px) srcset=iphone.jpg 1x, iphone4.jpg 2x img src=normal.jpg /picture I don't understand why this is better than: img src=normal.jpg srcset=highres.jpg 2x, ipad.jpg 768w 1x, ipad3.jpg 768w 2x, iphone.jpg 320w 1x, iphone4.jpg 320w 2x alt=... ...which as far as I can tell does exactly the same thing. It is better because art direction and bandwidth use cases can be solved differently in an appropriate manner: - For the bandwidth use case, no MQ is needed, but only some information on the sources available to let the UA decide which source to load. - For the art direction use case OTOH, the picture element is more intuitive to handle and also easier to script, as sources can be added or removed via DOM. I don't understand why it's more intuitive and easier. It seems way more unwieldly. Whether it's easier for script is hard for me to say, because I don't really understand what scripts are going to be doing here. Can you elaborate? What will scripts need to do here? If it is harder to script, we can always provide a dedicated API. Manipulating picture from script would be a huge pain -- you'd have to be manipulating lots of elements and attributes. Anyway, with your proposal, would this be valid, to address the bandwidth-only use case?: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x Yes (assuming it's a presentational image). You can make it even shorter: img src=normal.jpg alt= srcset=high.jpg 2x On Thu, 9 Aug 2012, Andy Davies wrote: I know it's there for graceful degradation reasons but doesn't setting the 1x image via src and the others via srcset just add to developers confusion? Doesn't seem that confusing to me, but maybe I've more confidence in authors than you? :-) Would also like to see if there's a way of using srcset to hint to the UA that it can skip the image under low throughput conditions e.g. GPRS. Same would apply to image-set in CSS The browser is never required to show the image, so that's already possible for all images. However, for a discussion of the difficulties of bandwidth-driven negotiations, see: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0247.html On Wed, 8 Aug 2012, Florian Rivoal wrote: 1) Your syntax (almost, see point 2) replicates the behavior of max-width and and max-height Media Queries, but doesn't give access to other existing and future media queries, some of which may actually be useful. For example: a) using the 'monocrhome' MQ to serve gray scale images to black-and-white printers or e-ink displays. Displaying a color image on a monochrome display does not always work well, as two different colors of similar luminosity would be impossible to distinguish in a monochrome environment. I expect this need to grow together with the increasing popularity of HTML based ebooks. Is this a real use case or a theoretical one? Until
Re: [whatwg] Features for responsive Web design
On Tue, 21 Aug 2012 22:36:15 +0200, Steve Dennis ad...@subcide.com wrote: While it's unlikely that screen resolution will go above 2x in the near future, should we be taking into account the zooming of specific elements that might result in the need for larger artwork? (take icons, that can scale all the way up to 512px or above) Or outdoor screens that are 4m x 8m, carrying the same content meant for a TV display and a message to your mobile. Use cases: + emergency information provision, where the sign is acting as a server providing information to all devices that can connect). + providing advertising, local information that can be rendered on large outdoor screens, tv-size screens, and for customers. cheers Chaals On 13/08/2012, at 5:39 PM, Henri Sivonen hsivo...@iki.fi wrote: Another thing worth considering is if ever anyone is really going to go over 2x, given that at normal viewing distances 2x is roughly enough to saturate the resolution of the human eye (hence the retina branding). Even for printing photos, 192 pixels per inch should result in very good quality, and for line art, authors should use SVG instead of bitmaps anyway. -- Chaals - standards declaimer
Re: [whatwg] Features for responsive Web design
On Aug 7, 2012, at 3:09 PM, Ian Hickson wrote: On Tue, 15 May 2012, 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. I'm happy to consider specific feedback, but at the time in this thread where this e-mail was sent, We had yet to receive any negative commentary at all on the mailing list, so this seems a bit vague. :-) A great deal of author feedback was posted to http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/, the link to which was posted to the mailing list several times. You’ll notice that the comments are nearly unanimous. At the time this was posted the CG sites were taken down due to excessive traffic, as authors sounded off on the subject. There was also no small measure of relief from the #whatwg regulars once the IRC traffic died down, as I recall. Prominent members of the developer community haven’t been terribly subtle in their opinions of the markup, either: https://twitter.com/zeldman/status/233232252111302657 When the syntax is the butt of jokes at high-profile conferences, it might be time to accept that we authors aren’t especially partial to it. If you’d prefer I instruct the developer community to comment on this thread instead, I’m happy to do so. If author sentiment was somehow ignored the first time, though — if it either went wholly unnoticed by the decision-makers, or is now being disregarded due to where those sentiments were posted — I don’t see where it will change much apart from several hundred more emails to prove a fairly self-evident point. Since author preference has been cited several times in support of the terseness of the extended `srcset` syntax, I think it’s probably best that we not discount the methods by which authors voice their own preference if the real goal is an author-friendly pattern — unless we’re dismissing the “authors will prefer the shorter syntax” argument as well. Perhaps that would be the second best course of action here. Mat Marquis
Re: [whatwg] Features for responsive Web design
While it's unlikely that screen resolution will go above 2x in the near future, should we be taking into account the zooming of specific elements that might result in the need for larger artwork? (take icons, that can scale all the way up to 512px or above) On 13/08/2012, at 5:39 PM, Henri Sivonen hsivo...@iki.fi wrote: Another thing worth considering is if ever anyone is really going to go over 2x, given that at normal viewing distances 2x is roughly enough to saturate the resolution of the human eye (hence the retina branding). Even for printing photos, 192 pixels per inch should result in very good quality, and for line art, authors should use SVG instead of bitmaps anyway.
Re: [whatwg] Features for responsive Web design
On Fri, Aug 10, 2012 at 11:54 AM, Florian Rivoal flori...@opera.com wrote: I wasn't debating whether or not shipping a device with a 1.5 pixel ratio is the best decision, but answering: Is there a good reason to believe that will be something other than a power of two? The fact that it has happened seems a pretty good reason to believe that it may happen. These are different questions: Will someone ship a browser/device combination whose device pixel ratio is something other than 1 or 2? Will Web authors bother to supply bitmaps with sampling factors other than 1 and 2? As a data point worth considering, for desktop apps on OS X Apple makes developers supply bitmap assets for 1x and 2x and if the user chooses a ratio between 1 and 2, the screen is painted at 2x and the resulting bitmap is scaled down. Another thing worth considering is if ever anyone is really going to go over 2x, given that at normal viewing distances 2x is roughly enough to saturate the resolution of the human eye (hence the retina branding). Even for printing photos, 192 pixels per inch should result in very good quality, and for line art, authors should use SVG instead of bitmaps anyway. If it indeed is the case that there are really only two realistic bitmaps samplings for catering to differences in weeding device pixel density (ignoring art direction), it would make sense to have simply img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative instead of an in-attribute microsyntax for the non-art-directed case. Ian Hickson wrote: On Wed, 16 May 2012, Henri Sivonen wrote: 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 picture is bad for the pixel density case. I don't really understand why They are conceptually very different: One is mere mipmapping and can be automatically generated. The other involves designer judgment and is conceptually similar to CSS design where authors use MQ. Also, having w and h refer to the browsing environment and x to the image in the same microsyntax continues to be highly confusing. Ignoring implementation issues for a moment, I think it would be conceptually easier it to disentangle these axes like this: Non-art directed: img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative Art directed: picture source src=1xsampling-cropped.jpg hisrc=2xsampling-cropped.jpg media=max-width: 480px img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative /picture -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Features for responsive Web design
Am 13.08.2012 18:39 schrieb Henri Sivonen: Ignoring implementation issues for a moment, I think it would be conceptually easier it to disentangle these axes like this: Non-art directed: img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative Art directed: picture source src=1xsampling-cropped.jpg hisrc=2xsampling-cropped.jpg media=max-width: 480px img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative /picture I like this hisrc approach for its simplicity; it depends on the question whether a limit of 2 sources for the bandwidth use case is considered to be okay. Anyway, I think it is an important question, as there may be future use cases that require more than 2 sources, such as providing an extra source for printing (which may be a 3x or 4x pixel format or a vector format), or progressive loading of sources as I described here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036884.html Anyway both these cases are hypothetic, and the print use case may also be solved via picture and media=print. From an author's POV, hisrc looks quite intuitive and easy to use to me.
Re: [whatwg] Features for responsive Web design
On Mon, Aug 13, 2012 at 6:39 PM, Henri Sivonen hsivo...@iki.fi wrote: If it indeed is the case that there are really only two realistic bitmaps samplings for catering to differences in weeding device pixel density (ignoring art direction), it would make sense to have simply img src=1xsampling.jpg hisrc=2xsampling.jpg alt=Text alternative instead of an in-attribute microsyntax for the non-art-directed case. Agreed that avoiding the in-attribute micro syntax--if at all possible--is a mighty worthy goal. --tobie
Re: [whatwg] Features for responsive Web design
Am 10.08.2012 12:06 schrieb Odin Hørthe Omdal: On Thu, 09 Aug 2012 18:54:10 +0200, Kornel Lesiński kor...@geekhood.net wrote: One stylesheet can be easily reused for pixel-perfect 1x/2x layout, but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x. Apart from it possibly being a self-fulfilling prophecy – isn't this too much premature “optimization” ? I think we can safely assume that authors will always want to prepare as few assets and stylesheets as they can, and will prefer integer units to fractional ones (1px line vs 1.px line). I don't see the big problem, I think the spec is fine here. Yes it allows for putting a float there, but authors won't use it, so what's the problem? The spec already say you should use the number to calculate the correct intrinsic size, and the implementation will know what to do with a float number there if someone finds an actual use for it. This isn't limiting it for the sake of making anything easier, it's not like the x is an integer is any easier than the x is a float. And if you *do* somehow find a good use for it down the line (and I believe there might be, maybe 0.5x) it'll be there and work. No harm. :) One hypothetic use case for 0.5x could be: Future UAs may want to progressively load sources in order to display a lowres image very quickly, and increase quality if there is enough bandwidth to do so, similarly to what we know from interlaced GIFs. Authors then might want to provide 0.5x and even 0.25x sources for this purpose.
Re: [whatwg] Features for responsive Web design
On Thu, 09 Aug 2012 11:29:17 +0200, Kornel Lesiński kor...@geekhood.net wrote: On 8 sie 2012, at 12:57, Florian Rivoal flori...@opera.com wrote: Is there a good reason to believe that * will be something other than a power of two? That is, could we just optimize the *x syntax away and specify that the first option is 1x, the second is 2x, the third is 4x, etc.? If you look at mobile phones, there are a bunch of existing devices with 1.5 device pixel per css pixel, and also some with 2.25, so I don't think we can assume only powers of 2 will be used. Pixel-perfect design for non-integer scaling ratios is very hard. To have evenly thin lines (1 device pixel wide) on such screens you have to use fractional CSS pixel sizes, and fractions need to be different for different scaling ratios. I don't think anybody will take advantage of that. IMHO non-integer ratios are a mistake that can/will be corrected. I wasn't debating whether or not shipping a device with a 1.5 pixel ratio is the best decision, but answering: Is there a good reason to believe that will be something other than a power of two? The fact that it has happened seems a pretty good reason to believe that it may happen. Fractional ratios have proven to be unnecessary: on desktops 1x CSS pixel changed from 72dpi (CRT) to 130dpi on notebook screens, but we haven't got fractional scaling ratios along the way. Variability in screen sizes and actual DPI has been accepted. The same can happen with 1.5x-2.5x screens: pretend they all are 2x, vary CSS pixel width/height, accept physical size of CSS pixel will be slightly different. For example the 2.25 ratio doesn't make sense to me. 12.5% increase in screen density is going to be imperceptible. A better solution would be to use the crisp 2x ratio and have bigger screen area (in CSS pixels). A ratio of 2.25 on 720 physical pixel device gives a viewport width of 320 css pixels. 320 pixels is the same as the iPhone, and being identical to that helps with site compatibility. I am not convinced that using 2.25 was the best decision, but it has some justifications, and has happened, so I don't think it is reasonable to bake in some assumptions in the spec (only powers of 2) when we know that they don't match reality. - Florian
Re: [whatwg] Features for responsive Web design
On 10 Aug 2012, at 09:54, Florian Rivoal wrote: On Thu, 09 Aug 2012 11:29:17 +0200, Kornel Lesiński kor...@geekhood.net wrote: On 8 sie 2012, at 12:57, Florian Rivoal flori...@opera.com wrote: Is there a good reason to believe that * will be something other than a power of two? I wasn't debating whether or not shipping a device with a 1.5 pixel ratio is the best decision, but answering: Is there a good reason to believe that will be something other than a power of two? The fact that it has happened seems a pretty good reason to believe that it may happen. For reference, we are seeing *all sorts* of viewport and pixel density variations on Android devices. Low cost devices such as the Galaxy Mini have 240 hardware pixels but the default viewport (CSS pixels) has been set to a higher value of 320 pixels. This value was likely chosen not just to match the iPhone, but because it was needed to achieve comfortable legibility given the quality of the display. It does however result in an unusual ratio of 0.75. As the Android platform also includes some incredibly robust user settings (and the granularity of these settings only seems to be increasing as the platform evolves) a user can easily reset these 320 CSS pixels back down to 240 or as high up as 940 (they won't know the exact number...the settings are simply labelled small, medium etc). Of course at 940 pixels, content on this device would be near illegible but this is just one example, of one setting, on one device. A given viewport adjustment may make little sense on a phone, but lots more sense on a completely different device (such as a seat-back display in a car or airplane). While I hope viewport sizes will eventually standardize, the display is just one variable on a bill of materials. Given that manufacturers (and not just the ones that make phones) have the option to tweak the viewport in an effort to achieve a more comfortable pairing of hardware with software, unusual viewport sizes seem likely to remain a coping strategy for some time. Steph
Re: [whatwg] Features for responsive Web design
On Thu, 09 Aug 2012 18:54:10 +0200, Kornel Lesiński kor...@geekhood.net wrote: One stylesheet can be easily reused for pixel-perfect 1x/2x layout, but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x. Apart from it possibly being a self-fulfilling prophecy – isn't this too much premature “optimization” ? I think we can safely assume that authors will always want to prepare as few assets and stylesheets as they can, and will prefer integer units to fractional ones (1px line vs 1.px line). I don't see the big problem, I think the spec is fine here. Yes it allows for putting a float there, but authors won't use it, so what's the problem? The spec already say you should use the number to calculate the correct intrinsic size, and the implementation will know what to do with a float number there if someone finds an actual use for it. This isn't limiting it for the sake of making anything easier, it's not like the x is an integer is any easier than the x is a float. And if you *do* somehow find a good use for it down the line (and I believe there might be, maybe 0.5x) it'll be there and work. No harm. :) -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: [whatwg] Features for responsive Web design
On 9 August 2012 17:01, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Aug 9, 2012 at 1:16 AM, Andy Davies dajdav...@gmail.com wrote: Would also like to see if there's a way of using srcset to hint to the UA that it can skip the image under low throughput conditions e.g. GPRS. Same would apply to image-set in CSS The image-set() function already includes this functionality. You can include a fallback color, and if the UA decides it doesn't want to download *any* of the images, it can just create a solid-color image and use that instead. Thanks I see it now - must have missed it when first scanned the CSS4-images spec Andy
Re: [whatwg] Features for responsive Web design
On 8 August 2012 17:44, Edward O'Connor eocon...@apple.com wrote: Hi Markus, You wrote: Anyway, with your proposal, would this be valid, to address the bandwidth-only use case?: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x You don't need the , normal.jpg 1x because src= has an implied 1x. The above could simply be done like so: img src=normal.jpg alt=appropriate alt text srcset=high.jpg 2x I know it's there for graceful degradation reasons but doesn't setting the 1x image via src and the others via srcset just add to developers confusion? Would also like to see if there's a way of using srcset to hint to the UA that it can skip the image under low throughput conditions e.g. GPRS. Same would apply to image-set in CSS Cheers Andy
Re: [whatwg] Features for responsive Web design
On 8 sie 2012, at 12:57, Florian Rivoal flori...@opera.com wrote: Is there a good reason to believe that * will be something other than a power of two? That is, could we just optimize the *x syntax away and specify that the first option is 1x, the second is 2x, the third is 4x, etc.? If you look at mobile phones, there are a bunch of existing devices with 1.5 device pixel per css pixel, and also some with 2.25, so I don't think we can assume only powers of 2 will be used. Pixel-perfect design for non-integer scaling ratios is very hard. To have evenly thin lines (1 device pixel wide) on such screens you have to use fractional CSS pixel sizes, and fractions need to be different for different scaling ratios. I don't think anybody will take advantage of that. IMHO non-integer ratios are a mistake that can/will be corrected. Fractional ratios have proven to be unnecessary: on desktops 1x CSS pixel changed from 72dpi (CRT) to 130dpi on notebook screens, but we haven't got fractional scaling ratios along the way. Variability in screen sizes and actual DPI has been accepted. The same can happen with 1.5x-2.5x screens: pretend they all are 2x, vary CSS pixel width/height, accept physical size of CSS pixel will be slightly different. For example the 2.25 ratio doesn't make sense to me. 12.5% increase in screen density is going to be imperceptible. A better solution would be to use the crisp 2x ratio and have bigger screen area (in CSS pixels). For mobile browsers which have zoom it's easy as they can pretend to have 2x scaling ratio on a virtual viewport and resize it to screen of any other density. That's what Retina MacBook Pro does with whole screen when user requests screen resolution that isn't 1:1 with screen pixels. You can see from previous OS X releases that Apple has struggled with implementation of fractional scaling ratios for years and has given up on them. It's going to be easier to stick to 2x screens (like most desktop monitors settled on ~100dpi) or use fake 2x (scaled viewport) than expect authors to make pixel-perfect designs for 1.25, 1.5, 1.75, 2.25, etc. -- regards, Kornel
Re: [whatwg] Features for responsive Web design
Kornel Lesi__ski kor...@geekhood.net schrieb am Thu, 9 Aug 2012 10:29:17 +0100: On 8 sie 2012, at 12:57, Florian Rivoal flori...@opera.com wrote: […] If you look at mobile phones, there are a bunch of existing devices with 1.5 device pixel per css pixel, and also some with 2.25, so I don't think we can assume only powers of 2 will be used. […] I don't think anybody will take advantage of that. IMHO non-integer ratios are a mistake that can/will be corrected. Limiting to powers of two because it can/will be “simpler” in this case not only makes the attribute harder to read – it also locks vendors in. Apart from it possibly being a self-fulfilling prophecy – isn't this too much premature “optimization” ? Btw, I am not aware of any other attribute that has a logarithmic scale baked in – are you? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Features for responsive Web design
On Thu, Aug 9, 2012 at 1:16 AM, Andy Davies dajdav...@gmail.com wrote: Would also like to see if there's a way of using srcset to hint to the UA that it can skip the image under low throughput conditions e.g. GPRS. Same would apply to image-set in CSS The image-set() function already includes this functionality. You can include a fallback color, and if the UA decides it doesn't want to download *any* of the images, it can just create a solid-color image and use that instead. ~TJ
Re: [whatwg] Features for responsive Web design
On 9 sie 2012, at 11:06, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: I don't think anybody will take advantage of that. IMHO non-integer ratios are a mistake that can/will be corrected. Limiting to powers of two because it can/will be “simpler” in this case not only makes the attribute harder to read – it also locks vendors in. I'm not talking just about difficulty of specifying image scaling factor, but overall difficulty of developing complete page layout with all box, border and margin sizes in fractional CSS pixels. I assume that if a designer cares enough to create several pixel-perfect versions of images, they will also want same pixel perfection from all other page features, e.g. will hate that on 1.5dppx screen a 1px border is rendered with 1dpx in one place, but 2dpx in another (or differently blurry 2dpx in both places) and will want to specify 0.px or 1.px border instead. One stylesheet can be easily reused for pixel-perfect 1x/2x layout, but pixel-perfect 1.5x requires its own sizes incompatible with 1x/2x. Apart from it possibly being a self-fulfilling prophecy – isn't this too much premature “optimization” ? I think we can safely assume that authors will always want to prepare as few assets and stylesheets as they can, and will prefer integer units to fractional ones (1px line vs 1.px line). Btw, I am not aware of any other attribute that has a logarithmic scale baked in – are you? Best scaling ratios are linear, rounded to nearest integer (i.e. 3x is OK too). That's quite common in computer science, and not surprising when dealing with discrete unit like device pixel. -- regards, Kornel
Re: [whatwg] Features for responsive Web design
Am 07.08.2012 21:09 schrieb Ian Hickson: On Tue, 22 May 2012, Markus Ernst wrote: Am 18.05.2012 23:19 schrieb Kornel Lesiński: If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. Maybe the use cases should be solved independent from each other: - Use picture for the art direction use case. - Remove the MQ except the pixel density from @srcset, and make @srcset available in both img and source: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x picture alt= source src=mobile.jpg srcset=low.jpg 0.5x, mobile.jpg 1x, mobile-hd.jpg 2x source src=large.jpg media=min-width: 600px srcset=large.jpg 1x, large-high.jpg 2x img src=mobile.jpg /picture I don't understand why this is better than: img src=large.jpg alt= srcset=low.jpg 600w 0.5x, mobile.jpg 600w 1x, mobile-hd.jpg 600w 2x, large-high.jpg 2x It seems to me that srcset as specified does exactly the same thing, but more succintly. [...] On Thu, 24 May 2012, Florian Rivoal wrote: picture source srcset=normal.jpg 1x, highres.jpg 2x source media=(max-width:768px) srcset=ipad.jpg 1x, ipad3.jpg 2x source media=(max-width:320px) srcset=iphone.jpg 1x, iphone4.jpg 2x img src=normal.jpg /picture I don't understand why this is better than: img src=normal.jpg srcset=highres.jpg 2x, ipad.jpg 768w 1x, ipad3.jpg 768w 2x, iphone.jpg 320w 1x, iphone4.jpg 320w 2x alt=... ...which as far as I can tell does exactly the same thing. It is better because art direction and bandwidth use cases can be solved differently in an appropriate manner: - For the bandwidth use case, no MQ is needed, but only some information on the sources available to let the UA decide which source to load. - For the art direction use case OTOH, the picture element is more intuitive to handle and also easier to script, as sources can be added or removed via DOM. Anyway, with your proposal, would this be valid, to address the bandwidth-only use case?: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x
Re: [whatwg] Features for responsive Web design
On 08/08/2012 12:27 PM, Markus Ernst wrote: It is better because art direction and bandwidth use cases can be solved differently in an appropriate manner: - For the bandwidth use case, no MQ is needed, but only some information on the sources available to let the UA decide which source to load. - For the art direction use case OTOH, the picture element is more intuitive to handle and also easier to script, as sources can be added or removed via DOM. What are the use cases for adding/removing images? It seems to me that they would be better addressed by having a good API for interacting with srcset rather than adopting an element based design. For example one could have HTMLImageElement.addSrc(url, options) where options is a dictionary allowing you to set the various srcset options.
Re: [whatwg] Features for responsive Web design
Am 18.05.2012 23:19 schrieb Kornel Lesiński: If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. Maybe the use cases should be solved independent from each other: - Use picture for the art direction use case. - Remove the MQ except the pixel density from @srcset, and make @srcset available in both img and source: img src=normal.jpg alt= srcset=high.jpg 2x, normal.jpg 1x picture alt= source src=mobile.jpg srcset=low.jpg 0.5x, mobile.jpg 1x, mobile-hd.jpg 2x source src=large.jpg media=min-width: 600px srcset=large.jpg 1x, large-high.jpg 2x img src=mobile.jpg /picture This leaves the whole design choice to the author, and gives the UA the full choice on what resource to use. Instead of coping with various kinds of MQs, the author can just specify the sources available, and the UA will make the choice based on the situation. The 0.5px version in my example would be intended for use with very low bandwidth, or for a UA that may progressively load sources as we know it from old progressive GIFs.
Re: [whatwg] Features for responsive Web design
On May 21, 2012, at 9:37 PM, Kornel Lesiński kor...@geekhood.net wrote: There’s no prior precedent this sort of thing—there’s no reason we can’t find a way to preserve an image’s intrinsic width using `picture`. I wonder if simply adding `width` and `height` attributes on the element (similar to `img`) might solve this, in the event that the author wants to rely on an intrinsic size instead of CSS? I think that is a very good idea. Having option to do so is good for performance, as it avoids reflows. If 'width' and 'height' attributes on the picture element would do the same thing as they do on img, then they would be setting the size via style, rather than setting intrinsic size. Even if setting the size explicitly affected intrinsic size rather than size computed via style, it would miss the point of intrinsic size, which is that images get automatically the right amount of space based on the image itself. Auto-sizing may not be the right choice for all designs, but it is for some designs. - Maciej
Re: [whatwg] Features for responsive Web design
Sorry, I forgot to clarify this ― I had in mind adding width/height on each source element, not on picture. -- regards, Kornel On 22 maj 2012, at 16:01, Maciej Stachowiak m...@apple.com wrote: On May 21, 2012, at 9:37 PM, Kornel Lesi��ski kor...@geekhood.net wrote: There’s no prior precedent this sort of thing―there’s no reason we can’t find a way to preserve an image’s intrinsic width using `picture`. I wonder if simply adding `width` and `height` attributes on the element (similar to `img`) might solve this, in the event that the author wants to rely on an intrinsic size instead of CSS? I think that is a very good idea. Having option to do so is good for performance, as it avoids reflows. If 'width' and 'height' attributes on the picture element would do the same thing as they do on img, then they would be setting the size via style, rather than setting intrinsic size. Even if setting the size explicitly affected intrinsic size rather than size computed via style, it would miss the point of intrinsic size, which is that images get automatically the right amount of space based on the image itself. Auto-sizing may not be the right choice for all designs, but it is for some designs. - Maciej
Re: [whatwg] Features for responsive Web design
On May 18, 2012, at 5:19 PM, Kornel Lesiński wrote: On Fri, 18 May 2012 20:24:00 +0100, André Luís andreluis...@gmail.com wrote: Make no mistake; this is not a pride or attachment thing, this is a knowing the reasons thing. I personally don't think picture answers things well enough, nor do I think srcset does. Not for general use cases - but for specific one-off use cases, each has benefits. Absolutely. And from what I read (and I admit not reading the entire archive of messages, but still, prefer to say my piece anyway) the main concern about picture was the potencial verbosity. Instead of trying to solve this issue, it got discarded. picture in its current form is unable to support bandwidth-based negotiation well (and that's not simply a matter of adding bandwidth media query) and has no mechanism to specify scaling factor for intrinsic sizes of images. Is there currently any documentation explaining how bandwidth is better handled by `srcset`? Seeing as any discussion around bandwidth is almost entirely theoretical, I have a hard time understanding where bandwidth concerns preclude one approach or the other. There’s a case to be made that few people implementing any form of “responsive images” solution will find a need to rely on an image’s intrinsic width, as doing so effectively negates any flexibility to begin with, which is almost entirely the point of either solution. This is a valid point, however, and very likely something that we could solve on the implementor’s side. There’s no prior precedent this sort of thing—there’s no reason we can’t find a way to preserve an image’s intrinsic width using `picture`. I wonder if simply adding `width` and `height` attributes on the element (similar to `img`) might solve this, in the event that the author wants to rely on an intrinsic size instead of CSS? IMHO those are pretty serious drawbacks that limit its functionality, which is much worse than ugly, but gets job done state of srcset. There are two categories of use-cases (art-directed and dpi/optimization) and picture is suited for only one of them, so please don't frame the decision as discarding of a perfectly good solution, as it wasn't. srcset addresses both dpi/optimisation and art-directed use-cases. It has its own problems, such as confusing microsyntax, so suggestions how to improve this are welcome. Lamenting picture and accusing WHATWG of wrongdoing is not productive. André didn’t seem to claim any loyalty to one solution or the other and, unless I’ve missed something earlier in the thread, certainly didn’t accuse anyone of “wrongdoing.” You’ve jumped to an oddly defensive place here, and that only reinforces an “us vs. them” perception that I’m certain we’d all prefer to move away from. I know I would. If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. This is where I assumed we would be working with you, and I continue to hope that we can. I’d really prefer there not be “sides” in this, rather than all of us seeking the best possible solution. If you feel `picture` could have potential given improvements on the UA end, well, that’s what we’re here for—your input, and your collective expertise. If we can bring `picture` in line with what implementors have in mind while preserving something close to the markup pattern authors prefer, we’ll have a solution that benefits everyone equally. I've tried to raise those issues on the Responsive Images group's mailinglist, but got no constructive feedback. We were admonished in an earlier thread for using the RICG’s mailing list to work in a vacuum (though it was seldom used, and any meaningful conclusions were published to the RICG). If this is the correct forum for these ongoing discussions, it’s likely best that we keep it here. -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On Mon, 21 May 2012 19:36:22 -0500, Mathew Marquis m...@matmarquis.com wrote: picture in its current form is unable to support bandwidth-based negotiation well (and that's not simply a matter of adding bandwidth media query) and has no mechanism to specify scaling factor for intrinsic sizes of images. Is there currently any documentation explaining how bandwidth is better handled by `srcset`? Seeing as any discussion around bandwidth is almost entirely theoretical, I have a hard time understanding where bandwidth concerns preclude one approach or the other. No, and bandwidth proposal for srcset isn't fleshed out yet. My — theoretical — take on this is that it's easier and safer to declare image sizes (e.g. in KB) and let UA figure out which ones it wants, than to add a bandwidth media query. Reasons are: - MQ model of matching current state is not suited for variable thing like bandwidth. - MQ would require somehow explicitly quantifying bandwidth, e.g. in mbps, and exposing that accurately seems to me harder than having less exposed/less sophisticated logic in UAs like picking smallest images when UA is on 2G mobile network. UA could experiment with different mechanisms and refine their algorithms over time. Explicit bandwidth negotiation may need to wait for green light from implementers. There's a risk that if initial solution is implemented poorly, authors will be forced to use fake/exaggerated values to get desired behavior, and that will poison the feature. I hope that image resolution negotiation (1x/2x) may be a testbed for bandwidth negotiation. It can be safely assumed that 2x images are significantly larger than 1x images, so bandwidth-constrained UAs can opt to always download 1x images. If it turns out that this is very useful, and that 1x images are still too large, then we may add more features for bandwidth negotiation. Or perhaps bandwidth will increase fast enough that it won't be a significant problem by the time implementations reach users, or maybe high-dpi screens will become popular enough that 1x will become de-facto a low-bandwidth version, etc. There’s a case to be made that few people implementing any form of “responsive images” solution will find a need to rely on an image’s intrinsic width, as doing so effectively negates any flexibility to begin with, which is almost entirely the point of either solution. I don't understand how reliance on intrinsic size negates flexibility. There’s no prior precedent this sort of thing—there’s no reason we can’t find a way to preserve an image’s intrinsic width using `picture`. I wonder if simply adding `width` and `height` attributes on the element (similar to `img`) might solve this, in the event that the author wants to rely on an intrinsic size instead of CSS? I think that is a very good idea. Having option to do so is good for performance, as it avoids reflows. -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On 19 May 2012 00:37, Kornel Lesiński kor...@geekhood.net wrote:
On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox m...@matthewwilcox.com
wrote:
picture in its current form is unable to support bandwidth-based
negotiation well
By all accounts no solution proposed can do this. This is not a
picture only problem.
srcset allows UA to pick any image density regardless of actual screen
density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download
1x images, instead of 2x.
Yes indeed, but the problem is not about srcset, picture or anything
else: it's that, as has been pointed out repeatedly to those of us
asking about bandwidth media queries, the browser simply can't do
reliable bandwidth detection. That effects srcset as much as anything
else. So while technically srcset allows for this, the browser itself
does't, so it can never be used in the manner you're describing.
UAs are also free to download 1x image first, and then 2x image after
onload, etc. Declarative nature of descriptors, as opposed to imperative
MQs, allows UAs to innovate in this area and come up with new uses that
authors didn't predict/express in MQ.
This would be no better than current JS approaches, in fact making it
worse by adding to the page load size rather than optimising it.
The syntax allows addition of KB descriptor later, which — assuming UAs
will figure out how to measure actual bandwidth well enough — will allow
even more sophisticated selection based on file size (rather than only 1x/2x
scale factors which are only a proxy for the file size).
As above; this seems set not to happen. Besides, how is it going to
know the file size unless you explicitly state it in the srcset
somewhere?
(and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic sizes
of images.
Not actually sure what intrinsic sizes of images means.
A default size of the image when you don't specify any size in HTML/CSS.
Ah, OK thanks :) I do not ever set intrinsic sizes, and nor does any
site I have seen that is responsive in nature. Precisely because it
has no meaning or use in a responsive site.
To take advantage of 200dpi displays you need to tell UA to render a X px
image at X/2 CSS px. Explicit width/height breaks adaptive mechanism.
Or you do what we do now and supply a double resolution image and set
it to a given CSS size. Or just any old size, from my experience of
the iPad3 you don't actually need to be that specific, just get an
oversized image and let it shrink a bit and it holds up well.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
True. An URI template can be added later to either solution.
I'd like to see idea's on how this might work.
The current URI template proposal is limited. I've pointed out few cases for
which a single global set of breakpoints is not sufficient. I'd be nice if
you tried to extend the proposal to support those cases as well (e.g. {case}
→ {case:category} and define breakpoints per category such as 'sidebar',
'gravatar', etc.)
All solutions are limited. The more I work on this the more convinced
I am that the nature or HTML and the layout system makes any truly
efficient solution impossible.
I actually prefer the limits of meta than any others simply because
meta does not postpone the issues until a re-design. meta is the
one and only solution I have seen that does not in some way
contaminate the mark-up with values dependent on the current design.
The price for that is less efficient image compression.
I can't see how to extend it as you're suggesting without also falling
to the same presentational properties embeded problem that picture
and srcset fall into. And that to me is a no-go. We already have
srcset if that's the compromise we want to make.
And meta breakpoint has same limitations for DPI adaptation as source
media.
There are two categories of use-cases (art-directed and
dpi/optimization) and picture is suited for only one of them, so
please don't frame the decision as discarding of a perfectly good
solution, as it wasn't.
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
not understand your argument.
picture
source src=200px media=(min-device-pixel-ratio:2)
source src=100px
/picture
This will only choose between large pixelated image and small pixelated
image, and will not make use of high display density.
On it's own you're right. But no-one actually builds a site like that.
If you're doing a fluid responsive site you've got img {
max-width:100% } in there, and in that case you do actually take
advantage of the high DPI.
I've explained it in more detail previously (using srcset as an example, but
it all applies to
Re: [whatwg] Features for responsive Web design
On 19 maj 2012, at 10:46, Matthew Wilcox m...@matthewwilcox.com wrote:
On 19 May 2012 00:37, Kornel Lesi��ski kor...@geekhood.net wrote:
On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox m...@matthewwilcox.com
wrote:
picture in its current form is unable to support bandwidth-based
negotiation well
By all accounts no solution proposed can do this. This is not a
picture only problem.
srcset allows UA to pick any image density regardless of actual screen
density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download
1x images, instead of 2x.
Yes indeed, but the problem is not about srcset, picture or anything
else: it's that, as has been pointed out repeatedly to those of us
asking about bandwidth media queries, the browser simply can't do
reliable bandwidth detection. That effects srcset as much as anything
else. So while technically srcset allows for this, the browser itself
does't, so it can never be used in the manner you're describing.
iPhone knows when it's on GPRS/EDGE, so it can implement logic exactly as I've
described it.
What it doesn't know is exact numerical value representing current bandwidth
and latency.
UAs are also free to download 1x image first, and then 2x image after
onload, etc. Declarative nature of descriptors, as opposed to imperative
MQs, allows UAs to innovate in this area and come up with new uses that
authors didn't predict/express in MQ.
This would be no better than current JS approaches, in fact making it
worse by adding to the page load size rather than optimising it.
The point is UA can do whatever gives better experience. UAs can innovate in
this area. For example phones know when they're on expensive roaming connection
and always download lowest-res images, without needing authors to add
(bandwidth-cost:expensive) MQ.
The syntax allows addition of KB descriptor later, which ― assuming UAs
will figure out how to measure actual bandwidth well enough ― will allow
even more sophisticated selection based on file size (rather than only 1x/2x
scale factors which are only a proxy for the file size).
As above; this seems set not to happen. Besides, how is it going to
know the file size unless you explicitly state it in the srcset
somewhere?
Setting explicit filesize may be an option. With current spec UA can safely
assume that 1x image is smaller than 2x.
(and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic sizes
of images.
Not actually sure what intrinsic sizes of images means.
A default size of the image when you don't specify any size in HTML/CSS.
Ah, OK thanks :) I do not ever set intrinsic sizes, and nor does any
site I have seen that is responsive in nature. Precisely because it
has no meaning or use in a responsive site.
intrinsic size is the one you don't set. Size in img width or CSS width:
overrides intrinsic size.
To take advantage of 200dpi displays you need to tell UA to render a X px
image at X/2 CSS px. Explicit width/height breaks adaptive mechanism.
Or you do what we do now and supply a double resolution image and set
it to a given CSS size.
That requires relatively large amount of effort ― putting image sizes for all
breakpoints in CSS, with same media queries, and ensuring you have unique
selector for the image.
That's 5-10 lines of code for what you get with mere 2 characters in srcset.
And when intrinsic size is usable you can use it for images with variable size
(e.g. known width, but height dependent on aspect ratio of the image)
Or just any old size, from my experience of
the iPad3 you don't actually need to be that specific, just get an
oversized image and let it shrink a bit and it holds up well.
That is true for devices which use zoom a lot, but may be suboptimal on
desktops.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
True. An URI template can be added later to either solution.
I'd like to see idea's on how this might work.
Just throwing an idea here:
img srcset=gravatar?s={grsize}
style
@breakpoint grsize:80;
@media (max-width:320px) {
@breakpoint grsize:40;
}
/style
I'm not sure about using style, as it cannot work in external CSS (we can't
ask UAs to wait).
However declaration may need more syntax than just meta to allow separate
groups of breakpoints.
And meta breakpoint has same limitations for DPI adaptation as source
media.
There are two categories of use-cases (art-directed and
dpi/optimization) and picture is suited for only one of them, so
please don't frame the decision as discarding of a perfectly good
solution, as it wasn't.
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
Re: [whatwg] Features for responsive Web design
On 18 May 2012 22:19, Kornel Lesiński kor...@geekhood.net wrote: On Fri, 18 May 2012 20:24:00 +0100, André Luís andreluis...@gmail.com wrote: If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. Thank you, that was helpful. I'm trying to steer the overwhelming amount of messages on the topic both here, online and on that mailing-list (recently joined). This will help me think and mature about some possible theories. I've tried to raise those issues on the Responsive Images group's mailinglist, but got no constructive feedback. People are already spread too thin on this... I myself am struggling to keep up with the current present status of things. :-\ -- André Luís -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On Sat, May 19, 2012 at 2:46 AM, Matthew Wilcox m...@matthewwilcox.com wrote: On 19 May 2012 00:37, Kornel Lesiński kor...@geekhood.net wrote: On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox m...@matthewwilcox.com wrote: picture in its current form is unable to support bandwidth-based negotiation well By all accounts no solution proposed can do this. This is not a picture only problem. srcset allows UA to pick any image density regardless of actual screen density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download 1x images, instead of 2x. Yes indeed, but the problem is not about srcset, picture or anything else: it's that, as has been pointed out repeatedly to those of us asking about bandwidth media queries, the browser simply can't do reliable bandwidth detection. That effects srcset as much as anything else. So while technically srcset allows for this, the browser itself does't, so it can never be used in the manner you're describing. I'm not sure where you got that idea; no one has said that bandwidth detection is impossible. We've merely said that it's *hard*, and it involves much more than a simple what's the instantaneous bandwidth right now?. Opera Turbo, for example, has high/low bandwidth detection for deciding what behavior to use. It was very difficult to get it right, but I presume they've settled on a decent solution now. *Because* it's hard, we shouldn't put the problem in the hands of devs. It's better to solve it a handful of times in browsers, than to expect ten thousand individual developers to all solve the problem correctly. UAs are also free to download 1x image first, and then 2x image after onload, etc. Declarative nature of descriptors, as opposed to imperative MQs, allows UAs to innovate in this area and come up with new uses that authors didn't predict/express in MQ. This would be no better than current JS approaches, in fact making it worse by adding to the page load size rather than optimising it. No, it's definitely better, because, as already stated, the browser can make these sorts of decisions intelligently. Grabbing the cheapest assets for a fast load then swapping them out when a slow load is less noticeable is a smart decision if the bandwidth supports it. The syntax allows addition of KB descriptor later, which — assuming UAs will figure out how to measure actual bandwidth well enough — will allow even more sophisticated selection based on file size (rather than only 1x/2x scale factors which are only a proxy for the file size). As above; this seems set not to happen. Besides, how is it going to know the file size unless you explicitly state it in the srcset somewhere? I'm not sure I understand the question. He's talking about a descriptor that lets you explicitly state the file size. ~TJ
Re: [whatwg] Features for responsive Web design
Am 15.05.2012 09:28 schrieb Ian Hickson: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset.
Re: [whatwg] Features for responsive Web design
On May 18, 2012, at 3:16 AM, Markus Ernst derer...@gmx.ch wrote: Am 15.05.2012 09:28 schrieb Ian Hickson: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If dynamically manipulating the items in srcset is useful, we can add a DOM API (similar to classList or style for manipulating the lists of items found in class and style attributes respectively). Cheers, Maciej
Re: [whatwg] Features for responsive Web design
On 2012-05-18 12:30, Maciej Stachowiak wrote: On May 18, 2012, at 3:16 AM, Markus Ernstderer...@gmx.ch wrote: Am 15.05.2012 09:28 schrieb Ian Hickson: img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h Re-reading most parts of the last day's discussions, 2 questions come to my mind that I have the impression have not been pointed out very clearly so far: 1. Are there other cases in HTML where an attribute value contains more than one URI? 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed frompicture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If dynamically manipulating the items in srcset is useful, we can add a DOM API (similar to classList or style for manipulating the lists of items found in class and style attributes respectively). ...which of course means that it stops being simpler. I think it would be worthwhile to combine elements form both proposals; in particular to avoid the microsyntax and use proper markup instead. Best regards, Julian
Re: [whatwg] Features for responsive Web design
On 05/18/2012 12:16 PM, Markus Ernst wrote: 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. Are there any use cases that benefit from scripting here? I wouldn't be surprised if there are, but whoever thinks they will have such use cases should state them clearly so that the design takes them into account.
Re: [whatwg] Features for responsive Web design
Am 18.05.2012 13:09 schrieb James Graham: On 05/18/2012 12:16 PM, Markus Ernst wrote: 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. Are there any use cases that benefit from scripting here? I wouldn't be surprised if there are, but whoever thinks they will have such use cases should state them clearly so that the design takes them into account. One use case is manipulating content in a contenteditable area, e.g. in a Rich text editor. A JS-based online editor such as TinyMCE or KTML may want to offer some kind of GUI for alternative sources. I am not sure whether this is a very important use case, as authors of online editors are usually JS experts and capable of writing complex string operations, too; but I assume the use case is at least valid.
Re: [whatwg] Features for responsive Web design
On 5/18/12 3:16 AM, Markus Ernst wrote: 1. Are there other cases in HTML where an attribute value contains more than one URI? * The archive attribute of applet (comma-separated list of URIs) * The ping attribute of a (space-separated list of URIs) * The style attribute (which can, e.g., set both border-image and background-image). There might be others, but this is off the top of my head. 2. Have there been thoughts on the scriptability of @srcset? While sources can be added to resp. removed from picture easily with standard DOM methods, it looks to me like this would require complex string operations for @srcset. If one really wanted to, this could be handled by having .srcset be a list object, etc. Might still be a bit of a pain, of course. -Boris
Re: [whatwg] Features for responsive Web design
On Fri, May 18, 2012 at 5:51 AM, Julian Reschke julian.resc...@gmx.dewrote: ...which of course means that it stops being simpler. No, it means nothing of the sort. An API to access this would introduce none of the problems with the multi-element approach; it would be simple and straightforward to do. I think it would be worthwhile to combine elements form both proposals; in particular to avoid the microsyntax and use proper markup instead. Only if there are actual problems solved by doing so, which there don't seem to be. Instead, people seem to be hunting for excuses to use parts of the other proposal just for the sake of using them, not to solve any actual problem. (That's not a good reason to do it? Hold on, let me try to come up with another...) -- Glenn Maynard
Re: [whatwg] Features for responsive Web design
On 18 May 2012 15:28, Glenn Maynard gl...@zewt.org wrote: Only if there are actual problems solved by doing so, which there don't seem to be. Instead, people seem to be hunting for excuses to use parts of the other proposal just for the sake of using them, not to solve any actual problem. (That's not a good reason to do it? Hold on, let me try to come up with another...) Perhaps but I think the real problem may be this... The other proposals have been knocked around by various parties who wanted to solve a problem, they had time to discuss it, digest it and see how it grew to meet their needs. Now srcset was dropped on them as a surprise, they're still trying to understand it, they keep being re-assured it meets their needs but no-one who developed the srcset proposal has really come out and explained to them how it meets their needs so they keep asking questions... I wasn't involved in the picture discussion so have no particular attachment to it, I think both picture and srcset have problems in that they move breakpoints into the markup, srcset's microsyntax is pretty horrible and the picture syntax has issues too. The thing that really astounds me about the responsive/adaptive images hullabaloo is: The responsive image problem has been discussed for at least a year with plenty of ideas / workarounds floated around (only got to look a slidedecks form Mobilism, Breaking Development etc. for this) yet WHATWG seemed pretty unaware of it. When WHATWG did decide to do something about it they just dropped it on the people who wanted it by surprise without talking to them first even just to say this is our proposal, this is how we think it solves your problem, what do you think? I can understand why some of the authors are upset and I still thing the srcset needs explaining clearly rather than them having to chew through the spec. Cheers Andy
Re: [whatwg] Features for responsive Web design
You have to understand that the picture idea was not the result of idle thought. We went through a *lot* of thinking to reach that point, and so it's not actually an attachement to that idea so much as *we know* that idea inside out, what it does, what it doesn't, and why it's like that. We had thought about it from a lot of angles, thrown everything we could at it, and determined that picture was the most robust, familiar, and flexible solution out of half a dozen possibilities - each of which was under similar scrutiny. Then along comes srcset - which has not been subject to the same scrutiny by that group. So *of course* it's getting questioned hard, and *of course* picture is being held as answering the needs best. Until srcset has been properly discussed, inspected, picked apart, and subjected to the same level of scrutiny as picture was, it's not the trusted thing that picture is. Make no mistake; this is not a pride or attachment thing, this is a knowing the reasons thing. I personally don't think picture answers things well enough, nor do I think srcset does. Not for general use cases - but for specific one-off use cases, each has benefits. Personally I'm coming around to a refined version of the srcset idea rather than picture after some clear explanation. But, again, I only see it being appropriate for one-off use cases - singular special-case images within a page. I don't think anyone has yet come up with a good enough general purpose solution that avoids contaminating the mark-up with design-dependent properties which will all be invalid come a re-design - that to me is not acceptable. The closest I've seen that could possibly address that limitation is meta variables, but that has it's own issues and does not answer the same use-cases as srcset or picture. -Matt On 18 May 2012 16:40, Andy Davies dajdav...@gmail.com wrote: On 18 May 2012 15:28, Glenn Maynard gl...@zewt.org wrote: Only if there are actual problems solved by doing so, which there don't seem to be. Instead, people seem to be hunting for excuses to use parts of the other proposal just for the sake of using them, not to solve any actual problem. (That's not a good reason to do it? Hold on, let me try to come up with another...) Perhaps but I think the real problem may be this... The other proposals have been knocked around by various parties who wanted to solve a problem, they had time to discuss it, digest it and see how it grew to meet their needs. Now srcset was dropped on them as a surprise, they're still trying to understand it, they keep being re-assured it meets their needs but no-one who developed the srcset proposal has really come out and explained to them how it meets their needs so they keep asking questions... I wasn't involved in the picture discussion so have no particular attachment to it, I think both picture and srcset have problems in that they move breakpoints into the markup, srcset's microsyntax is pretty horrible and the picture syntax has issues too. The thing that really astounds me about the responsive/adaptive images hullabaloo is: The responsive image problem has been discussed for at least a year with plenty of ideas / workarounds floated around (only got to look a slidedecks form Mobilism, Breaking Development etc. for this) yet WHATWG seemed pretty unaware of it. When WHATWG did decide to do something about it they just dropped it on the people who wanted it by surprise without talking to them first even just to say this is our proposal, this is how we think it solves your problem, what do you think? I can understand why some of the authors are upset and I still thing the srcset needs explaining clearly rather than them having to chew through the spec. Cheers Andy
Re: [whatwg] Features for responsive Web design
On Fri, May 18, 2012 at 2:53 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/18/12 3:16 AM, Markus Ernst wrote: 1. Are there other cases in HTML where an attribute value contains more than one URI? * The archive attribute of applet (comma-separated list of URIs) * The ping attribute of a (space-separated list of URIs) * The style attribute (which can, e.g., set both border-image and background-image). There might be others, but this is off the top of my head. HTML4's @profile is a whitespace-separated URI list: http://www.w3.org/TR/html4/struct/global.html#adef-profile RDFa's @property and @typeof are whitespace-separated lists of CURIEs: http://www.w3.org/TR/rdfa-in-html/#extensions-to-the-html5-syntax http://www.w3.org/TR/rdfa-core/#s_syntax -- Benjamin Hawkes-Lewis
Re: [whatwg] Features for responsive Web design
On Fri, May 18, 2012 at 1:54 PM, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On Fri, May 18, 2012 at 2:53 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/18/12 3:16 AM, Markus Ernst wrote: 1. Are there other cases in HTML where an attribute value contains more than one URI? * The archive attribute of applet (comma-separated list of URIs) * The ping attribute of a (space-separated list of URIs) * The style attribute (which can, e.g., set both border-image and background-image). There might be others, but this is off the top of my head. HTML4's @profile is a whitespace-separated URI list: http://www.w3.org/TR/html4/struct/global.html#adef-profile RDFa's @property and @typeof are whitespace-separated lists of CURIEs: not only CURIEs, they can also be full URIs. Steph. http://www.w3.org/TR/rdfa-in-html/#extensions-to-the-html5-syntax http://www.w3.org/TR/rdfa-core/#s_syntax -- Benjamin Hawkes-Lewis
Re: [whatwg] Features for responsive Web design
On 18 May 2012 17:29, Matthew Wilcox m...@matthewwilcox.com wrote: You have to understand that the picture idea was not the result of idle thought. We went through a *lot* of thinking to reach that point, and so it's not actually an attachement to that idea so much as *we know* that idea inside out, what it does, what it doesn't, and why it's like that. We had thought about it from a lot of angles, thrown everything we could at it, and determined that picture was the most robust, familiar, and flexible solution out of half a dozen possibilities - each of which was under similar scrutiny. Then along comes srcset - which has not been subject to the same scrutiny by that group. So *of course* it's getting questioned hard, and *of course* picture is being held as answering the needs best. Until srcset has been properly discussed, inspected, picked apart, and subjected to the same level of scrutiny as picture was, it's not the trusted thing that picture is. Make no mistake; this is not a pride or attachment thing, this is a knowing the reasons thing. I personally don't think picture answers things well enough, nor do I think srcset does. Not for general use cases - but for specific one-off use cases, each has benefits. Absolutely. And from what I read (and I admit not reading the entire archive of messages, but still, prefer to say my piece anyway) the main concern about picture was the potencial verbosity. Instead of trying to solve this issue, it got discarded. There are proposals to deal with the media-query only once to activate a specific page-global profile. It could support both ways: via media attribute in picture or source elements or via a detection made on the head. Anyway, I'll have to re-read the archive of past conversations to be able to formulate a complete proposal. But those efforts anyone of us might take need to be respectfully considered just as srcset has. And not discarded straight away. -- André Luís
Re: [whatwg] Features for responsive Web design
On Fri, 18 May 2012 20:24:00 +0100, André Luís andreluis...@gmail.com wrote: Make no mistake; this is not a pride or attachment thing, this is a knowing the reasons thing. I personally don't think picture answers things well enough, nor do I think srcset does. Not for general use cases - but for specific one-off use cases, each has benefits. Absolutely. And from what I read (and I admit not reading the entire archive of messages, but still, prefer to say my piece anyway) the main concern about picture was the potencial verbosity. Instead of trying to solve this issue, it got discarded. picture in its current form is unable to support bandwidth-based negotiation well (and that's not simply a matter of adding bandwidth media query) and has no mechanism to specify scaling factor for intrinsic sizes of images. IMHO those are pretty serious drawbacks that limit its functionality, which is much worse than ugly, but gets job done state of srcset. There are two categories of use-cases (art-directed and dpi/optimization) and picture is suited for only one of them, so please don't frame the decision as discarding of a perfectly good solution, as it wasn't. srcset addresses both dpi/optimisation and art-directed use-cases. It has its own problems, such as confusing microsyntax, so suggestions how to improve this are welcome. Lamenting picture and accusing WHATWG of wrongdoing is not productive. If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. I've tried to raise those issues on the Responsive Images group's mailinglist, but got no constructive feedback. -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
Make no mistake; this is not a pride or attachment thing, this is a knowing the reasons thing. I personally don't think picture answers things well enough, nor do I think srcset does. Not for general use cases - but for specific one-off use cases, each has benefits. Absolutely. And from what I read (and I admit not reading the entire archive of messages, but still, prefer to say my piece anyway) the main concern about picture was the potencial verbosity. Instead of trying to solve this issue, it got discarded. picture in its current form is unable to support bandwidth-based negotiation well By all accounts no solution proposed can do this. This is not a picture only problem. (and that's not simply a matter of adding bandwidth media query) and has no mechanism to specify scaling factor for intrinsic sizes of images. Not actually sure what intrinsic sizes of images means. IMHO those are pretty serious drawbacks that limit its functionality, which is much worse than ugly, but gets job done state of srcset. I see no difference between the end result of either syntax. Both approaches fail utterly in abstracting the query from the mark-up, which means both approaches are suited only to individual images. Should the design of the site change at any point, both solutions break completely. It's a major problem I pointed out with picture over in the CG. Srcset is no better in this regard. There are two categories of use-cases (art-directed and dpi/optimization) and picture is suited for only one of them, so please don't frame the decision as discarding of a perfectly good solution, as it wasn't. Picture dealt with both of these by simple use of the pixel density media query - i.e, in exactly the same way CSS already does it. I do not understand your argument. srcset addresses both dpi/optimisation and art-directed use-cases. It has its own problems, such as confusing microsyntax, so suggestions how to improve this are welcome. Agreed, and already underway. Lamenting picture and accusing WHATWG of wrongdoing is not productive. With respect, finding out where there have been fuck-ups is in everyone's interest if we want to get the most out of the process and communities who are all trying to better the web. If you'd like to see picture proposal succeed, then please help fixing its drawbacks. I've said I don't. No part of my argument said I condone continued argument for supporting picture - I in fact said I don't like it and haven't liked it since it was in the CG. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. I've tried to raise those issues on the Responsive Images group's mailinglist, but got no constructive feedback. That last bit is annoying. Some of the key players in that group seem to ignore stuff since they decided picture was finished - I've had the same problem myself. -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox
m...@matthewwilcox.com wrote:
picture in its current form is unable to support bandwidth-based
negotiation well
By all accounts no solution proposed can do this. This is not a
picture only problem.
srcset allows UA to pick any image density regardless of actual screen
density, so e.g. Safari on iPhone 4 on GPRS/EDGE connection could download
1x images, instead of 2x.
UAs are also free to download 1x image first, and then 2x image after
onload, etc. Declarative nature of descriptors, as opposed to imperative
MQs, allows UAs to innovate in this area and come up with new uses that
authors didn't predict/express in MQ.
The syntax allows addition of KB descriptor later, which — assuming UAs
will figure out how to measure actual bandwidth well enough — will allow
even more sophisticated selection based on file size (rather than only
1x/2x scale factors which are only a proxy for the file size).
(and that's not simply a matter of adding bandwidth media
query) and has no mechanism to specify scaling factor for intrinsic
sizes of images.
Not actually sure what intrinsic sizes of images means.
A default size of the image when you don't specify any size in HTML/CSS.
To take advantage of 200dpi displays you need to tell UA to render a X px
image at X/2 CSS px. Explicit width/height breaks adaptive mechanism.
I see no difference between the end result of either syntax. Both
approaches fail utterly in abstracting the query from the mark-up,
which means both approaches are suited only to individual images.
True. An URI template can be added later to either solution.
The current URI template proposal is limited. I've pointed out few cases
for which a single global set of breakpoints is not sufficient. I'd be
nice if you tried to extend the proposal to support those cases as well
(e.g. {case} → {case:category} and define breakpoints per category such as
'sidebar', 'gravatar', etc.)
And meta breakpoint has same limitations for DPI adaptation as source
media.
There are two categories of use-cases (art-directed and
dpi/optimization) and picture is suited for only one of them, so
please don't frame the decision as discarding of a perfectly good
solution, as it wasn't.
Picture dealt with both of these by simple use of the pixel density
media query - i.e, in exactly the same way CSS already does it. I do
not understand your argument.
picture
source src=200px media=(min-device-pixel-ratio:2)
source src=100px
/picture
This will only choose between large pixelated image and small pixelated
image, and will not make use of high display density.
I've explained it in more detail previously (using srcset as an example,
but it all applies to min-device-pixel-ratio: MQ as well)
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036051.html
--
regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On Thu, 17 May 2012 02:29:11 +0100, Jacob Mather jmat...@itsmajax.com wrote: As I said, I understand that it is a hard problem, but the question is, is it the correct problem. There are plenty of reasons not to do it, but is there any actual reason that the approach is less correct than the current proposals? Yes, trading off latency to save bandwidth is definitely an incorrect approach. Bandwidth will keep increasing much faster than latency decreases (and there are hard physical limits to decreasing latency, while bandwidth could go up to infinity). On high-latency high-bandwidth connections (satellite, 3G/4G) it may already be cheaper to download all versions of all images than to wait for CSS to be able to select the right ones to load. Solution that requires page layout for image loading is a step backwards for performance. -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On Thu, May 17, 2012 at 3:26 PM, Maciej Stachowiak m...@apple.com wrote: On May 16, 2012, at 9:39 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Wed, May 16, 2012 at 10:55 PM, Matthew Wilcox m...@matthewwilcox.com 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). If it does indeed rely on a rendering issue (like the size of the viewport), wouldn't it make more sense to make it a CSS feature? I think that would be less confusing and follow better the established separation of layout in html, styling(/rendering) in CSS. CSS can handle this fine for presentational images (such as CSS background images). But it's not obvious that it's the best way to influence selection of content images references from img. Content images are meaningful, not just stylistic, so their variants are meaningful too (even if the choice of variant is influenced by presentational issues). Hmm... I'm not actually talking about having the images specified in CSS. I don't actually have a suggestion for how that would look - it seems the list of resources needs to be given in HTML, but the selection between them should be done in CSS. Not sure this helps ... but since we're brainstorming... Silvia.
Re: [whatwg] Features for responsive Web design
On Thu, May 17, 2012 at 7:54 PM, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 17 May 2012 02:29:11 +0100, Jacob Mather jmat...@itsmajax.com wrote: As I said, I understand that it is a hard problem, but the question is, is it the correct problem. There are plenty of reasons not to do it, but is there any actual reason that the approach is less correct than the current proposals? Yes, trading off latency to save bandwidth is definitely an incorrect approach. Bandwidth will keep increasing much faster than latency decreases (and there are hard physical limits to decreasing latency, while bandwidth could go up to infinity). On high-latency high-bandwidth connections (satellite, 3G/4G) it may already be cheaper to download all versions of all images than to wait for CSS to be able to select the right ones to load. Solution that requires page layout for image loading is a step backwards for performance. Maybe the metrics that we are suggesting for resources can help: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12399 . When measuring bytesReceived, downloadTime, and networkWaitTime for resources loaded, it is possible to track available bandwidth and latency and thus find out what type of network connection one is on. This may help with making decisions? Silvia.
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 ja...@cloudfour.com wrote: In the @srcset syntax, I *think* I would end up with something like this: img src=a.png srcset=a-rectangle.png 300w 150h 1x, a-square.png 100w 100h 1x Nope, what you want is this: img src=a-square.png srcset=a-rectangle.png 600w 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 img src=a-square.png srcset=a-rectangle.png 2x 600w 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 Wed, May 16, 2012 at 12:14 AM, Mikko Rantalainen mikko.rantalai...@peda.net wrote: 2012-05-16 03:26 Europe/Helsinki: Tab Atkins Jr.: On Tue, May 15, 2012 at 5:15 PM, Jason Grigsby ja...@cloudfour.com wrote: In the @srcset syntax, I *think* I would end up with something like this: img src=a.png srcset=a-rectangle.png 300w 150h 1x, a-square.png 100w 100h 1x Nope, what you want is this: img src=a-square.png srcset=a-rectangle.png 600w 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 img src=a-square.png srcset=a-rectangle.png 2x 600w 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 10:19 Europe/Helsinki: Tab Atkins Jr.: On Wed, May 16, 2012 at 12:14 AM, Mikko Rantalainen mikko.rantalai...@peda.net wrote: I think that the correct syntax would be img src=a-square.png srcset=a-rectangle.png 2x 600w 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
Tab wrote: I suspect this is simply confusion about the proposal - @srcset handles the art-directed case same as picture, 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
On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com 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 picture 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 p...@mynameispj.com wrote: On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com 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 hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com 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 picture 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 m...@matthewwilcox.com 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 p...@mynameispj.com wrote: On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com 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 hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com 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 picture 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
Note that this is also my major criticism of picture and the reason why I would not use it in the current CG state - and why I've been looking into meta 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 m...@matthewwilcox.com 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 m...@matthewwilcox.com 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 p...@mynameispj.com wrote: On Wed, May 16, 2012 at 5:25 AM, Henri Sivonen hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com 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 hsivo...@iki.fi wrote: On Wed, May 16, 2012 at 2:46 PM, Jeremy Keith jer...@adactio.com 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 picture 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
Henri Sivonen hsivo...@iki.fi 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 picture 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
Le 15/05/12 09:28, Ian Hickson a écrit : img src=face-600-...@1.jpeg alt= src-template=face-%w-%h@%r.jpeg src-versions=600x200x1 600x200x2 200x200x1 [snip] img src=face-600-...@1.jpeg alt= srcset=face-600-...@1.jpeg 600w 200h 1x, face-600-...@2.jpeg 600w 200h 2x, face-icon.png 200w 200h 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. /Daniel -- W3C CSS Working Group, Co-chair
Re: [whatwg] Features for responsive Web design
On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox m...@matthewwilcox.com 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
