Picturefill 2.0: Responsive Images And The Perfect Polyfill

Advertisement

Not since the early days of web standards have I seen our community rally around a seemingly small issue: responsive images.

Over the last four years1 (yeah, it’s been about four years), we’ve seen many permutations of images in responsive design. From the lazier days of setting max-width: 100% (the absolute minimum you should be doing) to more full-featured JavaScript implementations, such as Picturefill and Zurb’s data-interchange method, we’ve spent a lot of time spinning our wheels, banging our heads and screaming at the wall. I’m happy to say that our tireless journey is coming to a close. The W3C and browser makers got the hint.

The State Of Responsive Images

In our search for the holy grail of serving the right image to the user, our attitude towards browser makers until now has largely been, “Forget you — we’ll do it ourselves.” I’m certainly no exception. We were so attentive to responsive images and were exposed to all of the guesswork and trials that are not typically released to the public that we got impatient (rightfully so) and did it with JavaScript.

The difference between a CSS transition and a responsive image is, of course, how they degrade. If a CSS transition doesn’t work, who really cares? Your interface might be a little jumpy, but the experience as a whole won’t really suffer because your users will still be able to accomplish their goal and consume the content they need.

That really isn’t the case with images. How does a new image tag degrade? The img tag is so widely accepted that I couldn’t even find when the W3C recommended it as a standard, other than a small reference in the HTML 4.01 specification2. Replacing or even expanding on the img tag would be like telling Frank Sinatra to wear a baseball cap instead of a fedora — you’ll get some pushback.

Resource Problems

As responsive design grew in popularity and as the media through which users consume information became uncontrollable, we slowly realized that img by itself wasn’t going to cut the mustard. We started asking questions like, “What screen size is the user on?” and “What’s the pixel density of the screen?” These questions fuelled our image techniques until we realized that screen size and pixel density have absolutely no relationship to the amount of bandwidth available to serve up a huge high-definition image.

The RICG began working on the picture element, sharing its work with the W3C along the way.
The RICG began working on the picture element, sharing its work with the W3C along the way.

The solutions got pretty complex. Talk of the picture element started, and a group called the Responsive Images Community Group (RICG) appeared. The RICG began working on the picture element, sharing its work with the W3C along the way. The result has led us to today and this discussion about all of the progress that’s been made.

The Introduction of srcset

Because most of the responsive-image community was on board with the picture element and looking forward to it because of the great polyfills, such as Picturefill, it went ahead and released a well thought-out and fleshed-out document outlining something called srcset, which is an extension of the standard img tag. Yeah, I know — it feels like it came out of nowhere. It was also super-complicated and overly limiting by restricting you to (implied) pixel values and using a microsyntax that didn’t allow for scalability with media queries in the future. Luckily, the syntax has matured into what we have today, which is a fairly robust recommendation.

Most recently, Andrew Clark said it best when he tweeted3, “Looked at the responsive images srcset & sizes attributes for the first time. Blimey it’s complicated.”

I couldn’t have said it better myself. Let’s look at what we’re dealing with:

<img alt="dog" src="dog.jpg" srcset="dog-HD.jpg 2x, dog-narrow.jpg 300w, dog-narrow-HD.jpg 600w 2x">  

Three major attributes are in the snippet above: alt, src and srcset. The alt attribute is the same as it’s always been; src is the fallback if srcset isn’t supported; and srcset is obviously the meat and potatoes here.

We can see three arguments in srcset. The first is the image path. The second gives the browser information about the natural widths of the sources, so that it knows which resource to serve to the user (based on the user’s preferences and cross-referencing with the sizes attribute4 – I told you it was complicated). The last piece sets the optional pixel ratio (2x in this example specifies the high-definition image).

One thing I really love about srcset is that the specification states that the browser should contain image-allocation preferences for certain bandwidth situations. This means you don’t have to worry about serving a 2x image to a high-definition screen if that device is on a cruddy 3G connection. The user’s preferences should take over, and the browser would choose the appropriate image to serve.

Preparing for the picture Element

After much complaining about our new weird friend, srcset, the RICG continued working on the picture element, which is finally getting some serious traction with browser makers… well, that is, with Chrome. The proposed syntax for the picture element might look familiar because we saw it largely in the first version of Picturefill, and it’s not unlike how <audio> and <video> are marked up.

<picture>
  <source media="(min-width: 600px)" srcset="large-1.jpg, large-2.jpg 2x">
  <img alt="A fat dog" src="small-1.jpg">
</picture>  

As you can see, a source tag is in the picture element, along with a normal img tag. Just as we saw with src in srcset, the img is a fallback. In the source tag, we have what looks like a media query, alongside a srcset attribute that contains the same image-source and pixel-density arguments as before. This seems like a nice clean way to popularize responsive images; we’re generally familiar with the syntax, so it should be easily adopted.

Browser Support

The srcset attribute has been supported in Chrome5 since version 34. At the time of writing, it is not supported anywhere else. Mozilla appears to be working on an implementation (fingers crossed). Internet Explorer is nowhere in sight.

The picture element has even worse support; it isn’t even in Chrome yet. But like Mozilla with srcset, Google is currently working on implementing it. If you can stomach reading through a specification, I highly recommend it. Even though there isn’t much of a plot and the character development is pretty weak, it’s still a pretty good read.

Picturefill 2.0 was created because native support is reasonably close. You know we’ll need a rock-solid polyfill to use when the time officially comes, so let’s take a look at it!

Introducing Picturefill 2.0

Picturefill 2.06 was recently released as beta, and it’s quite a large jump from version 1. The RICG really aimed to create a one-stop solution for responsive images. The challenge was to create a script that allows you, the developer, to use any combination of the solutions currently being standardized, without bloating it to the point that not using it at all would be more lightweight.

Imagine polyfilling an image that would normally take 2 seconds to load using a JavaScript file that takes 10 seconds to load — it wouldn’t make much sense. Picturefill 2.0 avoids this by following the specification very closely (with some intentional omissions, which we’ll go over in a bit) and letting you use either srcset or picture or a combination of the two.

Picturefill is an responsive image approach that mimics the proposed picture element using divs.7
Picturefill is an responsive image approach that mimics the proposed picture element using divs. (Larger version8)

While we can’t reliably achieve everything in the specification using JavaScript (such as reasonably detecting bandwidth, which would be a user setting anyway), we can certainly take care of all of the pieces that are meant to be in HTML (i.e. elements and attributes). This version of Picturefill gets us one step closer to not needing Picturefill, which is the ultimate goal of anyone who has ever written a polyfill.

If you’re currently using version 1.0, I highly recommend upgrading to 2.0. It’s a big step towards a better solution to serving the correct image to the user. Some big changes have been made to the syntax and functionality. Let’s look at what’s new.

What’s New in 2.0

One thing that makes this polyfill different from others that I’ve seen is that it polyfills a concept, not just an unsupported block of HTML. Picturefill 1.0 used spans and custom attributes to mimic how we thought responsive images should work. For the record, it is a great solution, and I currently use it for many of my projects that haven’t been converted to 2.0.

In the last year or so, the specification for srcset and picture have matured so much, so we can now actually get to use something close to the real syntax. Picturefill is starting to look like a true polyfill, one we can strip away when real support shows up.

Installing and Using the Polyfill

If you’ve read this far, then you’ve probably dealt with some form of polyfill in the past. This one isn’t much different. Polyfills are supposed to be set-it-and-forget-it (to steal a line from Ronco9), but because this is an HTML polyfill, you’ll need either to create the picture element manually or use some form of HTML shiv to do it for you. Luckily, HTML shivs are pretty common and ship with toolkits such as Modernizr10; just verify that picture is supported in whatever shiv you choose.

<!-- Create the actual picture element if you haven’t already. -->
<script>
  document.createElement( "picture" );
</script>

<!-- Asynchronously load the polyfill. -->
<script src="picturefill.js" async></script>  

Other than creating the picture element, you simply have to link to the script. Using the async attribute is also recommended, so that Picturefill doesn’t block your page from loading.

Using Picturefill 2.0 With srcset

Let’s look at the syntax that provides the best support and that uses srcset. It should look familiar because it has the same attributes that we saw when discussing the specification.

<img sizes="100vw, (min-width: 40em) 80vw"
srcset="pic-small.png 400w, pic-medium.png 800w, pic-large.png 1200w" alt="Obama">  

The most glaring difference between this snippet and the specification is the absence of a fallback src attribute, which was intentionally removed to prevent images from being downloaded twice in unsupported browsers. And, really, what would be the point of this if images were downloaded twice? Other than that, it’s pretty faithful to the specification, but it will probably evolve over time as the specification fleshes out and the polyfill matures.

The sizes attribute tells the browser of the image’s size relative to the viewport. This often gets overlooked because srcset is the buzzword now, but this attribute is equally important. If you’d like to learn more, Eric Portis makes a lot of sense11 of this “blimey complicated mess.”

Using Picturefill 2.0 With the picture Element

The RICG did such a good job with this second version of Picturefill that the syntax of the picture element should come as no surprise. It matches the specification very closely:

<picture>
  <source srcset="extralarge.jpg, extralarge.jpg 2x" media="(min-width: 1000px)">
  <source srcset="large.jpg, large.jpg 2x" media="(min-width: 800px)">
  <source srcset="medium.jpg">
  <img srcset="medium.jpg" alt="Cambodia Map">
</picture>  

The biggest change between versions 1.0 and 2.0 is the removal of some traditional HTML (divs and spans) and the addition of newer elements (picture and source). Also, srcset support is built in (heck, why not, right? It’s in the spec!). This is great step forward for this polyfill.

Use as many or as few of these options as you’d like. In line with the specification, if you don’t want to use the 2x option, you don’t have to (and so on). The difference between this and the official picture element is the img fallback. You’ll notice here that the img fallback also has a srcset attribute, instead of a normal src (which is widely supported). Again, this is to prevent double-downloading (it’s a real problem). The srcset in the img tag would also cause double-downloading if the browser supports srcset but not picture. This bug should get worked out in the beta version.

Like many good polyfills, Picturefill 2.0 can be executed programmatically by exposing a global function, picturefill(). This allows you to use it in any ultra-hip JavaScript framework that you’d like. You can read about a few options for targeting specific images in the API documentation12.

Degrading Gracefully

Earlier in the article, I alluded to the challenge of degrading the img tag gracefully in unsupported browsers. This was another problem in creating Picturefill 2.0. Because it is a polyfill, the concept of unsupported browsers doesn’t really exist (kind of) — we’re using JavaScript to force it to work.

The edge case is this: If a browser doesn’t natively support picture or srcset and has JavaScript turned off, then you’ll get a frowny face. I can already feel your eyes rolling, but knowing the limitations of a system is important before you rely on it on a large scale. If a user were to come across a Picturefill’ed image in an unsupported browser with JavaScript turned off, they would see the image’s alt text — a nice little way to reinforce the importance of descriptive and meaningful alt text, isn’t it?

Alternative text is the fallback because the previous <noscript> solution caused problems with browsers that support picture or srcset but have JavaScript disabled (two images would render). The group also explored adding a src attribute to img (as in the specification), but that results in double-downloading, which defeats the purpose of allocating the appropriate image assets to the user.

We’ve come a long way with responsive images. We can see the light at the end of the tunnel, but a lot of work still has to be done. And we’d love your help!

How To Get Involved

If you’d like to get involved and help out with the responsive-images movement, join the RICG13 via the W3C. If that’s too much, we’re always looking for people to try out Picturefill’s beta version and submit bugs through the issue tracker on GitHub14.

You can also spread the word about great tools like Sizer Soze15, which calculates the performance cost of not using responsive images.

Resources and Further Reading

(al, ml)

Footnotes

  1. 1 http://alistapart.com/article/responsive-web-design/
  2. 2 http://www.w3.org/TR/html401/struct/objects.html#h-13.2
  3. 3 https://twitter.com/Malarkey/status/458336077934522368
  4. 4 http://ericportis.com/posts/2014/srcset-sizes/
  5. 5 http://caniuse.com/#search=srcset
  6. 6 http://scottjehl.github.io/picturefill/
  7. 7 http://www.smashingmagazine.com/wp-content/uploads/2014/05/01-devices-opt.jpg
  8. 8 http://www.smashingmagazine.com/wp-content/uploads/2014/05/01-devices-opt.jpg
  9. 9 https://www.ronco.com/
  10. 10 http://modernizr.com/
  11. 11 http://ericportis.com/posts/2014/srcset-sizes/
  12. 12 http://scottjehl.github.io/picturefill/#api
  13. 13 http://www.w3.org/community/respimg/
  14. 14 https://github.com/scottjehl/picturefill/issues
  15. 15 http://www.sizersoze.org/
  16. 16 http://responsiveimages.org/
  17. 17 http://picture.responsiveimages.org/
  18. 18 http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/
  19. 19 https://twitter.com/respimg

↑ Back to topShare on Twitter

Tim Wright is the Senior User Experience Designer and Developer at Fresh Tilled Soil, a UX design agency out of Boston, MA.

Tim is a frequent speaker, blogger, article writer, and published author. In fact, he recently wrote a book on JavaScript: Learning JavaScript: A Hands-On Guide to the Fundamentals of Modern JavaScript. You can find more of his writings at CSSKarma

Advertising
  1. 1

    Nice article, although it’s been covered widely before. I do have a hint of criticism though. We’ve been dealing with this issue for so long, what’s another year? I think time should be spent on trying to make browsers adopt the technique, rather than working on yet another makeshift way to do something browsers should just support anyway. Not a dig at the author, I’m just saying, lets make this happen already.

    I think the feature would be amazing for image heavy sites. Portfolio sites especially, such as Behance who need to serve multiple sizes of the same image.

    9
  2. 2

    Ivan de la Jara

    May 12, 2014 1:03 pm

    Cutting the image is the antitesis to perfect for me

    5
  3. 3

    Francesco Spreafico

    May 12, 2014 1:41 pm

    It really sounds great, but having to rely on JavaScript to load actual content of the page… that really doesn’t work for me.

    Also, would search engines see images without an src? (This would not be *my* primary concern, but I’m sure clients would worry about that).

    Still I love everything people is doing to get us and srcset as fast as possible!

    10
    • 4

      Josh Kieschnick

      May 12, 2014 3:08 pm

      With the fallback image being in the html source, search engines would still see the alt text of the fallback image.

      2
      • 5

        I’m not sure I understand what you mean… search engines will se the alt attribute, yes, but they will not see the image url, so the image won’t be indexed. I’m talking about image-indexing, not text-indexing.

        Am I missing something?

        0
    • 6

      If only HTML had an element for linking to image URLs without loading them. If javascript is not available (or fails to load or run) then the end-user could click on the element and be taken to the image page. If JS runs then it replaces inert linking element with an [img src="..."].

      The markup might look something like:

      [div class="picture"]
      Here’s a picture of
      [hyperlink href="medium.jpg"]A kitten in a shopping bag[/hyperlink]
      [hyperlink href="large.jpg"]Large[/hyperlink]
      [hyperlink href="small.jpg"]Small[/hyperlink]
      [/div]

      -1
      • 7

        You could do that now, by using a hyperlink.

        Assign those links a particular class (or better, use data- attributes) and then have your JavaScript just cycle through all matching links, loading the image to replace the link, based on the user’s device or the width of the parent element.

        1
  4. 8

    Carlo Rizzante

    May 12, 2014 3:36 pm

    Awesome. I’ll surely adopt it starting with the next very project.

    Thanks for the update on Picturefill 2.0 and a neat article about.

    2
  5. 9

    Irwan Sulistyanto

    May 12, 2014 5:22 pm

    Realy nice to be here because my site full of image in every article. By using your way hopefully my next project wll be better

    -1
  6. 10

    Jonathan Steinfeld

    May 12, 2014 5:44 pm

    Seems that CMSes start implementing support for :
    https://www.pimcore.org/en/resources/blog/pimcore+2.2+released_b442

    Awesome!

    0
  7. 12

    This is great. As someone following the ups and downs of responsive image processes, I’m glad to see some of these solutions still evolving.

    0
  8. 13

    Great Article Tim. Thought I’d contribute a helpful link for anyone wanting to simply the generating all those image variations required for the picture syntax. http://www.resrc.it is a service that can optimize and deliver perfect images on any device. Its really straight forward to use with the picture syntax. Might be a useful link for readers of the comments.

    4
  9. 14

    Whatever happened to the idea of multiple sizes built into the image itself? Some meta data calls etc to the css media query and maybe we’d be saving heaps of time…and data. Remember the old Kodak PhotoCD format? http://en.wikipedia.org/wiki/Photo_CD Or LivePicture’s iVue, or FlashPix?

    Perhaps a rethink of PNG (and aPNG) to handle the various Pyramid style resolutions, animations etc could’ve been conceived and approved within the last four years that everyone’s been working out solutions for the browser. Google’s WebP (Weppy) format still buzzes along, but hasn’t had much press that I’ve seen.

    3
    • 15

      Yeah… like many also rated Microsofts Photosynth project back in the days, yet we seek so many complicated solutions in unwritten web standards. This would only be necessary if we want to markup the pictures themselves somehow, but most of the time we just need a “simple” display depending on a few factors we sometimes don’t even know when delivering the content but only the client itself. So any extension to the established methods (actually – how did it get to that point anyway) is just another variant of guessing and messing so far.

      0
  10. 16

    The ATSC HD standard is 1920 by 1080 pixels, therefore, why not size all your images within this size constraint and be done with it. The images will shrink and scale perfectly and anything larger then this size is unnecessary, unless you’re targeting a specific ultra high definition device.

    -13
    • 17

      Bandwidth.

      Mobile viewers of your site won’t be happy about the time or cost of downloading all your HD images.

      Also art-direction. See
      http://blog.cloudfour.com/a-framework-for-discussing-responsive-images-solutions/

      4
      • 18

        You obviously are not aware of the current trend of screen aspect ratio design. One size does fit all. I think you are saving you’re images the wrong way if you are having bandwidth troubles.

        -12
        • 19

          A typical HD image (1920×1080) is around 200k in JPG format (at around 80% quality).

          If you take the same image and say make it 480 pixels wide at 144 PPI (small mobile) then it will be around 20k.

          That means your user would be downloading 10 times more image than they actually need. With 10 images on the page the user would be wasting 1800k (1.76Mb) per page. A user isn’t going to be happy navigating your site using all of their data allowance and plus it will be slow for them, especially if they are unlucky enough to have a poor mobile signal – just think, if a user looked at your page each day for a month they’d waste 52.7Mb (54,000k) and that doesn’t even account for any other content you may have.

          2
    • 20

      so you’re not getting the problem, yet.

      1
  11. 21

    Whilst this article is great, and its good to see some (painstakingly slow) progress… Feels fundamentally wrong to me that the presentational variants are being defined in the HTML instead of the CSS?

    img.arbitrary {
    image-type:responsive;
    @media only screen and (min-width: 600px) {src:’/image600.jpg’}
    @media only screen and (min-width: 990px) {src:’/image990.jpg’}
    @media only screen and (min-width: 1366px) {src:’/image1366.jpg’}
    }

    It’s early, and I’m thinking out loud really but just feels like a CSS issue rather than a mark up issue?

    Although; then how do editors of the site provide images I guess is the real world problem with that.

    6
    • 22

      I agree with Jamie. So many of us deliver solutions built in a (often limiting) CMS, and we therefore prefer to have as little “in-line” mark-up as possible. I hope to see the W3C and browser developers integrate better CSS support for this development…as well as background images. Either way, good article.

      1
    • 23

      Jamie

      Why not use the “content” property? Works for me. It may not keep the SEO nazis happy tho… :D

      You can leave the src property empty in the html too.

      CSS like this:

      @media only screen and (min-width: 600px) {
      img.test {
      content:url(“http://lorempixel.com/350/100″);
      }
      }

      @media only screen and (min-width: 800px) {
      img.test {
      content:url(“http://lorempixel.com/450/200″);
      }
      }

      @media only screen and (min-width: 1000px) {
      img.test {
      content:url(“http://lorempixel.com/550/300″);
      }
      }

      1
      • 24

        I suppose what I was writing was a suggestion for how it could work… rather than for now (I think I made it up, don’t think you can wrap media queries within rules can you?).

        I have hacked many things on our website using content but I’m not sure it would be ideal.

        Its frustrating how slowly standards and browsers develop to catch up with real technical developments that effect everyone working in the community. My firefox GUI has been redesigned again in the latest update, but we’re still trying to hack responsive images in 2014.

        I’m not sure if I am right on the article subject but does just seem to me that any progression of standards and support for responsive images should focus on giving CSS the power to specify the responsive variants… otherwise we are back to using HTML to define presentation. Feel free to tell me I’m wrong though.

        1
        • 25

          +1 “Its frustrating how slowly standards and browsers develop to catch up” and the Firefox GUI priority over responsive too.

          On the one hand I agree this is a CSS issue; however, if you are writing dynamic html, you then need to write dynamic CSS as well. Creating CSS on the fly is not something browsers do, unless you embed it head/foot or inline it. (And inline doesn’t support media queries anyway)

          Although, you can also embed in body, but that is considered a big no. There is a “scoped” argument for the style tag, to make it acceptable, but is only supported by FF so far.

          So, how do I manage responsive images in CSS if I can’t easily create it on the fly?

          What we probably need is tighter integration between the img tag and CSS. The img tag is getting too complicated. So instead of everything being in the image tag, move the responsive aspects to CSS.

          And the CSS “content” property could be extended with a “source” value.

          So, here’s a rough idea of how it could all fit together.

          eg html: img src=”pic1.jpg,pic3.jpg,pic3.jpg” class=”mypic”

          e.g. CSS:
          img.mypic {
          content:none;
          display:none;
          }
          @media (max-width:599px) {
          img.mypic {
          display:none;
          }
          img.mypic:nth-child(1) {
          content:source;
          display:block;
          }
          }
          @media (min-width:600px) {
          img.mypic {
          display:none;
          }
          img.mypic:nth-child(2) {
          content:source;
          display:block;
          }
          }
          @media (min-width:800px) {
          img.mypic {
          display:none;
          }
          img.mypic:nth-child(3) {
          content:source;
          display:block;
          }
          }

          What this CSS is saying is don’t load the source until it’s required for display and then don’t display it except when required. All using existing CSS properties.

          Also, you could have a name type attribute in html tag, to correspond with each src, so that you could use that name instead of the number in the CSS.

          I do absolutely agree though, that if we can do it in CSS we should, because then we can change the appearance without touching the structure. And that follows good coding principles.

          1
        • 26

          BTW This example is so much better than my first, because the CSS is “dumb” in this example. That is, it is ignorant of the content itself. Which makes it easily reusable on any image element or any image element with the class mypic. (Whereas my first example was locked to specific images, so only works on the specific element therefore requiring separate css for every image. Eek!)

          0
  12. 27

    Although promising; the vast majority of these solutions miss a big part of the problem – generation of all these image sizes. Services are available (such as ReSRC.it) that can take out the heavy lifting of processing and delivering whatever image size, without the hassle of batch processing. Most of them have JS polyfills until picture becomes wider supported.

    6
  13. 28

    Just a note on the first example with: “dog-narrow-HD.jpg 600w 2x”
    It is better not to use the w- and the densitiy decriptor at the same time, so it should rather be:

    dog-narrow-HD.jpg 600w
    or
    dog-narrow-HD.jpg 2x

    “1x/2x & w do not mix. Don’t use both in the same srcset” (http://ericportis.com/posts/2014/srcset-sizes/)

    -1
  14. 29

    Esther Brunner

    May 13, 2014 1:22 pm

    Thanks Tim for this great article. I though feel a little unease with declaring breakpoints in HTML again. A perfect solution for responsive images would rely on breakpoint definitions in CSS, imho. There’s an interesting blog post by André Abt who explores this idea:
    http://www.andre-abt.com/2013/09/16/responsive-breakpoints-and-images/

    1
  15. 30

    Great article Tim! And the saga continues! Although these “in the meantime” solutions are inspiring and aid in the process of finding a holy grail a.k.a. picture tag with browser support across the board.

    1
  16. 31

    This all seem very nice indeed, but is all this “anxiety” over the images really worth it? I mean I have yet to find a production situation where the images are a problem. Are you doing all this for the 1-2 seconds more that a page will do to load?
    With 4G on mobiles, sites load even faster than with regular T1 connection.
    Don’t get me wrong its all good and nice to have, but is going from to

    really worth it?

    1
  17. 32

    Crying web designer

    May 14, 2014 12:29 pm

    :( you’re killing me here. I thought things should be more streamlined as they got better? I think this is exactly the kind of thing putting web developers into early graves.

    1
  18. 33

    hi there,

    Anyone knows why is this not working?

    http://jsfiddle.net/79×83/1/

    -1
  19. 34

    Spadicton Njoroge

    May 14, 2014 7:04 pm

    There is a photo of me posted by this service and that i have heard from a friend and from what he has told me it’s not that nice would you kindly address to that and take them down please.

    -2
  20. 35

    Meinaart van Straalen

    May 14, 2014 8:29 pm

    Nice article and nice polyfill. However there are a few major problems with this implementation:
    - No real fallback because “src” is omitted
    - Search engines won’t be able to index your images any more. Not a problem for some sites but a huge problem for others.
    - Omitting the src causes some browsers (IE, can’t remember which versions) to try to load the current page as an image.
    - You disable preloading of images by the browser. Which has a huge impact on performance.

    Downside with include a src is off course that the browser (pre)loads the image in the src element even though it might be replaced by PictureFill. So it’s choosing between 2 evils here. This is especially a hard choice for truly responsive sites where you would also have the bandwidth consideration for mobile devices. That could be partially solved by some kind of server-side browser-sniffing. But this would be hard to implement for sites that have a caching solution in place.

    I think it will remain quite challenging. But since mobile browsers tend to be quite modern they will probably soon implement and srcset. If that’s the case then there is less reason to omit the fallback src attribute.

    You would think that Apple/Safari would be one of the browsers that would implement this the fastest. Apple is pushing the whole DPI-race with their Retina screens on their laptops. MacBooks with Retina screens would really benefit from this technique.

    2
  21. 36

    Regarding the fallback with noscript, when the browser supports picture or srcset and has JS disabled:
    What about hiding the picture or image with srcset with css like this:

    .no-js picture > img,
    .no-js img[srcset] {
    display: none;
    }

    then you would only see one image (although both images will be loaded).
    but this seems to me no big problem, since i guess users with modern browsers AND js disabled are a small minority.

    1
  22. 37

    Portfolio are looking text art but those are good.

    -4
  23. 38

    I’d be interested in seeing a super lightweight version that only supports secs . Anyone know if this is in the works?

    0
  24. 39

    Is the picture element officially approved as a standard?

    1
  25. 41

    Nice! About year ago I built something like this for personal use – https://github.com/nickbrit/ResponsiveImageResizer
    But it’s more powerful, of course. Thank you for article.

    0
  26. 42

    Is there any CMS out there that will support this kind of thing? I imagine not, but if there is can’t see the implementation being straight forward.

    Many of my clients struggle simply resizing a single image for inclusion on a web page (Let alone creating several sets of images).

    1
  27. 43

    I saw this last week. It appears to be the original request for an tag from Marc Andreesen on February 25th, 1993.

    http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html

    0
  28. 45

    And Retina.js where does this story?

    0
  29. 46

    No good to me. I still have to support IE6 :(

    0
  30. 47

    I’ve been using background images and divs that retain their aspect ratio using padding to achieve this effect. Having a usable polyfill that emulates the standard support is a boon to those of us struggling with this.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top