Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
80 lines (48 sloc) 5.49 KB


Project Scope

Picturefill aims to polyfill the standard features of the picture element and related srcset, sizes, type, and media attributes (some of which work on img elements without a picture parent as well). Issues and contributions that fall outside of this scope are not likely to be accepted by the project. Some exceptions include workarounds that improve browser support for standard features.

Submitting issues

While we always welcome new issues, please take a look through our open and closed issues to see if it's been brought up before. We're happy to reopen closed issues if it still persists.

FAQ / Frequent Issues

Q: Firefox isn't updating the src on window resize.
A: This is a known issue, ever since firefox added partial support in Firefox 38. It's slated to be fixed in Firefox 46.

Q: I have an issue/question about the picture element/spec.
A: Since Picturefill is only a polyfill, there's a repo for general picture discussion here.

Q: I have a question about how to use srcset, sizes, or picture.
A: Understandable—it's a lot of stuff to use! There's a handy resource from Eric Portis on srcset & sizes. Additionally, the picturefill website has a lot of demos and walks through some edge cases and how to solve them.

Working on Picturefill

Code License

Picturefill is an open source project falling under the MIT License. By using, distributing, or contributing to this project, you accept and agree that all code within the Picturefill project are licensed under MIT license.

Issue Discussion

General Picturefill discussion takes place in Slack, at To join, send an email to picturefill at Discussion of issues pertaining to the responsive images specifications takes place in the RICG IRC channel and issue tracker.

You can connect to the Picturefill Slack channel via IRC (SSL enabled).

Modifying the code

First, ensure that you have the latest Node.js or io.js and npm installed.

Test that Grunt's CLI is installed by running grunt --version. If the command isn't found, run npm install -g grunt-cli. For more information about installing Grunt, see the getting started guide.

  1. Fork and clone the repo.
  2. Run npm install to install all dependencies (including Grunt).
  3. Run grunt to grunt this project.

Assuming that you don't see any red, you're ready to go. Just be sure to run grunt after making any changes, to ensure that nothing is broken.

Development Workflow

Note: The master branch now represents the publishing branch. Anything on master should be publishable to npm and bower. When something goes into master, it gets published. Minor version branches (2.2, 2.3, etc) also exist to capture in-progress work on a particular version of picturefill. Once work on a version branch is complete, it gets merged into master to be published.

  1. If no issue already exists for the work you’ll be doing, create one to document the problem(s) being solved and self-assign.
  2. Create a new branch based off of the minor version branch you're fixing (2.3, 2.2, etc) — please don't work in the master branch directly. We recommend naming the branch to match the issue being addressed (issue-777).
  3. Add failing tests for the change you want to make. Run grunt to see the tests fail.
  4. Fix stuff.
  5. Run grunt to see if the tests pass. Repeat steps 2-4 until done.
  6. Open test/*.html unit test file(s) in actual browsers to ensure tests pass everywhere.
  7. Update the documentation to reflect any changes.
  8. Push to your fork or push your issue-specific branch to the main repo, then submit a pull request against the minor version branch you're fixing. 2.2, 2.3, etc.
  9. Once tested and +1’d by another team member (with no outstanding objections), self-merge into the branch specified in the pull request.
  10. Once ready to release to the public, merge the minor version branch into master and publish to npm and create a tag for bower.


The rules of semver don’t necessarily apply here in the case of major releases (as a polyfill for a stable spec, we shouldn’t have breaking changes), so we’re using the following:

  1. MAJOR versions at maintaners’ discretion following significant changes to the codebase (e.g. refactoring core)
  2. MINOR versions for backwards-compatible enhancements (e.g. performance improvements)
  3. PATCH versions for backwards-compatible bug fixes (e.g. spec compliance bugs, support issues)

Important notes

Please don't edit files in the dist subdirectory as they are generated via Grunt. You'll find source code in the src subdirectory!

Code style

Regarding code style like indentation and whitespace, follow the conventions you see used in the source already.


While Grunt can run the included unit tests via PhantomJS, this shouldn't be considered a substitute for the real thing. Please be sure to test the test/*.html unit test file(s) in actual browsers.

You can’t perform that action at this time.