Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On Sun, 13 May 2012 00:43:48 +0200, Jason Grigsby ja...@cloudfour.com wrote: On May 11, 2012, at 8:52 PM, Simon Pieters wrote: There seem to be two proposals for what syntax to use for the responsive images use case: several elements vs. an attribute. There are two proposals because they solve two different use cases. Both use cases are becoming increasingly important. Unfortunately, these use cases are commonly collapsed into one. I have done it myself in the past. I tried to clarify the use cases recently.[1] I agree, but that is orthogonal (the proposals for both use cases could use either attribute syntax or element syntax). Use case #1 --- Document author needs to display different versions of an image at different breakpoints based on what I’m calling, for a lack of a better phrase, art direction merits. * Example 1: News site shows photograph speaking at a auto factory. On wide screens, the news site includes a widescreen version of the photograph in which the cars being built can clearly be seen. On small screens, if the photograph is simply resized to fit the screen, Obama’s face is too small to be seen. Instead, the document author may choose to crop the photograph so that it focuses in on Obama before resizing to fit the smaller screen. [1] * Example 2: On the Nokia Browser site where it describes the Meego browser[2], the Nokia Lumia is show horizontally on wide screens[3]. As the screen narrows, the Nokia Lumia is then shown vertically and cropped[4]. Bryan and Stephanie Rieger, the designers of the site, have talked about how on a wide screen, showing the full phone horizontally showed the browser best, but on small screens, changing the img to vertical made more sense because it allowed the reader to still make out the features of the browser in the image. Current proposed solution: picture element[5] Use case #2 --- For a variety of reasons, images of various pixel density are needed. These reasons include current network connection speed, display pixel density, user data plan, and user preferences. * Example 1: The use of high-density images for the new iPad on Apple.com.[6] * Example 2: A user on a slow network or with limited data left may explicitly declare that he or she would like to download a high resolution because they need to see a sharper version of an image before buying product, etc. Current proposed solution for use case #2: img srcset[7] IMHO Neither proposed solution handles all of the use cases. I’m not convinced that one solution needs to solve both of them, but I do think if we’re getting close to implementing one of the proposed solutions, we need to consider how it would work in conjunction with a solution for the other use case. To be more specific, if img srcset were to be implemented in a browser--potentially solving use case #2, but leaving use case #1 open--what would happen when we realized that use case #1 still needed to be solved? Would we end up with some bastardized mixture of picture and imgset syntax? When Ted proposed img srcset, he wrote[7]: Ultimately I don't think addressing the multiple-resolution case needs to wait for a solution to these other cases. We don't need to SOLVE ALL THE PROBLEMS! right now. In a similar vein, the responsive images community group, focused on use case #1 and explicitly chose to ignore the problems described in use case #2. While I agreed with that focus earlier, I now think this may be a mistake. As much as I don’t want to bog down solving either use case, it seems likely that if we don’t look at both at the same time, that we’ll end up with[8]: picture alt= source src=mobile.jpg / source src=medium.jpg media=min-width: 600px / source src=fullsize.jpg media=min-width: 900px / img src=foo-lores.jpg srcset=foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x alt=decent alt text for foo. /picture Which would make no one happy. -Jason [1] http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/ [2] http://browser.nokia.com/smartphones.html [3] http://browser.nokia.com/resources/images/home-feature.png [4] http://browser.nokia.com/resources/images/smartphones/choose-me...@320.png [5] https://github.com/Wilto/respimg [6] http://blog.cloudfour.com/how-apple-com-will-serve-retina-images-to-new-ipads/ [7] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-May/035746.html [8] Yes, yes, this is an exaggeration, but you get my point. -- Simon Pieters Opera Software
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On Fri, 11 May 2012 20:52:43 +0200, Simon Pieters sim...@opera.com wrote: There seem to be two proposals for what syntax to use for the responsive images use case: several elements vs. an attribute. I think an attribute is simpler to implement and thus likely to result in fewer bugs in browsers, which in turn benefits Web developers. With img src=... srcset=..., in the parser case, all the information is available when the tag has been parsed. Excellent! In the scripted case, we need to await a stable state when the src or srcset attributes are changed (because the same script might also change the other), and then process the attributes again. The spec already does this for src= because of the crossorigin= attribute, so it's basically a solved problem already for img in the spec. Just for the record if people are interested in exploring possible syntaxes, *multiple* attributes on img would have the same order of implementation complexity as a single attribute. Even an open-ended set of attributes. Here's a straw man example of how an open-ended set of attributes could look like (trying to solve both use cases presented), where two images are decided between using media queries, and each of those have several available resolutions, which are decided between by the browser: img src=desktop.jpg alt=... src-small=mobile-zoomed-out.jpg 32dpi, mobile.jpg 96dpi, mobile-hires.jpg 200dpi media-small=max-width: 400px src-big=desktop.jpg 96dpi, desktop-hires.jpg 200dpi, desktop-print-res.jpg 600dpi media-big=min-width: 400px With pictureimg src=...source ../picture, in the parser case, the browser can't know it has all the information is not available until the picture element has been popped off the stack (since there might be futher source elements), which necessarily delays fetching the image. Moreover, scripts might have changed things before then, because scripts can run between the time that the picture element is added to the document and the time it is popped off the stack, which is a potential source for bugs. In the scripted case, we need to listen for changes to img elements' parents, changes to img element's attributes, changes to source elements' parents, and changes to source elements' attributes, and await a stable state and then process the picture element's img and source elements' attributes (for both the old and new picture element, if you moved an element between two picture elements), which is more complex than the attribute case. -- Simon Pieters Opera Software
[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] runat (or server) attribute
On Sun, May 13, 2012 at 6:24 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Sun, 2012-05-13 at 17:16 +0200, Anne van Kesteren wrote: Just use type=text/server-js... Is that really a good idea? It seems odd to use a mime type for such a reason. 1) It makes it backwards compatible and therefore works today (modulo server-side changes). 2) Server-side JavaScript is not fully compatible with client-side JavaScript (other libraries for instance) so deserves a type other than text/javascript. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] runat (or server) attribute
Odin Hørthe Omdal odi...@opera.com schrieb am Sun, 13 May 2012 17:45:46 +: Just use type=text/server-js... Is that really a good idea? It seems odd to use a mime type for such a reason. I thought it was quite a nice idea. Why would it not be? I find it profoundly odd to define templating language bits that are not used (or even usable) by User Agents – especially because there already are lots of widespread templating solutions. It's describing what's in the script tag, just like it's supposed to do. It's even a quite much used pattern for doing client side templates script type=text/template on the web today. This appeal to tradition is weak and – arguably – intellectually dishonest. Table layout once was a “quite much used pattern”. Mime types are not magical any more. Before we could make our own text/x-whatever, but prefixes are not really any use. If you want something specific to your program you could always use something specific as prefix, -- but for this use case just doing text/server-js seems rather nice :-) Deviating from set standards regarding structured data in networks solely for aesthetic reasons creates a world of pain for data consumers. I once wrote an program to check for dead links that failed in it's task quite unexpectedly when it encountered a web site whose owners decided that “HTTP status codes are not magical any more” and answered every request with a 404 (plus the actual content). All problems with hashbang javascript routing are an instance of this flawed line of reasoning (returning 200 for every link). If you do not want to appear as a sociopathic hipster programmer, please emit conservatively and use a prefix. Alternatively, register your MIME type. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
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
[whatwg] Should a textarea outside of a document be immutable?
Hi, According to the HTML specifications, a textarea is mutable if it is neither disabled nor has a readonly attribute specified. Which means that a textarea outside of a document is mutable. This is not the case for an input element. I was wondering why there is this difference in behavior here between those two elements. I believe both elements should be immutable when outside of a document. Cheers, -- Mounir
Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)
On Mon, 14 May 2012 01:30:20 +0100, Odin Hørthe Omdal odi...@opera.com wrote: All optional replacements of the src will have to be fitted in the same box as the original src. That might actually require you to specify both width and height upfront. Of course, people won't really do that, so I guess we're bound to get differing behaviour... Hm. What do people think about that? What happens here? You have no info on the real size of the picture. I guess maybe the browser should never load any srcset alternatives then? If you have no information at all it's rather hard to make a judgement. A photo gallery wants to show you a fullscreen picture, and give you: img src=2048px.jpg srcset=4096px.jpg 2x In this example, us (humans :P) can easily see that one is 2048 px and the other 4096 px. If I'm viewing this on my highres Nokia N9, a naïve implementation could pick the 2x, because it knows that's nicely highres just like its own screen. But it would actually be wrong! It would never need anything else than the 2048 px for normal viewing because it is anyway exceeding its real pixels on the screen. If srcset/picture provides authors with good way to serve images at most appropriate size, they won't need to resort to tricks with downsizing high-res images to smaller size. For a full-width image on a ~960px viewport (assuming author doesn't have better sizes available) this would be appropriate: img src=2048px.jpg srcset=2048px.jpg 2x, 4096px.jpg 4x style=width:100% -- regards, Kornel Lesiński
[whatwg] picture, `img set`, and polyfills
It’s worth noting that a practical polyfill may not be possible when using `img set`, for reasons detailed at length elsewhere: http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ http://www.netmagazine.com/features/state-responsive-images Long story short: attempting to write a polyfill for `img set` leaves us in the exact situation we were in while trying to solve the issue of responsive images strictly on the front-end. We would be saddling users with a redundant download—first for the original src, then for the appropriately-sized source if needed. Where the new element would be all but ignored by existing browsers, efficient polyfills become possible. In fact, two `picture` polyfills exist today: http://wiki.whatwg.org/wiki/Adaptive_images#Functional_Polyfills Thanks, Mat Marquis
Re: [whatwg] picture, `img set`, and polyfills
On May 14, 2012, at 4:17 PM, Mathew Marquis m...@matmarquis.com wrote: It’s worth noting that a practical polyfill may not be possible when using `img set`, for reasons detailed at length elsewhere: http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ http://www.netmagazine.com/features/state-responsive-images Long story short: attempting to write a polyfill for `img set` leaves us in the exact situation we were in while trying to solve the issue of responsive images strictly on the front-end. We would be saddling users with a redundant download—first for the original src, then for the appropriately-sized source if needed. Interesting data point. Can you explain why this is the case for the img srcset syntax, but not for the picture syntax with an embedded img? I wasn't able to figure that out, from the articles you linked. Regards, Maciej
Re: [whatwg] picture, `img set`, and polyfills
(12/05/15 7:17), Mathew Marquis wrote: It’s worth noting that a practical polyfill may not be possible when using `img set`, for reasons detailed at length elsewhere: http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ http://www.netmagazine.com/features/state-responsive-images Long story short: attempting to write a polyfill for `img set` leaves us in the exact situation we were in while trying to solve the issue of responsive images strictly on the front-end. We would be saddling users with a redundant download—first for the original src, then for the appropriately-sized source if needed. Where the new element would be all but ignored by existing browsers, efficient polyfills become possible. In fact, two `picture` polyfills exist today: http://wiki.whatwg.org/wiki/Adaptive_images#Functional_Polyfills Sorry but I don't understand why noscript as used around img by these polyfills listed can't be used along img srcset. If your point is that some Web developers will not cater for NoScript users and chose to include img in picture, I think those authors can use img srcset without @src too (if I understand correctly). Cheers, Kenny
Re: [whatwg] picture, `img set`, and polyfills
On May 14, 2012, at 8:29 PM, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/05/15 7:17), Mathew Marquis wrote: It’s worth noting that a practical polyfill may not be possible when using `img set`, for reasons detailed at length elsewhere: http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ http://www.netmagazine.com/features/state-responsive-images Long story short: attempting to write a polyfill for `img set` leaves us in the exact situation we were in while trying to solve the issue of responsive images strictly on the front-end. We would be saddling users with a redundant download—first for the original src, then for the appropriately-sized source if needed. Where the new element would be all but ignored by existing browsers, efficient polyfills become possible. In fact, two `picture` polyfills exist today: http://wiki.whatwg.org/wiki/Adaptive_images#Functional_Polyfills Sorry but I don't understand why noscript as used around img by these polyfills listed can't be used along img srcset. If your point is that some Web developers will not cater for NoScript users and chose to include img in picture, I think those authors can use img srcset without @src too (if I understand correctly). Cheers, Kenny I think I saw noscript in picasa galleries. It does seem like the always load aspect of img is leading to these techniques. They're great though for fallback. I guess we are trying to introduce images without loading them upon setting src.
