Re: [whatwg] An alternative to picture and srcset, is this realistic?
We're getting some good feedback over on the Community Group about this, people seem to like it. I'm still asking a few people to try and find holes in the proposal though, reasons why it wouldn't work. -Matt On 14 May 2012 17:59, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, May 14, 2012 at 9:31 AM, Matthew Wilcox m...@matthewwilcox.com wrote: All good points, thanks. Sorry I'd missed you saying style rather than link/, my bad! I had assumed that we would be able to take the logic for resolving media query applicability directly from that in CSS, which is why I have not given it any further thought. It seemed like a solved issue. Heh, it *is* solved by CSS, it's just that the solution is somewhere between none and all of them apply, which works for CSS but not for yours. ^_^ On Mon, May 14, 2012 at 9:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/14/12 11:55 AM, Tab Atkins Jr. wrote: That's why I mentioned an inlinestyle at the top of thebody - I'm not sure if browsers skip past that when building the tree or not, They certainly skip past such things when prefetching. Putting information that needs to affect prefetching in elements where the HTML tokenizer can extract it is vastly better than putting it into elements where it can't (like style). That's what I was afraid of. All right, then, ignore that part of the suggestion. This should live in HTML if it lives anywhere. ~TJ
[whatwg] An alternative to picture and srcset, is this realistic?
Hi all, have any of you seen this proposal for an alternative solution to the problem? http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ I like the general idea and from an author perspective this seems great; but I know nothing of the browser/vendor side of the equation - is this do-able? Cheers, Matt
Re: [whatwg] An alternative to picture and srcset, is this realistic?
On Mon, May 14, 2012 at 10:55 AM, Matthew Wilcox m...@matthewwilcox.com wrote: have any of you seen this proposal for an alternative solution to the problem? http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ I like the general idea and from an author perspective this seems great; but I know nothing of the browser/vendor side of the equation - is this do-able? Adding a level of indirection is actually not that great as it makes it harder to understand what is going on. Also if you work on sites in teams it's not always a given access to head is equal to the templates that are being authored. Let alone full control over how resources are stored. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] An alternative to picture and srcset, is this realistic?
I'd contest that it is no harder to understand than it is to understand why your CSS behaves differently when a JS element acts on the mark-up. We are used to one stack defining how another acts. We do it all the time. Adding classes to mark-up to control display, or just the cascade on its own does this. Is this harder to understand than picture or srcset is what really matters. Anything we do to resolve this resource adaption problem will by necessity complicate things. Is this better than the alternatives? Remember too that this idea can be mixed with existing techniques, it is not a replacement for other ways of dealing with stuff. You'd be free to bake your media-queries into CSS in exactly the same way as you do now, if a sub-module didn't want to respond to a generic breakpoint, for example. -Matt On 14 May 2012 11:01, Anne van Kesteren ann...@annevk.nl wrote: On Mon, May 14, 2012 at 10:55 AM, Matthew Wilcox m...@matthewwilcox.com wrote: have any of you seen this proposal for an alternative solution to the problem? http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ I like the general idea and from an author perspective this seems great; but I know nothing of the browser/vendor side of the equation - is this do-able? Adding a level of indirection is actually not that great as it makes it harder to understand what is going on. Also if you work on sites in teams it's not always a given access to head is equal to the templates that are being authored. Let alone full control over how resources are stored. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] An alternative to picture and srcset, is this realistic?
On Mon, May 14, 2012 at 10:55 AM, Matthew Wilcox m...@matthewwilcox.com wrote: Hi all, have any of you seen this proposal for an alternative solution to the problem? http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ I like the general idea and from an author perspective this seems great; but I know nothing of the browser/vendor side of the equation - is this do-able? Several critiques, in more or less random order: I'm not sure why it's billed as an alternative to @srcset as well - it has nothing to do with that functionality. It's purely a way to stuff your media queries (which, as already established, can't be used to serve different resolutions well) into a variable, and then abstract your url-rewriting into a single place. I do like the idea of abstracting your MQs - the post makes a good point that between CSS and JS you're already duplicating your breakpoints, and if picture or a similar solution is adopted, you'll be doing it a lot more. Unfortunately, Media Queries aren't immediately amenable to CSS Variables (moving from global vars to tree-scoped vars means that things that aren't part of the element tree can no longer see the vars), so we either need something like this, or I need to add to Variables so that they're friendly to this use-case (and can interact with the URL-rewriting mechanism proposed). I share Anne's concern that the contents of head are often not trivially authorable. This isn't killer, but it's something to keep in mind. Moving the definition to CSS might help here, as it could be put in an inline CSS block at the top of body then. This approach implies that all of your images (at least, all of them with [case] in their URL) must respond to *all* of your breakpoints. If an image doesn't change between certain breakpoints, it still needs to exist in two places on your server (or you need to manually alias a single file) and the browser will make an extra useless request if you cross those breakpoints. From a technical purity standpoint, this introduces a new URL-rewriting mechanism, but specialized for only a single purpose. I suspect there are other uses that URL-rewriting could potentially be put to; we should think about this and make sure that this approach doesn't close the door to future uses. (It doesn't need to be magically infinitely extensible - that way lies madness - but making reasonably sure that it doesn't close the door to other URL-rewriting use-cases is just good sense.) I mentioned above that this solution has nothing to do with @srcset. It's actually slightly worse - this ends up being *hostile* to @srcset, such that you can't combine the two. At least, not without reworking @srcset into a parallel URL-rewriter. The proposal doesn't explain what to do when multiple MQs match. Normally, the CSS cascade takes care of this - if you apply the same property under multiple MQs that all match, specificity determines the winner. It wouldn't be difficult to define how this worked - last-wins is probably the sanest - but still, it's a detail to be specified. Note, though, that if we want this to hook into a more generic variables-in-MQ sort of thing, one may indeed want multiple axises of variables that can match together. I suspect this is especially useful with the new media queries that will show up in MQ4 to help target different kinds of devices. So, it may be good to look into widening this to accomodate different variable names, where within a variable only a single case can win at a time. Related - it would probably be good to be able to define a default case to fall back to when none of the others match. ~TJ
Re: [whatwg] An alternative to picture and srcset, is this realistic?
Thanks for the feedback. Please also forgive me not being too technically aware of things at a browser level; so I'm not really sure how valid my feedback can be: The URI thing is actually using URI Templates, which are already pretty far along? http://code.google.com/p/uri-templates/ I thought this was a strong advantage of the idea. Putting the variables into the CSS would break the advantage of them being available to the browser *before* the browser starts trying to pre-fetch images, right? Any solution has to avoid the prefetch behaviour or else it fails; so I don't understand how they could be moved. I am of the opinion that media queries actually belong in the head more often than they do elsewhere, both from a practical and semantic standpoint (see http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/#comment-752 ) I had presumed that should multiple cases match the browser would simply uses the last matching one. There's already a polyfil in JS that does exactly that: http://jsbin.com/3/ecifaf/latest/ On 14 May 2012 15:50, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, May 14, 2012 at 10:55 AM, Matthew Wilcox m...@matthewwilcox.com wrote: Hi all, have any of you seen this proposal for an alternative solution to the problem? http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/ I like the general idea and from an author perspective this seems great; but I know nothing of the browser/vendor side of the equation - is this do-able? Several critiques, in more or less random order: I'm not sure why it's billed as an alternative to @srcset as well - it has nothing to do with that functionality. It's purely a way to stuff your media queries (which, as already established, can't be used to serve different resolutions well) into a variable, and then abstract your url-rewriting into a single place. I do like the idea of abstracting your MQs - the post makes a good point that between CSS and JS you're already duplicating your breakpoints, and if picture or a similar solution is adopted, you'll be doing it a lot more. Unfortunately, Media Queries aren't immediately amenable to CSS Variables (moving from global vars to tree-scoped vars means that things that aren't part of the element tree can no longer see the vars), so we either need something like this, or I need to add to Variables so that they're friendly to this use-case (and can interact with the URL-rewriting mechanism proposed). I share Anne's concern that the contents of head are often not trivially authorable. This isn't killer, but it's something to keep in mind. Moving the definition to CSS might help here, as it could be put in an inline CSS block at the top of body then. This approach implies that all of your images (at least, all of them with [case] in their URL) must respond to *all* of your breakpoints. If an image doesn't change between certain breakpoints, it still needs to exist in two places on your server (or you need to manually alias a single file) and the browser will make an extra useless request if you cross those breakpoints. From a technical purity standpoint, this introduces a new URL-rewriting mechanism, but specialized for only a single purpose. I suspect there are other uses that URL-rewriting could potentially be put to; we should think about this and make sure that this approach doesn't close the door to future uses. (It doesn't need to be magically infinitely extensible - that way lies madness - but making reasonably sure that it doesn't close the door to other URL-rewriting use-cases is just good sense.) I mentioned above that this solution has nothing to do with @srcset. It's actually slightly worse - this ends up being *hostile* to @srcset, such that you can't combine the two. At least, not without reworking @srcset into a parallel URL-rewriter. The proposal doesn't explain what to do when multiple MQs match. Normally, the CSS cascade takes care of this - if you apply the same property under multiple MQs that all match, specificity determines the winner. It wouldn't be difficult to define how this worked - last-wins is probably the sanest - but still, it's a detail to be specified. Note, though, that if we want this to hook into a more generic variables-in-MQ sort of thing, one may indeed want multiple axises of variables that can match together. I suspect this is especially useful with the new media queries that will show up in MQ4 to help target different kinds of devices. So, it may be good to look into widening this to accomodate different variable names, where within a variable only a single case can win at a time. Related - it would probably be good to be able to define a default case to fall back to when none of the others match. ~TJ
Re: [whatwg] An alternative to picture and srcset, is this realistic?
On Mon, May 14, 2012 at 5:34 PM, Matthew Wilcox m...@matthewwilcox.com wrote: Thanks for the feedback. Please also forgive me not being too technically aware of things at a browser level; so I'm not really sure how valid my feedback can be: The URI thing is actually using URI Templates, which are already pretty far along? http://code.google.com/p/uri-templates/ I thought this was a strong advantage of the idea. I don't know of this having any traction within actual browsers. It might be a good idea, I dunno. Putting the variables into the CSS would break the advantage of them being available to the browser *before* the browser starts trying to pre-fetch images, right? Any solution has to avoid the prefetch behaviour or else it fails; so I don't understand how they could be moved. That's why I mentioned an inline style at the top of the body - I'm not sure if browsers skip past that when building the tree or not, but it's *potentially* available. I am of the opinion that media queries actually belong in the head more often than they do elsewhere, both from a practical and semantic standpoint (see http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/#comment-752 ) I don't necessarily disagree. I wasn't arguing from a theoretical standpoint, just supporting Anne's point that, from a practical standpoint, putting things into head isn't always easy for authors. I had presumed that should multiple cases match the browser would simply uses the last matching one. There's already a polyfil in JS that does exactly that: http://jsbin.com/3/ecifaf/latest/ Yeah, you can't assume that. They're conditions, and a page can potentially match multiple of them at once. For example, if your MQs are min-width: 1000px and min-width: 300px, a 1200px wide screen will match both of them. You can *make* them exclusive by adding a max-width declaration as well, but we can't depend on that happening, so the behavior has to be specified somewhere. Similarly, we can't depend on *any* of them matching, so there should be a default case that is used when nothing else matches. ~TJ
Re: [whatwg] An alternative to picture and srcset, is this realistic?
All good points, thanks. Sorry I'd missed you saying style rather than link/, my bad! I had assumed that we would be able to take the logic for resolving media query applicability directly from that in CSS, which is why I have not given it any further thought. It seemed like a solved issue. I ought to point out I've been updating the main post today, and have also added a prior art thing about how this works for JavaScript - the Conditional CSS technique is already doing what I am proposing here, but using pesudo content rather than a meta tag. :) On 14 May 2012 16:55, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, May 14, 2012 at 5:34 PM, Matthew Wilcox m...@matthewwilcox.com wrote: Thanks for the feedback. Please also forgive me not being too technically aware of things at a browser level; so I'm not really sure how valid my feedback can be: The URI thing is actually using URI Templates, which are already pretty far along? http://code.google.com/p/uri-templates/ I thought this was a strong advantage of the idea. I don't know of this having any traction within actual browsers. It might be a good idea, I dunno. Putting the variables into the CSS would break the advantage of them being available to the browser *before* the browser starts trying to pre-fetch images, right? Any solution has to avoid the prefetch behaviour or else it fails; so I don't understand how they could be moved. That's why I mentioned an inline style at the top of the body - I'm not sure if browsers skip past that when building the tree or not, but it's *potentially* available. I am of the opinion that media queries actually belong in the head more often than they do elsewhere, both from a practical and semantic standpoint (see http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/#comment-752 ) I don't necessarily disagree. I wasn't arguing from a theoretical standpoint, just supporting Anne's point that, from a practical standpoint, putting things into head isn't always easy for authors. I had presumed that should multiple cases match the browser would simply uses the last matching one. There's already a polyfil in JS that does exactly that: http://jsbin.com/3/ecifaf/latest/ Yeah, you can't assume that. They're conditions, and a page can potentially match multiple of them at once. For example, if your MQs are min-width: 1000px and min-width: 300px, a 1200px wide screen will match both of them. You can *make* them exclusive by adding a max-width declaration as well, but we can't depend on that happening, so the behavior has to be specified somewhere. Similarly, we can't depend on *any* of them matching, so there should be a default case that is used when nothing else matches. ~TJ
Re: [whatwg] An alternative to picture and srcset, is this realistic?
On 5/14/12 11:55 AM, Tab Atkins Jr. wrote: That's why I mentioned an inlinestyle at the top of thebody - I'm not sure if browsers skip past that when building the tree or not, They certainly skip past such things when prefetching. Putting information that needs to affect prefetching in elements where the HTML tokenizer can extract it is vastly better than putting it into elements where it can't (like style). -Boris
Re: [whatwg] An alternative to picture and srcset, is this realistic?
On Mon, May 14, 2012 at 9:31 AM, Matthew Wilcox m...@matthewwilcox.com wrote: All good points, thanks. Sorry I'd missed you saying style rather than link/, my bad! I had assumed that we would be able to take the logic for resolving media query applicability directly from that in CSS, which is why I have not given it any further thought. It seemed like a solved issue. Heh, it *is* solved by CSS, it's just that the solution is somewhere between none and all of them apply, which works for CSS but not for yours. ^_^ On Mon, May 14, 2012 at 9:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/14/12 11:55 AM, Tab Atkins Jr. wrote: That's why I mentioned an inlinestyle at the top of thebody - I'm not sure if browsers skip past that when building the tree or not, They certainly skip past such things when prefetching. Putting information that needs to affect prefetching in elements where the HTML tokenizer can extract it is vastly better than putting it into elements where it can't (like style). That's what I was afraid of. All right, then, ignore that part of the suggestion. This should live in HTML if it lives anywhere. ~TJ
