Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Hi Mat, >Yeah, this would be a bit tricky in terms of backwards-compatibility, as you said. I feel the gut reaction from a lot of authors would be “I don’t want that text >showing up in some browsers but not others,” then (sadly) omission. It’s hide-able with CSS, as you said, but it would add some complexity. I would have thought a polyfill would handle the hiding. and I am not sure that the possible backward compat issues should deter us from providing a better text alternative method in the longer term. besides thinking about it, providing the alt on the img would suffice until such times that lat text as a child of is supported (if implemented). which removes the need for alt on picture altogether, which is of no use anyway until it is implemented. > > > > > >This seems like a great candidate for `figcaption`, and could be pollyfilled, in a way, through the use of `aria-describedby`. I wouldn’t want to discourage the use of >`alt` tags on either `picture` or the fallback `img`, but — and correct me if I’m wrong — isn’t `aria-describedby` specced to take precedence over the `alt` attribute? >That might be the ideal approach — and even if not, a bit of redundancy may not hurt there. There is one current implenentation [1] (Firefox) of figure/figcation accessibility. this implementation can be illustrated using ARIA. although it does not use ARIA, the acc support is provided through IAccessible2 caption text So the figcaption content labels the figure. Also note that the figcaption has a role=caption (from IA2), but that is not currently defined in ARIA In regards to aria-decribedby it does not override the alt attribute, aria-describedby provides the accessible description, it is not used in accessible name calculation. if aria-labelledby is on an img element it overrides that alt. [1] figcaption http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-43 figure http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-44 regards SteveF On 24 July 2012 16:05, Mathew Marquis wrote: > > On Jul 23, 2012, at 5:38 PM, Steve Faulkner wrote: > > > Hi Mat, > > as I previously previously mentioned, I am concerned about the use of the > > alt attribute on when it would be much better to allow text > > alternatives inside the picture element. > > Some of the advantages are: > > Markup can be used to structure text alternative content. > > The length of the alt text is no longer a constraint, as it is currently > > for assistive tech. > > > > > > > > > > > > > > > > > > > > is there any reason why you think the use of alt attribute on picture is > > preferable to > > > > > > > > alt text > > > > > > > > > > > > > > > > Yeah, this would be a bit tricky in terms of backwards-compatibility, as > you said. I feel the gut reaction from a lot of authors would be “I don’t > want that text showing up in some browsers but not others,” then (sadly) > omission. It’s hide-able with CSS, as you said, but it would add some > complexity. > > > > > note:role=img is just of polyfill purposes. > > > > or > > > > > > > > > > > > > > > > > > > > > > > > caption text > > > > This seems like a great candidate for `figcaption`, and could be > pollyfilled, in a way, through the use of `aria-describedby`. I wouldn’t > want to discourage the use of `alt` tags on either `picture` or the > fallback `img`, but — and correct me if I’m wrong — isn’t > `aria-describedby` specced to take precedence over the `alt` attribute? > That might be the ideal approach — and even if not, a bit of redundancy may > not hurt there. > > > > > I can understand that backwards compatibility may be of concern in the > > first example, but that can be resolved through the use of CSS to clip or > > hide text content if so desired. > > > > regards > > Stevef > > > > > > > > On 23 July 2012 20:06, wrote: > > > >> Send whatwg mailing list submissions to > >>whatwg@lists.whatwg.org > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >>http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > >> or, via email, send a message with subject or body 'help' to > >>whatwg-requ...@lists.whatwg.org > >> > >> You can reach the person managing the list at > >>whatwg-ow...@lists.whatwg.org > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of whatwg
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Jul 23, 2012, at 5:38 PM, Steve Faulkner wrote: > Hi Mat, > as I previously previously mentioned, I am concerned about the use of the > alt attribute on when it would be much better to allow text > alternatives inside the picture element. > Some of the advantages are: > Markup can be used to structure text alternative content. > The length of the alt text is no longer a constraint, as it is currently > for assistive tech. > > > > > > > > > > is there any reason why you think the use of alt attribute on picture is > preferable to > > > > alt text > > > > > > > Yeah, this would be a bit tricky in terms of backwards-compatibility, as you said. I feel the gut reaction from a lot of authors would be “I don’t want that text showing up in some browsers but not others,” then (sadly) omission. It’s hide-able with CSS, as you said, but it would add some complexity. > > note:role=img is just of polyfill purposes. > > or > > > > > > > > > > > > caption text > This seems like a great candidate for `figcaption`, and could be pollyfilled, in a way, through the use of `aria-describedby`. I wouldn’t want to discourage the use of `alt` tags on either `picture` or the fallback `img`, but — and correct me if I’m wrong — isn’t `aria-describedby` specced to take precedence over the `alt` attribute? That might be the ideal approach — and even if not, a bit of redundancy may not hurt there. > > I can understand that backwards compatibility may be of concern in the > first example, but that can be resolved through the use of CSS to clip or > hide text content if so desired. > > regards > Stevef > > > > On 23 July 2012 20:06, wrote: > >> Send whatwg mailing list submissions to >>whatwg@lists.whatwg.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >>http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org >> or, via email, send a message with subject or body 'help' to >>whatwg-requ...@lists.whatwg.org >> >> You can reach the person managing the list at >>whatwg-ow...@lists.whatwg.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of whatwg digest..." >> >> >> When replying to digest messages, please please PLEASE update the subject >> line so it isn't the digest subject line. >> >> Today's Topics: >> >> 1. Re: Media queries, viewport dimensions, srcset and picture >> (Mathew Marquis) >> >> >> -- >> >> Message: 1 >> Date: Mon, 23 Jul 2012 11:39:14 -0400 >> From: Mathew Marquis >> To: whatwg@lists.whatwg.org >> Cc: Florian Rivoal >> Subject: Re: [whatwg] Media queries, viewport dimensions, srcset and >>picture >> Message-ID: >> Content-Type: text/plain; charset=windows-1252 >> >> WHATWG, >> >> The Responsive Images Community Group was recently asked to furnish a >> formal draft proposal for consideration by the HTML WG. I thought it best >> to post it here along with some details, where Ian Hickson has mentioned >> that he?ll be considering this issue again within a few days. >> >> More and more it seems that it?s a waste of effort trying to retrofit the >> original srcset proposal to cover all the use cases of the original >> `picture` proposal. As we attempt to do so, the `srcset` msyntax grows more >> confusing, and shares an increasing amount of overlap with media queries ? >> though with some obvious holes, for example: units other than `px`. To >> those ends, the Responsive Images Community Group has officially published >> a draft proposal based on Florian Rivoal?s proposed compromise ( >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html) >> between the two markup patterns. In this way, `srcset` retains the >> purpose for which it was originally proposed: a terse, easily-implemented >> syntax for switching image sources based on the client resolution. >> >> The draft proposal can be found here: >> http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal >> >> Discussion with the HTML WG can be found here: >> http://lists.w3.org/Archives/Public/public-html/2012Jun/0113.html >> >> ## Proposed Markup >> >> >> >> >> >> >> >> >> The chain of events followed by the above markup pattern are: >> >> 1.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Hi Mat, as I previously previously mentioned, I am concerned about the use of the alt attribute on when it would be much better to allow text alternatives inside the picture element. Some of the advantages are: Markup can be used to structure text alternative content. The length of the alt text is no longer a constraint, as it is currently for assistive tech. is there any reason why you think the use of alt attribute on picture is preferable to alt text note:role=img is just of polyfill purposes. or caption text I can understand that backwards compatibility may be of concern in the first example, but that can be resolved through the use of CSS to clip or hide text content if so desired. regards Stevef On 23 July 2012 20:06, wrote: > Send whatwg mailing list submissions to > whatwg@lists.whatwg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org > or, via email, send a message with subject or body 'help' to > whatwg-requ...@lists.whatwg.org > > You can reach the person managing the list at > whatwg-ow...@lists.whatwg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of whatwg digest..." > > > When replying to digest messages, please please PLEASE update the subject > line so it isn't the digest subject line. > > Today's Topics: > >1. Re: Media queries, viewport dimensions, srcset and picture > (Mathew Marquis) > > > -- > > Message: 1 > Date: Mon, 23 Jul 2012 11:39:14 -0400 > From: Mathew Marquis > To: whatwg@lists.whatwg.org > Cc: Florian Rivoal > Subject: Re: [whatwg] Media queries, viewport dimensions, srcset and > picture > Message-ID: > Content-Type: text/plain; charset=windows-1252 > > WHATWG, > > The Responsive Images Community Group was recently asked to furnish a > formal draft proposal for consideration by the HTML WG. I thought it best > to post it here along with some details, where Ian Hickson has mentioned > that he?ll be considering this issue again within a few days. > > More and more it seems that it?s a waste of effort trying to retrofit the > original srcset proposal to cover all the use cases of the original > `picture` proposal. As we attempt to do so, the `srcset` msyntax grows more > confusing, and shares an increasing amount of overlap with media queries ? > though with some obvious holes, for example: units other than `px`. To > those ends, the Responsive Images Community Group has officially published > a draft proposal based on Florian Rivoal?s proposed compromise ( > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html) > between the two markup patterns. In this way, `srcset` retains the > purpose for which it was originally proposed: a terse, easily-implemented > syntax for switching image sources based on the client resolution. > > The draft proposal can be found here: > http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal > > Discussion with the HTML WG can be found here: > http://lists.w3.org/Archives/Public/public-html/2012Jun/0113.html > > ## Proposed Markup > > > > > > > > > The chain of events followed by the above markup pattern are: > > 1. If the `picture` element is unsupported, the `img` contained therein is > shown as fallback markup. > 2. If picture is supported, use `media` attributes to determine which > source element best suits the user?s viewport, following the same logic as > `video`?s specced use of `media` attributes. > 3. Once an appropriate source element has been selected, the `srcset` > attribute determines which image source is best suited to the user?s screen > resolution. If only a single resolution is necessary, the `src` attribute > will function as expected, instead. > > In terms of selecting a source element, this markup leverages all the > strengths of media queries ? the syntax created for this very purpose ? to > handle the ?art direction? use case. > > However, as has been detailed at length here and elsewhere, > `device-pixel-ratio` media queries are poorly suited towards these > decisions. As an author, using vendor-prefixed `min-device-pixel-ratio` > media queries in the example above would involve a massive amount of text > and twice as many source elements. This could get unwieldy for authors very > quickly, a concern voiced numerous times in these ongoing discussions. > Further, implementation of MQ-based resolution switching is far more > difficult on the UA side: a very real concern. > > Once we?ve used
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
WHATWG, The Responsive Images Community Group was recently asked to furnish a formal draft proposal for consideration by the HTML WG. I thought it best to post it here along with some details, where Ian Hickson has mentioned that he’ll be considering this issue again within a few days. More and more it seems that it’s a waste of effort trying to retrofit the original srcset proposal to cover all the use cases of the original `picture` proposal. As we attempt to do so, the `srcset` msyntax grows more confusing, and shares an increasing amount of overlap with media queries — though with some obvious holes, for example: units other than `px`. To those ends, the Responsive Images Community Group has officially published a draft proposal based on Florian Rivoal’s proposed compromise ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036160.html ) between the two markup patterns. In this way, `srcset` retains the purpose for which it was originally proposed: a terse, easily-implemented syntax for switching image sources based on the client resolution. The draft proposal can be found here: http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal Discussion with the HTML WG can be found here: http://lists.w3.org/Archives/Public/public-html/2012Jun/0113.html ## Proposed Markup The chain of events followed by the above markup pattern are: 1. If the `picture` element is unsupported, the `img` contained therein is shown as fallback markup. 2. If picture is supported, use `media` attributes to determine which source element best suits the user’s viewport, following the same logic as `video`’s specced use of `media` attributes. 3. Once an appropriate source element has been selected, the `srcset` attribute determines which image source is best suited to the user’s screen resolution. If only a single resolution is necessary, the `src` attribute will function as expected, instead. In terms of selecting a source element, this markup leverages all the strengths of media queries — the syntax created for this very purpose — to handle the “art direction” use case. However, as has been detailed at length here and elsewhere, `device-pixel-ratio` media queries are poorly suited towards these decisions. As an author, using vendor-prefixed `min-device-pixel-ratio` media queries in the example above would involve a massive amount of text and twice as many source elements. This could get unwieldy for authors very quickly, a concern voiced numerous times in these ongoing discussions. Further, implementation of MQ-based resolution switching is far more difficult on the UA side: a very real concern. Once we’ve used media queries to determine the most appropriate source element, srcset’s originally intended usage becomes absolutely ideal for our purposes: simply determining the appropriate image source for a user’s resolution. It’s worth noting that this example is, in fact, the most convoluted this element can ever be. This pattern in no way precludes the use of srcset on an `img` tag for simply preforming resolution switching, nor does it preclude the use of `picture` as originally proposed for the “art direction”/screen size use cases, with `src` in source elements rather than `srcset`. ## Bandwidth We cannot reliably make assumptions about bandwidth based on client capabilities — a MacBook Pro with a Retina display may be tethered to a 3G phone; a high-resolution mobile device is as likely to be connected to WiFi as it is an EDGE connection. Based on previous discussion on the list, I think we’re largely in agreement that bandwidth decisions are best left to the browser. 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. 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. 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. I think `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. It seems `srcset` won’t be going anywhere, and that’s not an indictment. There i
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Tue, 03 Jul 2012 03:24:50 +0200, Andy Davies wrote: In Scott Jehl's latest example of a responsive image polyfill (https://github.com/scottjehl/picturefill), he produced a variation that allows a non-retinae image to be downloaded by default with the user having the ability to then choose the download the retina version of image if then wanted. Which ever solution to the responsive image eventually get's incorporated into the spec I think we need to account for this behaviour at the user-agent level i.e. if the UA decides to download a non-retina image because the user is on a cell network, then they need a way of easily choosing to download the retina image if they want. This seems perfectly compatible with srcset, both in the original version and in my proposed variant. Neither require the UA to have such a mechanism, but both allow it to, should the UA vendor agree that it is a good idea. - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
In Scott Jehl's latest example of a responsive image polyfill (https://github.com/scottjehl/picturefill), he produced a variation that allows a non-retinae image to be downloaded by default with the user having the ability to then choose the download the retina version of image if then wanted. Which ever solution to the responsive image eventually get's incorporated into the spec I think we need to account for this behaviour at the user-agent level i.e. if the UA decides to download a non-retina image because the user is on a cell network, then they need a way of easily choosing to download the retina image if they want. Any thoughts? Andy
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 29, 2012, at 6:49 AM, Florian Rivoal wrote: >> * It has two attributes that could easily be confused as doing the >> same job. There's little clear logic as to why they're split, from an >> authors viewpoint. > > It might be confusing, but there is logic in the splitting: > > srcset="." lets you describe the properties of a set of > equivalent images, and the browser decides which > one is more appropriate given the environment. > > should be displayed based on the properties of the medium > you're displaying on. > This makes perfect sense, and certainly seems to cover all of the potential use cases of `picture` and `srcset` alone — even so far as preserving the brevity of the original proposal, in cases where that markup pattern is most appropriate. Is it fair to say that `srcset` will likely remain drafted as a solution to the resolution issue alone, and that `picture` with `srcset` functionality added should be handled as a separate proposal altogether? Just looking for some guidance on how to proceed from here. Thanks, Mat Marquis
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
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. Regards -Mark
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 06.06.2012 14:36 schrieb Henri Sivonen: On Wed, May 23, 2012 at 6:21 PM, Florian Rivoal wrote: 1) simplyfy srcset to only accept the *x qualifier 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.? Explicitly specifying the * in *x allows more flexibility in the future for cases such as: - If sometime most displays will have 2x or higher resolutions, authors might want to set 1x versions aside. - If 3x or whatever displays should occur, the spec should be suitable for them, too. - Some UAs might decide to progressively load sources in order to emulate what we know from interlaced GIFs. Authors could for this purpose add 0.5x and even 0.25x versions.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Wed, May 23, 2012 at 6:21 PM, Florian Rivoal wrote: > On the other hand, I think that including 600w 400h in there is misguided. I agree. > 1) simplyfy srcset to only accept the *x qualifier 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.? > I believe the only way out is through an image format that: ... > - is designed so that the browser can stop downloading half way through > the file, if it determines it got sufficiently high resolution given the > environment 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.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Mon, 28 May 2012 18:29:45 +0200, Matthew Wilcox wrote: Personally I think it's better than either or srcset alone. But I don't think it's good enough even so, it still has problems: * It's verbose (but less-so than ). It's just as dense as the original srcset proposal if you don't need media queries: I my mind, you only pull out the rest if you actually need media queries. * It has two attributes that could easily be confused as doing the same job. There's little clear logic as to why they're split, from an authors viewpoint. It might be confusing, but there is logic in the splitting: srcset="." lets you describe the properties of a set of equivalent images, and the browser decides which one is more appropriate given the environment. * It bakes design properties into the mark-up. They will be the wrong breakpoints come any re-design. It does, and I am somewhat reluctant because of that. But arguably, already has that problem, even if it is to a lesser degree, and to be purely semantic, the mark-up ought to only contain the alt text, to be replaced (or not, if you're on a voice browser) by the approriate image using the css content property. But is practical enough that you don't want be bothered with that, and I am thinking that media queries enabled images (aka ) would be valuable for the same reason. - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Balls, that should have read: "...they go and load the matching resource; which is a 1200px wide image" i.e., the same as the content column at a viewport width of 1600px. On 28 May 2012 20:46, Matthew Wilcox wrote: > On 28 May 2012 20:37, Matthew Wilcox wrote: >> On 28 May 2012 18:21, Scott Jehl wrote: >>> Matt Wilcox's first two points are fair, though I see them as >>> inconveniences rather than blockers. >>> >>> To his third point, however: >>> >>> I see the suggestion mentioned on occasion that content image sizes and >>> design breakpoints should be coordinated, but in practice, I personally >>> haven't found much of a need for that coordination. >>> >>> In the responsive layouts I've worked on, content image sizes and their >>> breakpoints were chosen for completely different reasons than the design >>> (CSS) breakpoints: the former for sensible jumps in file size to match >>> screen dimension and/or density, and the latter for how content modules are >>> visibly designed at given viewport dimensions. >>> >>> Design breakpoints can be plentiful, especially when factoring in all the >>> minor and major tweaks in multi-column responsive layout. Yet for content >>> images, I've found the need for fewer breakpoints, or even entirely >>> different breakpoints than the design. In a site like the bostonglobe.com >>> for example, 2-3 image sizes provide sensible jumps in file size, and >>> because the images live a fluid layout, they scale to fill the layout gaps >>> as the CSS breakpoints shift much more frequently around them. If an image >>> needs finer coordination than that with its design, perhaps it might be >>> considered a design asset that should be handled in CSS with background >>> images; I guess I'd need to see some examples of where this problem could >>> occur. >>> >>> There are sure to be gray areas here. I'm just not sure I agree that the >>> redesign problem is all that much of a real concern for this feature. Matt, >>> if you disagree, do you have any examples you could provide? >> >> Sure :) In many ways I agree with you - the entire problem is >> really all about *the space they fit into* and not about the design. >> And if CSS and HTML could work with that then we would be in a far >> better position because they'd be able to adapt to any space >> regardless of what the design is. The problem is that CSS media >> queries do not work with the space an image fits into - they can only >> measure the viewport. Which means that in practice you're actually >> coupled to the design breakpoint, even when you're intentionally >> working with the containing element into which the image is sitting. >> >> I.e., the space into which the image can fit is defined in the design >> breakpoint. It can't be known any other way because we can't measure >> the containing space itself - we have to define it as part of the >> design based on the value of the viewport width. >> >> Does that make sense? > > To illustrate the example: > > I have my first design, and it is intended for 1600px wide viewports. > In this design I have a main column that's 1200px wide, and I've set > all my 's to adapt to that breakpoint. When those s see a > viewport in excess of 1600px they go and load the matching resource; > which is a 1600px wide image. All is dandy. > > Two years later there's a re-design, and I've got hundreds of blog > posts with embedded elements that match a 1600px wide viewport. > But the re-design isn't the same layout. It now has three columns at > that viewport width, not one main column. And now all of the > elements match the viewport... but lead to images which are much too > large for the new design. > > Or, even worse, the new design has completely different breakpoints, > and the 's that are being loaded when the viewport hits 1600px > are completely at odds with the layout bracket that I'd defined for > 1200-1800px ranges. > > This is what I mean by saying that we're tying our elements to > design breakpoints. Everything is based on Viewports, and we could > *really* do with them not being. That's incredibly unlikely to happen > though because the technologies just aren't designed that way. Which > means we have to hope for a second-best approach of some hefty > abstraction.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 28 May 2012 20:37, Matthew Wilcox wrote: > On 28 May 2012 18:21, Scott Jehl wrote: >> Matt Wilcox's first two points are fair, though I see them as inconveniences >> rather than blockers. >> >> To his third point, however: >> >> I see the suggestion mentioned on occasion that content image sizes and >> design breakpoints should be coordinated, but in practice, I personally >> haven't found much of a need for that coordination. >> >> In the responsive layouts I've worked on, content image sizes and their >> breakpoints were chosen for completely different reasons than the design >> (CSS) breakpoints: the former for sensible jumps in file size to match >> screen dimension and/or density, and the latter for how content modules are >> visibly designed at given viewport dimensions. >> >> Design breakpoints can be plentiful, especially when factoring in all the >> minor and major tweaks in multi-column responsive layout. Yet for content >> images, I've found the need for fewer breakpoints, or even entirely >> different breakpoints than the design. In a site like the bostonglobe.com >> for example, 2-3 image sizes provide sensible jumps in file size, and >> because the images live a fluid layout, they scale to fill the layout gaps >> as the CSS breakpoints shift much more frequently around them. If an image >> needs finer coordination than that with its design, perhaps it might be >> considered a design asset that should be handled in CSS with background >> images; I guess I'd need to see some examples of where this problem could >> occur. >> >> There are sure to be gray areas here. I'm just not sure I agree that the >> redesign problem is all that much of a real concern for this feature. Matt, >> if you disagree, do you have any examples you could provide? > > Sure :) In many ways I agree with you - the entire problem is > really all about *the space they fit into* and not about the design. > And if CSS and HTML could work with that then we would be in a far > better position because they'd be able to adapt to any space > regardless of what the design is. The problem is that CSS media > queries do not work with the space an image fits into - they can only > measure the viewport. Which means that in practice you're actually > coupled to the design breakpoint, even when you're intentionally > working with the containing element into which the image is sitting. > > I.e., the space into which the image can fit is defined in the design > breakpoint. It can't be known any other way because we can't measure > the containing space itself - we have to define it as part of the > design based on the value of the viewport width. > > Does that make sense? To illustrate the example: I have my first design, and it is intended for 1600px wide viewports. In this design I have a main column that's 1200px wide, and I've set all my 's to adapt to that breakpoint. When those s see a viewport in excess of 1600px they go and load the matching resource; which is a 1600px wide image. All is dandy. Two years later there's a re-design, and I've got hundreds of blog posts with embedded elements that match a 1600px wide viewport. But the re-design isn't the same layout. It now has three columns at that viewport width, not one main column. And now all of the elements match the viewport... but lead to images which are much too large for the new design. Or, even worse, the new design has completely different breakpoints, and the 's that are being loaded when the viewport hits 1600px are completely at odds with the layout bracket that I'd defined for 1200-1800px ranges. This is what I mean by saying that we're tying our elements to design breakpoints. Everything is based on Viewports, and we could *really* do with them not being. That's incredibly unlikely to happen though because the technologies just aren't designed that way. Which means we have to hope for a second-best approach of some hefty abstraction.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 28 May 2012 18:21, Scott Jehl wrote: > Matt Wilcox's first two points are fair, though I see them as inconveniences > rather than blockers. > > To his third point, however: > > I see the suggestion mentioned on occasion that content image sizes and > design breakpoints should be coordinated, but in practice, I personally > haven't found much of a need for that coordination. > > In the responsive layouts I've worked on, content image sizes and their > breakpoints were chosen for completely different reasons than the design > (CSS) breakpoints: the former for sensible jumps in file size to match screen > dimension and/or density, and the latter for how content modules are visibly > designed at given viewport dimensions. > > Design breakpoints can be plentiful, especially when factoring in all the > minor and major tweaks in multi-column responsive layout. Yet for content > images, I've found the need for fewer breakpoints, or even entirely different > breakpoints than the design. In a site like the bostonglobe.com for example, > 2-3 image sizes provide sensible jumps in file size, and because the images > live a fluid layout, they scale to fill the layout gaps as the CSS > breakpoints shift much more frequently around them. If an image needs finer > coordination than that with its design, perhaps it might be considered a > design asset that should be handled in CSS with background images; I guess > I'd need to see some examples of where this problem could occur. > > There are sure to be gray areas here. I'm just not sure I agree that the > redesign problem is all that much of a real concern for this feature. Matt, > if you disagree, do you have any examples you could provide? Sure :) In many ways I agree with you - the entire problem is really all about *the space they fit into* and not about the design. And if CSS and HTML could work with that then we would be in a far better position because they'd be able to adapt to any space regardless of what the design is. The problem is that CSS media queries do not work with the space an image fits into - they can only measure the viewport. Which means that in practice you're actually coupled to the design breakpoint, even when you're intentionally working with the containing element into which the image is sitting. I.e., the space into which the image can fit is defined in the design breakpoint. It can't be known any other way because we can't measure the containing space itself - we have to define it as part of the design based on the value of the viewport width. Does that make sense?
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Matt Wilcox's first two points are fair, though I see them as inconveniences rather than blockers. To his third point, however: I see the suggestion mentioned on occasion that content image sizes and design breakpoints should be coordinated, but in practice, I personally haven't found much of a need for that coordination. In the responsive layouts I've worked on, content image sizes and their breakpoints were chosen for completely different reasons than the design (CSS) breakpoints: the former for sensible jumps in file size to match screen dimension and/or density, and the latter for how content modules are visibly designed at given viewport dimensions. Design breakpoints can be plentiful, especially when factoring in all the minor and major tweaks in multi-column responsive layout. Yet for content images, I've found the need for fewer breakpoints, or even entirely different breakpoints than the design. In a site like the bostonglobe.com for example, 2-3 image sizes provide sensible jumps in file size, and because the images live a fluid layout, they scale to fill the layout gaps as the CSS breakpoints shift much more frequently around them. If an image needs finer coordination than that with its design, perhaps it might be considered a design asset that should be handled in CSS with background images; I guess I'd need to see some examples of where this problem could occur. There are sure to be gray areas here. I'm just not sure I agree that the redesign problem is all that much of a real concern for this feature. Matt, if you disagree, do you have any examples you could provide? Thanks! On May 28, 2012, at 12:29 PM, Matthew Wilcox wrote: > Personally I think it's better than either or srcset alone. > But I don't think it's good enough even so, it still has problems: > > * It's verbose (but less-so than ). > * It has two attributes that could easily be confused as doing the > same job. There's little clear logic as to why they're split, from an > authors viewpoint. > * It bakes design properties into the mark-up. They will be the wrong > breakpoints come any re-design. > > That last one is killer for me. And I've no idea how to address it either :s > > -Matt > > On 28 May 2012 17:23, Mathew Marquis wrote: >> >> On May 24, 2012, at 3:58 AM, Florian Rivoal wrote: >> >>> On Wed, 23 May 2012 21:18:25 +0200, Scott Jehl wrote: >>> With this proposal, could "src" be used on a source element if you don't need the features srcset provides? Or maybe, would that just be equivalent to srcset with a single source listed? >>> >>> I have no strong preference for src vs srcset with a single source and no >>> density >>> qualifier, but yes, one of them should be available. >>> >> >> I’m a little uneasy at the silence following Florian’s proposal. I’d love to >> hear the WHATWG’s thoughts on this compromise. >> >>> - Florian >>
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Personally I think it's better than either or srcset alone. But I don't think it's good enough even so, it still has problems: * It's verbose (but less-so than ). * It has two attributes that could easily be confused as doing the same job. There's little clear logic as to why they're split, from an authors viewpoint. * It bakes design properties into the mark-up. They will be the wrong breakpoints come any re-design. That last one is killer for me. And I've no idea how to address it either :s -Matt On 28 May 2012 17:23, Mathew Marquis wrote: > > On May 24, 2012, at 3:58 AM, Florian Rivoal wrote: > >> On Wed, 23 May 2012 21:18:25 +0200, Scott Jehl wrote: >> >>> With this proposal, could "src" be used on a source element if you don't >>> need the features srcset provides? >>> >>> Or maybe, would that just be equivalent to srcset with a single source >>> listed? >> >> I have no strong preference for src vs srcset with a single source and no >> density >> qualifier, but yes, one of them should be available. >> > > I’m a little uneasy at the silence following Florian’s proposal. I’d love to > hear the WHATWG’s thoughts on this compromise. > >> - Florian >
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 24, 2012, at 3:58 AM, Florian Rivoal wrote: > On Wed, 23 May 2012 21:18:25 +0200, Scott Jehl wrote: > >> With this proposal, could "src" be used on a source element if you don't >> need the features srcset provides? >> >> Or maybe, would that just be equivalent to srcset with a single source >> listed? > > I have no strong preference for src vs srcset with a single source and no > density > qualifier, but yes, one of them should be available. > I’m a little uneasy at the silence following Florian’s proposal. I’d love to hear the WHATWG’s thoughts on this compromise. > - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Thu, 24 May 2012 11:35:35 +0200, Markus Ernst wrote: Am 24.05.2012 11:13 schrieb Matthew Wilcox: I agree, the problem is that... it's still a problem. It's not always a cropped version, it's sometimes a different image entirely - but we can only sense the viewport rather than the space into which an image is sitting. Because we can only sense the viewport we are actually hooking into the design itself rather than being able to automate things based on "how much room is there for this image?". However it's cut, future maintenance is going to be a problem. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. That's true, but the problem isn't so much that as it is that there will be different breakpoints. It's unlikely we'd be working with the same breakpoints, so the one's in the mark-up are all wrong. Leading to incorrect image selection. It's not trivial to revisit all mark-up to correct this. Once CSS variables are available, would it be possible to reference them from the @media attribute? Given a variable "breakpoint1" is defined in the CSS file: CSS variables as proposed can't work like that, as they rely on the cascade. - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
>> That's true, but the problem isn't so much that as it is that there >> will be different breakpoints. It's unlikely we'd be working with the >> same breakpoints, so the one's in the mark-up are all wrong. Leading >> to incorrect image selection. It's not trivial to revisit all mark-up >> to correct this. > > > Once CSS variables are available, would it be possible to reference them > from the @media attribute? Given a variable "breakpoint1" is defined in the > CSS file: > > > I don't want to take this thread too far off topic, but the "we'll have changing breakpoints at some point" problem is a major reason why http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ was thought of. It has it's own drawbacks, but it does address the problem of breakpoint management and centralisation of breakpoints throughout the technology stack of HTML/CSS/JS.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 24.05.2012 11:13 schrieb Matthew Wilcox: I agree, the problem is that... it's still a problem. It's not always a cropped version, it's sometimes a different image entirely - but we can only sense the viewport rather than the space into which an image is sitting. Because we can only sense the viewport we are actually hooking into the design itself rather than being able to automate things based on "how much room is there for this image?". However it's cut, future maintenance is going to be a problem. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. That's true, but the problem isn't so much that as it is that there will be different breakpoints. It's unlikely we'd be working with the same breakpoints, so the one's in the mark-up are all wrong. Leading to incorrect image selection. It's not trivial to revisit all mark-up to correct this. Once CSS variables are available, would it be possible to reference them from the @media attribute? Given a variable "breakpoint1" is defined in the CSS file:
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 24 May 2012 09:45, Markus Ernst wrote: > Am 24.05.2012 10:27 schrieb Matthew Wilcox: > >> Excellent, sorry I was not clear on that; this is looking good! >> >> I would like to re-iterate that this solution is another which puts >> design properties into mark-up directly, and just like old >> and srcset, this means that when it's time to re-design a site an >> author is going to have to trawl through all elements >> throughout the site to adjust them to fit the new design. >> >> This is to my mind a major problem which stops any such solution from >> being a general-purpose solution. I'd be ok for one-off special uses, >> but I can't write website's that I know to be future un-friendly - >> that's just storing up problems for the future. > > > This is true only for the art-direction use case, as MQs are removed from > the optimization use case. Yep, I can see that's the case :) > Unless a new proposal comes up that solves this issue, too, I think this is > something we can live with, for two reasons: > - The art direction use case is somehow at the edge between content and > design. Serving a cropped version of an image is actually dealing with > content, even if it is about the design situation. I agree, the problem is that... it's still a problem. It's not always a cropped version, it's sometimes a different image entirely - but we can only sense the viewport rather than the space into which an image is sitting. Because we can only sense the viewport we are actually hooking into the design itself rather than being able to automate things based on "how much room is there for this image?". However it's cut, future maintenance is going to be a problem. > - New designs usually require other image dimensions, meaning that images > have to be recreated anyway. That's true, but the problem isn't so much that as it is that there will be different breakpoints. It's unlikely we'd be working with the same breakpoints, so the one's in the mark-up are all wrong. Leading to incorrect image selection. It's not trivial to revisit all mark-up to correct this. > In my practice I have seen several redesigns of > websites; none of them was restricted to CSS, in all cases, the whole > websites were rebuilt, or at least the content was entirely reviewed. This always happens at the agency where I work too, but we also tend to keep an awful lot of the existing content even if we re-shuffle the organisation. There's a lot of existing content that will be re-used in new designs, and as before: while it's easy to change overall template aspects like div structure, it's an entirely different matter to go editing detailed *parts* of content like embedded images. > (My experience is very much focused on corporate situations, so this may be > different in other fields such as academic.) We do academic, corporate, personal, all sorts. We almost always end up keeping content (but it's nice on the occasions where we dont!)
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 24.05.2012 10:27 schrieb Matthew Wilcox: Excellent, sorry I was not clear on that; this is looking good! I would like to re-iterate that this solution is another which puts design properties into mark-up directly, and just like old and srcset, this means that when it's time to re-design a site an author is going to have to trawl through all elements throughout the site to adjust them to fit the new design. This is to my mind a major problem which stops any such solution from being a general-purpose solution. I'd be ok for one-off special uses, but I can't write website's that I know to be future un-friendly - that's just storing up problems for the future. This is true only for the art-direction use case, as MQs are removed from the optimization use case. Unless a new proposal comes up that solves this issue, too, I think this is something we can live with, for two reasons: - The art direction use case is somehow at the edge between content and design. Serving a cropped version of an image is actually dealing with content, even if it is about the design situation. - New designs usually require other image dimensions, meaning that images have to be recreated anyway. In my practice I have seen several redesigns of websites; none of them was restricted to CSS, in all cases, the whole websites were rebuilt, or at least the content was entirely reviewed. (My experience is very much focused on corporate situations, so this may be different in other fields such as academic.)
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Excellent, sorry I was not clear on that; this is looking good! I would like to re-iterate that this solution is another which puts design properties into mark-up directly, and just like old and srcset, this means that when it's time to re-design a site an author is going to have to trawl through all elements throughout the site to adjust them to fit the new design. This is to my mind a major problem which stops any such solution from being a general-purpose solution. I'd be ok for one-off special uses, but I can't write website's that I know to be future un-friendly - that's just storing up problems for the future. -Matt [re-posted to the group, I'd hit reply and not reply-all, sorry!]
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Wed, 23 May 2012 21:18:25 +0200, Scott Jehl wrote: With this proposal, could "src" be used on a source element if you don't need the features srcset provides? Or maybe, would that just be equivalent to srcset with a single source listed? I have no strong preference for src vs srcset with a single source and no density qualifier, but yes, one of them should be available. - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Wed, 23 May 2012 20:56:29 +0200, Matthew Wilcox wrote: I think this is a good step forward, however nless I am mis-understanding something (entirely possible given how much has been going on over this recently) there are problems still... Resolution of an image and a device is not a guarantee of suitability of an image at a given physical size. This solution seems to take the art-directed aspect out of the equation. Just because there's enough resolution on the device does not mean that the image itself is suitable at the size the device is outputting the image. Without some form of other qualifier you end up in a situation where an iPhone 4 with it's retina display will load an image intended for a device twice as big. Now, unless you've got perfect eyesight that image will be displayed at the correct resolution, but *half the size* on an iPhone 4. That's going to be a problem for some users, especially older users. There needs to maintain an art-directed aspect, and it doesn't seem possible for a device to have the required intelligence to know which image is appropriate based solely on the device's pixel density and a collection of images at given dimensions. Maybe I am misunderstanding you, but if I am not, my proposal addresses this need. You'd write it something like this: You would use the media attribute of the source element to create arbitrarily complex media queries for your art-directed decisions, and use the srcset on the same element to provide various resolutions. - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Wed, 23 May 2012 21:48:39 +0200, Markus Ernst wrote: Am 23.05.2012 17:21 schrieb Florian Rivoal: Here's what I think we should do: 1) simplyfy srcset to only accept the *x qualifier 2) add support for srcset as an attribute of the sub-element of the element (in addition to src, or instead of it? I am not sure). Then you could do stuff like this: Yesterday I made a similar proposal in an other thread: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036143.html Yes, indeed, this seems to be exactly the same proposal. Sorry for not noticing you had already made it. I'd like to suggest that @srcset in this form would also be suitable for the element, to address the optimization use case (without art direction) without the verbosity of . Sure, sorry for not being very clear about that. In my mind, @srcset would apply to both and . If you need media queries (to detecte portrait vs landscape, the viewport size, color depth...), you go with: But if you don't need media queries, and only want images that adapt to the resolution and bandwidth, you do this one: - Florian
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
<<< Given a set of images of different qualities, browsers can have fairly advanced heuristics to pick the right one. For example switching from low res to high res halfway through the rendering of the page if the device is high resolution and the bandwith just went from bad to good and the latency is low enough. Most authors are not going to bother writing media queries of that complexity, and as media queries are stateless, even if they wanted they couldn't be as sophisticated as browsers. This gets even more true if you consider zooming. Having said all that, I think srcset="foo.jpg 1x, foo2.jpg 2x" is quite good, because it does indeed provide the browser with a set of images with different quality, leaving it free to pick the appropriate one. On the other hand, I think that including 600w 400h in there is misguided. It doesn't help for the problem of picking the right image for the right resolution/bandwidth combination, but is too crippled to be useful as media queries meant to serve different images to in different scenarios. serves these use cases much better. Here's what I think we should do: 1) simplyfy srcset to only accept the *x qualifier 2) add support for srcset as an attribute of the sub-element of the element (in addition to src, or instead of it? I am not sure). Then you could do stuff like this: >>> I’m really digging this solution Florian. It seems like the best of both worlds. I’m still not 100% sure about the impact on the pre-processor but I think it's an interesting avenue to examine. Cheers, Aaron
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 23.05.2012 17:21 schrieb Florian Rivoal: Here's what I think we should do: 1) simplyfy srcset to only accept the *x qualifier 2) add support for srcset as an attribute of the sub-element of the element (in addition to src, or instead of it? I am not sure). Then you could do stuff like this: Yesterday I made a similar proposal in an other thread: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/036143.html I'd like to suggest that @srcset in this form would also be suitable for the element, to address the optimization use case (without art direction) without the verbosity of .
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
With this proposal, could "src" be used on a source element if you don't need the features srcset provides? Or maybe, would that just be equivalent to srcset with a single source listed? On May 23, 2012, at 2:56 PM, Matthew Wilcox wrote: > I think this is a good step forward, however nless I am > mis-understanding something (entirely possible given how much has been > going on over this recently) there are problems still... > > Resolution of an image and a device is not a guarantee of suitability > of an image at a given physical size. This solution seems to take the > art-directed aspect out of the equation. Just because there's enough > resolution on the device does not mean that the image itself is > suitable at the size the device is outputting the image. Without some > form of other qualifier you end up in a situation where an iPhone 4 > with it's retina display will load an image intended for a device > twice as big. Now, unless you've got perfect eyesight that image will > be displayed at the correct resolution, but *half the size* on an > iPhone 4. That's going to be a problem for some users, especially > older users. > > There needs to maintain an art-directed aspect, and it doesn't seem > possible for a device to have the required intelligence to know which > image is appropriate based solely on the device's pixel density and a > collection of images at given dimensions. > > -Matt > > On 23 May 2012 18:27, Scott Jehl wrote: >> I agree with Mat. >> >> This idea appears to elegantly satisfy the goals we originally set out to >> address in the responsive images group (and ended up subsequently coming to >> like the picture/source syntax), while also bringing the advantages of the >> pixel density notation. >> >> >> >>> >>>> >>> From: "Florian Rivoal" >>> Subject: [whatwg] Media queries, viewport dimensions, srcset and picture >>> Date: May 23, 2012 11:21:44 AM EDT >>> To: whatwg@lists.whatwg.org >>> >>> Sorry for not replying to the right message in the thread, >>> I was previously not subscribed to this list, so I can't. >>> >>> As the editor of the CSS Media Queries spec, I've been asked >>> to share my opinion about this debate on responsive images, srcset, >>> media queries, etc. >>> >>> Disclamer: I haven't followed the discussion too closely, and I haven't >>> really done my homework of reading everything that's been said so far, >>> so I'm sure I'll miss the point in a bunch of places, but here's my >>> brain dump, for what it's worth. >>> >>> >>> >>> The responsive image problem is made significantly harder by the fact that >>> in most cases, the decision of whether you want to use a high res or low >>> res image depends both on the resolution of the device and on the network >>> bandwidth. >>> >>> For a low res device, no matter what the bandwidth is, you're going to >>> want a low res image (at least as long as you don't take zooming into >>> account). For a high res device, you want a high res image, unless the >>> bandwidth would make it to slow to load, in which case you might prefer a >>> low res image. If you have a variable bandwidth, the last thing you want >>> to do is to change your mind about which resolution you wanted half way >>> through due to a change of bandwidth, and discard already downloaded data >>> because it's the wrong one after all. This situation gets worse as with >>> high latency. >>> >>> Leaving syntax aside, I think media queries in relation to images can be >>> useful. Providing a different image based on aspect ratio, color depth, >>> viewport size, etc can certainly make sense. >>> >>> But I am skeptical that media queries can solve the responsive image >>> problem well, because I don't see how one could make a bandwidth or >>> latency media query that doesn't cause already downloaded content to be >>> discarded when the conditions change, other than by making it not update >>> to reflect the current conditions, which would make it fairly useless. >>> >>> Given a set of images of different qualities, browsers can have fairly >>> advanced heuristics to pick the right one. For example switching from low >>> res to high res halfway through the rendering of the page if the device is >>> high resolution and the bandwith just went from
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
I think this is a good step forward, however nless I am mis-understanding something (entirely possible given how much has been going on over this recently) there are problems still... Resolution of an image and a device is not a guarantee of suitability of an image at a given physical size. This solution seems to take the art-directed aspect out of the equation. Just because there's enough resolution on the device does not mean that the image itself is suitable at the size the device is outputting the image. Without some form of other qualifier you end up in a situation where an iPhone 4 with it's retina display will load an image intended for a device twice as big. Now, unless you've got perfect eyesight that image will be displayed at the correct resolution, but *half the size* on an iPhone 4. That's going to be a problem for some users, especially older users. There needs to maintain an art-directed aspect, and it doesn't seem possible for a device to have the required intelligence to know which image is appropriate based solely on the device's pixel density and a collection of images at given dimensions. -Matt On 23 May 2012 18:27, Scott Jehl wrote: > I agree with Mat. > > This idea appears to elegantly satisfy the goals we originally set out to > address in the responsive images group (and ended up subsequently coming to > like the picture/source syntax), while also bringing the advantages of the > pixel density notation. > > > >> >>> >> From: "Florian Rivoal" >> Subject: [whatwg] Media queries, viewport dimensions, srcset and picture >> Date: May 23, 2012 11:21:44 AM EDT >> To: whatwg@lists.whatwg.org >> >> Sorry for not replying to the right message in the thread, >> I was previously not subscribed to this list, so I can't. >> >> As the editor of the CSS Media Queries spec, I've been asked >> to share my opinion about this debate on responsive images, srcset, >> media queries, etc. >> >> Disclamer: I haven't followed the discussion too closely, and I haven't >> really done my homework of reading everything that's been said so far, >> so I'm sure I'll miss the point in a bunch of places, but here's my >> brain dump, for what it's worth. >> >> >> >> The responsive image problem is made significantly harder by the fact that >> in most cases, the decision of whether you want to use a high res or low >> res image depends both on the resolution of the device and on the network >> bandwidth. >> >> For a low res device, no matter what the bandwidth is, you're going to >> want a low res image (at least as long as you don't take zooming into >> account). For a high res device, you want a high res image, unless the >> bandwidth would make it to slow to load, in which case you might prefer a >> low res image. If you have a variable bandwidth, the last thing you want >> to do is to change your mind about which resolution you wanted half way >> through due to a change of bandwidth, and discard already downloaded data >> because it's the wrong one after all. This situation gets worse as with >> high latency. >> >> Leaving syntax aside, I think media queries in relation to images can be >> useful. Providing a different image based on aspect ratio, color depth, >> viewport size, etc can certainly make sense. >> >> But I am skeptical that media queries can solve the responsive image >> problem well, because I don't see how one could make a bandwidth or >> latency media query that doesn't cause already downloaded content to be >> discarded when the conditions change, other than by making it not update >> to reflect the current conditions, which would make it fairly useless. >> >> Given a set of images of different qualities, browsers can have fairly >> advanced heuristics to pick the right one. For example switching from low >> res to high res halfway through the rendering of the page if the device is >> high resolution and the bandwith just went from bad to good and the >> latency is low enough. Most authors are not going to bother writing media >> queries of that complexity, and as media queries are stateless, even if >> they wanted they couldn't be as sophisticated as browsers. This gets even >> more true if you consider zooming. >> >> Having said all that, I think srcset="foo.jpg 1x, foo2.jpg 2x" is quite >> good, because it does indeed provide the browser with a set of images with >> different quality, leaving it free to pick the appropriate one. >> >> On the other hand, I think that including 600w
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
I agree with Mat. This idea appears to elegantly satisfy the goals we originally set out to address in the responsive images group (and ended up subsequently coming to like the picture/source syntax), while also bringing the advantages of the pixel density notation. > >> > From: "Florian Rivoal" > Subject: [whatwg] Media queries, viewport dimensions, srcset and picture > Date: May 23, 2012 11:21:44 AM EDT > To: whatwg@lists.whatwg.org > > Sorry for not replying to the right message in the thread, > I was previously not subscribed to this list, so I can't. > > As the editor of the CSS Media Queries spec, I've been asked > to share my opinion about this debate on responsive images, srcset, > media queries, etc. > > Disclamer: I haven't followed the discussion too closely, and I haven't > really done my homework of reading everything that's been said so far, > so I'm sure I'll miss the point in a bunch of places, but here's my > brain dump, for what it's worth. > > > > The responsive image problem is made significantly harder by the fact that > in most cases, the decision of whether you want to use a high res or low > res image depends both on the resolution of the device and on the network > bandwidth. > > For a low res device, no matter what the bandwidth is, you're going to > want a low res image (at least as long as you don't take zooming into > account). For a high res device, you want a high res image, unless the > bandwidth would make it to slow to load, in which case you might prefer a > low res image. If you have a variable bandwidth, the last thing you want > to do is to change your mind about which resolution you wanted half way > through due to a change of bandwidth, and discard already downloaded data > because it's the wrong one after all. This situation gets worse as with > high latency. > > Leaving syntax aside, I think media queries in relation to images can be > useful. Providing a different image based on aspect ratio, color depth, > viewport size, etc can certainly make sense. > > But I am skeptical that media queries can solve the responsive image > problem well, because I don't see how one could make a bandwidth or > latency media query that doesn't cause already downloaded content to be > discarded when the conditions change, other than by making it not update > to reflect the current conditions, which would make it fairly useless. > > Given a set of images of different qualities, browsers can have fairly > advanced heuristics to pick the right one. For example switching from low > res to high res halfway through the rendering of the page if the device is > high resolution and the bandwith just went from bad to good and the > latency is low enough. Most authors are not going to bother writing media > queries of that complexity, and as media queries are stateless, even if > they wanted they couldn't be as sophisticated as browsers. This gets even > more true if you consider zooming. > > Having said all that, I think srcset="foo.jpg 1x, foo2.jpg 2x" is quite > good, because it does indeed provide the browser with a set of images with > different quality, leaving it free to pick the appropriate one. > > On the other hand, I think that including 600w 400h in there is misguided. > It doesn't help for the problem of picking the right image for the right > resolution/bandwidth combination, but is too crippled to be useful as > media queries meant to serve different images to in different scenarios. > serves these use cases much better. > > Here's what I think we should do: > > 1) simplyfy srcset to only accept the *x qualifier > > 2) add support for srcset as an attribute of the sub-element of > the element (in addition to src, or instead of it? I am not > sure). > > Then you could do stuff like this: > > > > > > > Note that it is different from: > > > src="long.jpg"> > src="long2.jpg"> > src="tall.jpg"> > src="tall2.jpg"> > > > > because it allows the browser to be smart about loading the high or low > res image depending on the network conditions. The solution purely based > on media queries doesn't let you do that. > > One final note: the "1x, 2x" ... solution still has one problem that I > think cannot be properly solved purely in html/css. Even though the > browser can be smart about which image to used based on network > conditions, it still cannot escape the fact that to change its mind half > way through, it will have wasted time downloading the wrong image. It > may be wor
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 23, 2012, at 11:21 AM, Florian Rivoal wrote: > > Having said all that, I think srcset="foo.jpg 1x, foo2.jpg 2x" is quite > good, because it does indeed provide the browser with a set of images with > different quality, leaving it free to pick the appropriate one. > > On the other hand, I think that including 600w 400h in there is misguided. > It doesn't help for the problem of picking the right image for the right > resolution/bandwidth combination, but is too crippled to be useful as > media queries meant to serve different images to in different scenarios. > serves these use cases much better. > > Here's what I think we should do: > > 1) simplyfy srcset to only accept the *x qualifier > > 2) add support for srcset as an attribute of the sub-element of > the element (in addition to src, or instead of it? I am not > sure). > > Then you could do stuff like this: > > > > > Honestly, I think this is a brilliant compromise between the two patterns: combining authors’ overwhelming preference for media queries, the need for layout-based art direction, the (relative) simplicity of `srcset` for implementors, and the potential to hinge low/high res images on future bandwidth detection without compromising media queries in the process. I believe this is now my preferred solution, and I hope I’m not alone in that. > > Note that it is different from: > > > src="long.jpg"> > src="long2.jpg"> > src="tall.jpg"> > src="tall2.jpg"> > > > > because it allows the browser to be smart about loading the high or low > res image depending on the network conditions. The solution purely based > on media queries doesn't let you do that. > > One final note: the "1x, 2x" ... solution still has one problem that I > think cannot be properly solved purely in html/css. Even though the > browser can be smart about which image to used based on network > conditions, it still cannot escape the fact that to change its mind half > way through, it will have wasted time downloading the wrong image. It > may be worth it in some cases, but it is still wasteful. > > I believe the only way out is through an image format that: > - stores multiple resolutions in one file > - stores the higher resolution as incremental information on top of the > low res, so that downloading low res images isn't a waste of time even if > you want the high res. > - is designed so that the browser can stop downloading half way through > the file, if it determines it got sufficiently high resolution given the > environment. > > This would allow browsers to switch from wanting a high res image to > wanting a low res image without having to restart the download from > scratch, which is really bad, as the main reason for switching from high > to low is a bad network. When the browser is aiming for the high res > image, it still gets some lower quality image to display temporarily while > the higher quality image is being downloaded. > > I am not enough of an image guy to know if progressive jpeg or webp or > some other existing format has these characteristics. > > The "1x, 2x..." syntax probably needs to be tweaked to accommodate such > images: > srcset="standard.jpg 1x, progressive.prog 0.1-4x" > > Even if we don't have an existing format for that, the html syntax should > probably anticipate it, so that soon-to-be implemented UAs don't get > confused when they get served content from the longer term future that > uses this syntax. > > As an aside, This syntax might work to mix raster images and vector > images: srcset="foo.svg 0.1-0.5x, foo.jpg 1x"
[whatwg] Media queries, viewport dimensions, srcset and picture
Sorry for not replying to the right message in the thread, I was previously not subscribed to this list, so I can't. As the editor of the CSS Media Queries spec, I've been asked to share my opinion about this debate on responsive images, srcset, media queries, etc. Disclamer: I haven't followed the discussion too closely, and I haven't really done my homework of reading everything that's been said so far, so I'm sure I'll miss the point in a bunch of places, but here's my brain dump, for what it's worth. The responsive image problem is made significantly harder by the fact that in most cases, the decision of whether you want to use a high res or low res image depends both on the resolution of the device and on the network bandwidth. For a low res device, no matter what the bandwidth is, you're going to want a low res image (at least as long as you don't take zooming into account). For a high res device, you want a high res image, unless the bandwidth would make it to slow to load, in which case you might prefer a low res image. If you have a variable bandwidth, the last thing you want to do is to change your mind about which resolution you wanted half way through due to a change of bandwidth, and discard already downloaded data because it's the wrong one after all. This situation gets worse as with high latency. Leaving syntax aside, I think media queries in relation to images can be useful. Providing a different image based on aspect ratio, color depth, viewport size, etc can certainly make sense. But I am skeptical that media queries can solve the responsive image problem well, because I don't see how one could make a bandwidth or latency media query that doesn't cause already downloaded content to be discarded when the conditions change, other than by making it not update to reflect the current conditions, which would make it fairly useless. Given a set of images of different qualities, browsers can have fairly advanced heuristics to pick the right one. For example switching from low res to high res halfway through the rendering of the page if the device is high resolution and the bandwith just went from bad to good and the latency is low enough. Most authors are not going to bother writing media queries of that complexity, and as media queries are stateless, even if they wanted they couldn't be as sophisticated as browsers. This gets even more true if you consider zooming. Having said all that, I think srcset="foo.jpg 1x, foo2.jpg 2x" is quite good, because it does indeed provide the browser with a set of images with different quality, leaving it free to pick the appropriate one. On the other hand, I think that including 600w 400h in there is misguided. It doesn't help for the problem of picking the right image for the right resolution/bandwidth combination, but is too crippled to be useful as media queries meant to serve different images to in different scenarios. serves these use cases much better. Here's what I think we should do: 1) simplyfy srcset to only accept the *x qualifier 2) add support for srcset as an attribute of the sub-element of the element (in addition to src, or instead of it? I am not sure). Then you could do stuff like this: Note that it is different from: because it allows the browser to be smart about loading the high or low res image depending on the network conditions. The solution purely based on media queries doesn't let you do that. One final note: the "1x, 2x" ... solution still has one problem that I think cannot be properly solved purely in html/css. Even though the browser can be smart about which image to used based on network conditions, it still cannot escape the fact that to change its mind half way through, it will have wasted time downloading the wrong image. It may be worth it in some cases, but it is still wasteful. I believe the only way out is through an image format that: - stores multiple resolutions in one file - stores the higher resolution as incremental information on top of the low res, so that downloading low res images isn't a waste of time even if you want the high res. - is designed so that the browser can stop downloading half way through the file, if it determines it got sufficiently high resolution given the environment. This would allow browsers to switch from wanting a high res image to wanting a low res image without having to restart the download from scratch, which is really bad, as the main reason for switching from high to low is a bad network. When the browser is aiming for the high res image, it still gets some lower quality image to display temporarily while the higher quality image is being downloaded. I am not enough of an image guy to know if progressive jpeg or webp or some other existing format has these characteristics. The "1x, 2x..." syntax probably needs to be tweaked to accommodate such images: srcset="standard.jpg 1x, progressive.prog 0.1-4x" Even if we don't have an existing format for
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
The patern thing is tangential. SRCSET using image dimensions instead of screen dimensions would work just as well, so would picture if it was set up to allow saying what the dimensions of each image are. I would argue that this does address the pixel density issue though. It does it in the same way it handles em, rem, or percentage based designs: by ignoring all that stuff and just picking the image that best fits the available hardware pixels. It's more future proof too, since you "200w 200h 2x" image could also stand in as your "100w 100h 4x" image, if/when something like that comes out, without any updates needed. Art direction is solved in a simialir way: don't provide any images that look bad, and don't size the img element to a size you don't have a picture for. Using the image dimensions instead of the screen dimensions also solves the "desktop first" vs "mobile first" dilemma. Syndication becomes easier (or are your breakpoints the same as readability's?), updating the design becomes easier (no editing every image in every post because a breakpoint changed) and really simplifies use cases like the following: You're making a grid of thumbnails. At it's largest size, it's three images across. It stays this way until the images are 2/3 their size, at which point it changes to 2 columns at the original size. When the images hit half their original size, it switches to one column, full size. So one image is created at the three most likely sizes (1/1, 1/2, 1/3) and then srcset is used to make sure the -- Mike Gossmann Mathew Marquis wrote: >On May 22, 2012, at 5:43 AM, Anne van Kesteren wrote: > >> On Tue, May 22, 2012 at 10:21 AM, Markus Ernst wrote: >>> I am somehow surprised that there are no reactions to this proposal. To me >>> as a humble author it looks like it would address the main issue of both >>> and @srcset, as it leaves the MQ to CSS, and thus separates design >>> from content. >> >> 1. It does not address the pixel density use case. 2. A pattern-based >> approach was actually mentioned in Ian Hickson's email when he >> announced the srcset attribute. >> > >We’re apt to see the element used in one of two ways: > >* Serving a size-appropriate image source in a flexible layout, wherein the >size of the images will be controlled by CSS—typically, `max-width: 100%`. >Using a pixel density MQ will serve a larger image within this constraint. >Inherent size is not a concern with this case—which is fortunate, as this will >likely require sources with varying dimensions, per the “art direction” case. > >* Serving a static-dimension asset at varying resolutions, a la Apple.com. To >always rely on the intrinsic size of another source is to negate the art >direction use case — however, we could simply add optional `width` and >`height` attributes to `picture`, constraining the higher res image to a >specified set of dimensions. This leaves control in the authors’ hands in a >simple, predictable way without negating either use case. > >I can’t speak to this personally, but Kornel has mentioned that using said >attributes instead of relying on a calculated inherent width will avoid >reflows. It should likely be an option in either case. > >> >> -- >> Anne — Opera Software >> http://annevankesteren.nl/ >> http://www.opera.com/ >
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 22.05.2012 12:46 schrieb Andy Davies:
On 22 May 2012 10:43, Anne van Kesteren wrote:
On Tue, May 22, 2012 at 10:21 AM, Markus Ernst wrote:
I am somehow surprised that there are no reactions to this proposal. To me
as a humble author it looks like it would address the main issue of both
and @srcset, as it leaves the MQ to CSS, and thus separates design
from content.
1. It does not address the pixel density use case. 2. A pattern-based
approach was actually mentioned in Ian Hickson's email when he
announced the srcset attribute.
It doesn't address the "art-direction" use case either -
http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/
You can do art direction by setting the width in the style sheet:
@media all and (max-width: 500px) {
.contentimg {
width: 100px;
}
}
@media all and (min-width: 501px) and (max-width: 800px) {
.contentimg {
width: 300px;
}
}
@media all and (min-width: 801px) {
.contentimg {
width: 500px;
}
}
You supply a cropped image with 100x67 and 200x134 versions, and the
full image with the bigger versions, which serves the art direction use
case. Retina displays that match the first MQ will likely use the
200x134 version rather than the 100x67 one, which serves the pixel
density use case.
I admit that it is not entirely intuitive, and does not give the author
full control. There may be conflicts between a cropped 200px wide image
intended to use in 2x displays, and a full 200px wide image for bigger
but 1x displays. Or a future 3x display may use the 300x200 version,
where the visual situation would require the cropped image.
I am far away from insisting in this solution; I am aware of the fact
that there have been long discussions by people who have far more
understanding on the topic than myself.
It looks to me like the pixel density use case is better addressed by
leaving the choice on the appropriate resource to the UA, and providing
it information on the resources rather than a MQ. While the art
direction use case is better addressed with a MQ undoubtedly.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On May 22, 2012, at 5:43 AM, Anne van Kesteren wrote: > On Tue, May 22, 2012 at 10:21 AM, Markus Ernst wrote: >> I am somehow surprised that there are no reactions to this proposal. To me >> as a humble author it looks like it would address the main issue of both >> and @srcset, as it leaves the MQ to CSS, and thus separates design >> from content. > > 1. It does not address the pixel density use case. 2. A pattern-based > approach was actually mentioned in Ian Hickson's email when he > announced the srcset attribute. > We’re apt to see the element used in one of two ways: * Serving a size-appropriate image source in a flexible layout, wherein the size of the images will be controlled by CSS—typically, `max-width: 100%`. Using a pixel density MQ will serve a larger image within this constraint. Inherent size is not a concern with this case—which is fortunate, as this will likely require sources with varying dimensions, per the “art direction” case. * Serving a static-dimension asset at varying resolutions, a la Apple.com. To always rely on the intrinsic size of another source is to negate the art direction use case — however, we could simply add optional `width` and `height` attributes to `picture`, constraining the higher res image to a specified set of dimensions. This leaves control in the authors’ hands in a simple, predictable way without negating either use case. I can’t speak to this personally, but Kornel has mentioned that using said attributes instead of relying on a calculated inherent width will avoid reflows. It should likely be an option in either case. > > -- > Anne — Opera Software > http://annevankesteren.nl/ > http://www.opera.com/
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On 22 May 2012 10:43, Anne van Kesteren wrote: > On Tue, May 22, 2012 at 10:21 AM, Markus Ernst wrote: >> I am somehow surprised that there are no reactions to this proposal. To me >> as a humble author it looks like it would address the main issue of both >> and @srcset, as it leaves the MQ to CSS, and thus separates design >> from content. > > 1. It does not address the pixel density use case. 2. A pattern-based > approach was actually mentioned in Ian Hickson's email when he > announced the srcset attribute. > It doesn't address the "art-direction" use case either - http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ Andy
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
On Tue, May 22, 2012 at 10:21 AM, Markus Ernst wrote: > I am somehow surprised that there are no reactions to this proposal. To me > as a humble author it looks like it would address the main issue of both > and @srcset, as it leaves the MQ to CSS, and thus separates design > from content. 1. It does not address the pixel density use case. 2. A pattern-based approach was actually mentioned in Ian Hickson's email when he announced the srcset attribute. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 21.05.2012 07:49 schrieb Mike Gossmann: I am somehow surprised that there are no reactions to this proposal. To me as a humble author it looks like it would address the main issue of both and @srcset, as it leaves the MQ to CSS, and thus separates design from content.
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
I think variables for more than width and height might actually be a bit
redundant, since all the other variables are just copying over values from src,
which are known values when the tag is being created, that won't change on
their own. A developer could just type them a second time and be done with it.
This doesn't prevent the width and height variables from being used as part of
a folder structure or filename either. Trying to use a something like
{filename} could also cause problems if you want to use
src="img/blog/anImage_200x300.jpg" as your fallback, unless the variable can
strip the sizes out on it's own.
--
Mike Gossmann
Re: [whatwg] Media queries, viewport dimensions, srcset and picture
Am 21.05.2012 07:49 schrieb Mike Gossmann:
When all the picture vs srcset started showing up on twitter, I was initially
behind picture. I'm sure you all know the arguments for it, and I liked those
arguments. Today though, I was reading an article about the two, and there was
a misunderstanding about how srcset was working in the comments, and it made me
realize that something closer to srcset would be ideal.
The big thing I realized is that as a developer, I do not want to write more
media queries - or anything that works at all like them - into image elements.
It's redundant. There's a good chance there's already a bunch of CSS in place
controlling the shape and size of the image element itself, why should I have
to write a bunch more, somewhere else, to control the src of the image too?
Why can't it work so that in the html I say here's an image, there's a version
of it at 150x150, and a version at 48x48, and then in the CSS I say that the
image is 25% of the width of the article it's in, which works out to 100px
wide, and then the browser can just decide that the 150x150 would be best, and
scale it down. If I change the CSS, I don't have to change the html too, the
images I provided are still only available at those sizes. With image/picture
sources set by viewport dimensions, even something as simple as adding more
padding around articles on a site could involve going through all the HTML and
adjusting the breakpoints in the tags. This way layout, units, and screen dpi,
don't matter when writing the HTML,
I've seen people get confused and think srcset work this way, instead of by
viewport size (unless I'm the confused one), and if they were right then srcset
would work well for this. It would be even nicer if there was something even
more CMS friendly, like:
So src would be the fallback, then sizes would say which dimensions are available, in a fairly
common format, using spaces to separate options like class does. pattern (probably a bad name)
would be a template for the URL the browser can request the image from, replacing {w} and {h} with
the requested dimensions. There wouldn't need to be a token for the dpi/resoultion/whatever, the
browser could just request an image twice or three times or whatever the size. There's no point in
having sizes="100x100@1 100x100@2 200x200@1" when you can just have sizes="100x100
200x200"
This gives the designer/developer full control over the shape and size of the
image element (through CSS), while still allowing the browser to make decisions
based on bandwidth and whatnot.
I was actually writing a similar proposal and like the approach very
much. I have 3 inputs on the pattern syntax:
1. @pattern needs some more variables so authors can use it without a
server side handler, using distinct file names or directories or
whatever, such as:
- directory path
- file name
- file name without suffix
- suffix
So patterns for use with src="/img/people.jpg" could also be e.g.
(variable names are subject to optimisation...):
- /img/{filenameWithoutSuffix}_{w}x{h}.{suffix}
- /{dirname}/{w}x{h}/{filename}
2. It would be nice if @pattern defaulted to something that authors do
all the time anyway. From my practice I suggest:
- /{dirname}/{filenameWithoutSuffix}_{w}x{h}.{suffix}
It is very easy to tell authors or even CMS page admins to use image
file names such as people.jpg and people_200x300.jpg.
3. Variable syntax: Curly brackets are also used for variables by some
server side template engines, such as PEAR HTML_Template_IT and
HTML_Template_Sigma. These would replace or remove the @pattern
variables. Thus, some other kind of variable delimiter might be more
compatible.
[whatwg] Media queries, viewport dimensions, srcset and picture
When all the picture vs srcset started showing up on twitter, I was initially
behind picture. I'm sure you all know the arguments for it, and I liked those
arguments. Today though, I was reading an article about the two, and there was
a misunderstanding about how srcset was working in the comments, and it made me
realize that something closer to srcset would be ideal.
The big thing I realized is that as a developer, I do not want to write more
media queries - or anything that works at all like them - into image elements.
It's redundant. There's a good chance there's already a bunch of CSS in place
controlling the shape and size of the image element itself, why should I have
to write a bunch more, somewhere else, to control the src of the image too?
Why can't it work so that in the html I say here's an image, there's a version
of it at 150x150, and a version at 48x48, and then in the CSS I say that the
image is 25% of the width of the article it's in, which works out to 100px
wide, and then the browser can just decide that the 150x150 would be best, and
scale it down. If I change the CSS, I don't have to change the html too, the
images I provided are still only available at those sizes. With image/picture
sources set by viewport dimensions, even something as simple as adding more
padding around articles on a site could involve going through all the HTML and
adjusting the breakpoints in the tags. This way layout, units, and screen dpi,
don't matter when writing the HTML,
I've seen people get confused and think srcset work this way, instead of by
viewport size (unless I'm the confused one), and if they were right then srcset
would work well for this. It would be even nicer if there was something even
more CMS friendly, like:
So src would be the fallback, then sizes would say which dimensions are
available, in a fairly common format, using spaces to separate options like
class does. pattern (probably a bad name) would be a template for the URL the
browser can request the image from, replacing {w} and {h} with the requested
dimensions. There wouldn't need to be a token for the dpi/resoultion/whatever,
the browser could just request an image twice or three times or whatever the
size. There's no point in having sizes="100x100@1 100x100@2 200x200@1" when you
can just have sizes="100x100 200x200"
This gives the designer/developer full control over the shape and size of the
image element (through CSS), while still allowing the browser to make decisions
based on bandwidth and whatnot.
--
Mike Gossmann | m...@c572.ca | http://gossmati.ca
