Introducing srcset, our first step towards fully responsive images in Microsoft Edge

Windows 10 Insider builds recently introduced support for srcset, our first step on the path to fully supporting the picture element for responsive images. In this post we’d like to share more about our initial implementation of srcset in Windows 10 and our strategy for bringing more components of responsive images to future releases.

What is srcset?

Srcset is an attribute on the image element that allows you to declare a set of images and their scale factor (pixel density descriptor). This allows browsers to select the best image for the device currently in use. Here’s an example of an image with various versions defined in its srcset:

Note: In order to ship our implementation of srcset in time for Windows 10, Microsoft Edge currently does not support the width (w) descriptor – we’re working on adding this in a future update.

In the above example, the browser collects all of the images in srcset and src, determines which image is best for the user’s device, and only downloads that image. This is a vast improvement over how the majority of srcset polyfills work, as most either do this via a data-* attribute (which has the downside of the src still being downloaded via the pre-parser) or by adding the image via script (which results in potential wasted time to first paint). The srcset attribute allows the browser to take advantage of the pre-parser, but download only the image the user needs.

Picturefill and the RICG, bringing responsive images to the masses

Picturefill is a very popular responsive images polyfill that provides developers with every component of what makes up responsive images:

• original srcset with density descriptors
• extended srcset allowing width descriptors
• the sizes attribute
• the picture element

Picturefill, along with the Responsive Issues Community Group (RICG) is one of the first libraries to accomplish what the Extensible Web Manifesto is asking for. Picturefill came onto the scene to provide a library that efficiently solves a common problem, and took the additional step of helping it get standardized via the W3C and the WHATWG.

We estimate¹ that Picturefill is used on millions of sites, including a number of the most popular sites on the Web. This allows authors the freedom to use responsive image technologies today in a progressively enhanced manner, and allows the specification editors to make changes based on author feedback.

How does Picturefill fit in with Microsoft Edge’s srcset implementation?

When we implemented srcset, we initially included the currentSrc API, as detailed in the spec. This API allows a web developer to see which image source was actually selected by the browser. If you’re following along with some of those tutorials, you may notice it’s missing . Upon an initial flight of this feature, we quickly received numerous bugs about sites not rendering images or redirecting to error pages. After reducing the problem, we discovered that it was caused by an assumption in Picturefill that if the browser doesn’t support the picture element, it must need Picturefill to polyfill all of the components that make up responsive images.

We considered several options in order to get an early implementation out to our Windows Insiders in time to get feedback and discover bugs:

1. Remove srcset completely and only add it back in once we have picture, sizes and srcset implemented
   We rejected this because we believe there is value to releasing our early implementation of srcset, as evidenced by Safari’s similar implementation. Additionally, it felt like taking a step backward rather than forward.
2. Make currentSrc writable
   This was initially a tantalizing option as this would provide us with compatibility with the Picturefill polyfill and web developers could use the API freely. However, this approach would result in Microsoft Edge going against the spec, and has potential interoperability impacts. A web developer may inadvertently leave code where they were trying to set currentSrc and no browser would update that currentSrc value besides Microsoft Edge. One of our goals is to follow standards while working with today’s code. We didn’t want to add more confusion and non-standard functionality that holds back the interoperable web – no matter how convenient it would be. Additionally, we had to consider the risk of developers taking a dependency on this capability and not being able to change this easily in the future.
3. Don’t throw the exception when trying to write to currentSrc
   This is similar to option 2, in that it could risk dependencies in “use strict” mode to not throw errors on currentSrc (such as Picturefill would be if we went this route), would go against the ECMA standard, and would require custom logic in our code just for currentSrc.
4. Remove currentSrc and ship srcset without it.
   We knew this would be web-compatible as this is how Safari has been shipping srcset. Furthermore, we could keep srcset in the codebase.

Considering all of the above, we decided on option 4, and chose to reach out to the Picturefill team to let them know about the issue with the hopes that it could be patched in a future release of the polyfill. Recently, Safari began hitting this issue and decided to go the same route as Microsoft, further validating this approach.

I want the currentSrc API in Microsoft Edge–what can I do?

Update Picturefill!

In order for us to comfortably release a build to our Insiders with currentSrc enabled, we have to see the usage of Picturefill versions less than 2.3.1 drop tremendously. If you manage a site (or know someone that does) that uses Picturefill, please update to any version later than 2.3.1. The Picturefill team was very prompt in handling our concerns regarding this issue and had a patch in a matter of days put into build 2.3.1.

This is a low-risk update; Mat Marquis of Bocoup (and one of the main contributors of Picturefill and RICG) wrote in a recent CSS Tricks article about this issue: “There haven’t been any breaking changes in any version of Picturefill 2, so you shouldn’t run into any issues updating.”

Additionally, we encourage you to vote for the following features on our User Voice page, as this helps us when ranking new features to implement:

• Support of the width descriptor in srcset, and the sizes attribute
• picture element

Ultimately, currentSrc will make its way back into Microsoft Edge–it’s just a matter of when. Depending on Picturefill 2.3.1 adoption, we’ll evaluate a preview release to Insiders; otherwise, we’ll wait to restore currentSrc until after we get picture fully implemented.

Do component based feature detection

Responsive images are made up of many different pieces and support for one does not imply the support for another. If you plan to roll your own feature detection, make sure not to do feature detection on just one piece and make an assumption based on that.

Here is an example of how to do feature detection for the various aspects of responsive images:

Looking forward

We’re thrilled to preview our early implementation of srcset in Microsoft Edge, as it’s a great start towards lighting up all of the features encompassed in responsive images. I look forward to when we add srcset with width descriptors, sizes and picture in the near future!

– Greg Whitworth, Program Manager, Microsoft Edge

¹We reached this estimate by crawling a random set of 500 thousand sites and found that 3% of the sites were actively using Picturefill. If we extrapolate that to the estimated 978 million active sites that results in approximately 29 million sites. Based on this we can safely conclude that there are millions of sites utilizing picturefill.