Modernizr

While Modernizr was meant from day one to eventually become unnecessary, that day is far from here, and so development on the library goes on. Some of the things we’ve been busy with: Version 3 Modernizr v.3 is not a mere version bump with some new ... [More] additions; it is a complete architectural rewrite of the entire library and all of the 150+ community feature tests. The team and some of our great contributors have worked tirelessly to convert all of the tests to facilitate a new loading structure based on AMD, and are currently embedding the tests with important meta-data such as known issues, sample usage and more. There is a new site in the making as well, with a new documentation page taking your feedback into account (feel free to fill out that survey if you haven’t yet), and a new download page that makes it much easier and faster to create the custom build that you need. You can help make v.3 become a reality by closing issues, or by updating open Pull Requests to the new v.3-compatible format for tests (see this example for what that looks like). Stickers! While we work on version 3, you can show your support with some fancy new Modernizr stickers, courtesy of the fine folks at DevSwag. Put these stickers on your laptop, fixie bike, and anything else you’d like to “modernize” (ahem). The stickers are just $6 for a pack of four, and all of the proceeds that go to Modernizr will be donated to the Ada Initiative. All of us here at Modernizr care deeply about having a healthy and diverse community of developers, and the Ada Initiative does great work that we support. Diversity in tech & open source The tech community, and in particular open source, is currently quite male-dominated. By itself that’s not so much of a problem, but it becomes more of one when it leads to increasingly male-specific behavior and cultures, which can be hostile and alienating to various groups—other men included. Currently in tech, typically male behavior such as aggressiveness is rewarded with more visibility and, consequently, more opportunities. Discussions online, whether they’re about community diversity, ruby vs. python, or tabs vs. spaces, often devolve into a lot of verbal aggression, breeding an angry and hostile culture from which no one really benefits. Similarly, a harmless joke here or there isn’t a big deal, but the same kind of jokes over and over again breed a certain culture, and that culture is often exclusionary to people who don’t care for those jokes. When this happens within a small group of people, it’s one thing. When it happens industry-wide, we’re excluding people from our field altogether, and that is a terrible thing that fundamentally undermines the meaning and value of our work. “Merit” is a total fallacy if you only allow a certain kind of people to be measured for it. Our industry is vast and encompasses many different types of people. It is time to stop having this belief that tech, web development, or open source, is a community composed entirely of “other people who are just like us,” and that it gives us carte blanche for behaving however we want, or for saying whatever we want. Sexist, misogynist, racist, homophobic and otherwise exclusionary language, jokes and slurs—whether we put them in commits, source code, or comments to blog posts—are absolutely unacceptable. It’s time for us to stop trying to get the industry or community to behave according to the rules set forth by the most vocal majority. Each and every one of us deserves to be respected and listened to, to not be shouted down by an angry mob. We should not judge our peers solely by the quality of their code or pixels: that’s dehumanizing and wrong, and encourages individualism. It’s time for us all to embrace the diversity that we represent: different people from different backgrounds with different skills, ideas and opinions. Since Faruk first started Modernizr in 2009, it has evolved through a collective, social effort. This wouldn't have been possible without the vast range of different contributors, each bringing their own unique slant. It’s ultimately this diversity that has allowed Modernizr to be the broad-reaching tool it has become — and it will only be able to continue to grow and improve if it sticks to and supports these ideals across the entire community. [Less]

Modernizr detects features in browsers based on the APIs they expose to enable that feature. However, sometimes a browser vendor will implement a feature, but its implementation is buggy; for instance, its API exists but the output is not rendered ... [More] , or the feature doesn’t work right—or even at all. This sometimes results in what we call “False Positives”: a feature that tests positively, but is not reliable or usable. (For example, Opera Mini provides a false positive for CSS Gradients.) Other times we might calls these plain “browser bugs,” issues in the implementation that doesn’t affect the common use but is an edge case issue. (For example, box-sizing doesn't work with min-height in Firefox.) False positives are a developer’s nightmare: they can be hard to discover, even harder to fix, and are almost always frustrating. So what can we do? Modernizr aims for accuracy in tests based on their associated ECMAScript, HTML and CSS specifications. Yet sometimes something slips past and it reports a false positive. We are in the process of documenting these cases and putting them in one single page for easy consumption. Found a false positive? When you encounter a false positive, add it to the Modernizr Issues tracker. We will give it the “False result” label. Also please clearly describe which browser(s) it is a false positive in, and whether the implementation is buggy, broken or incomplete. Wherever possible, we will attempt to work around the issue (for example: forcing a reflow, adding the element to the DOM, etc), though as a last result we will add a UA sniff. We'd appreciate your help with a pull request, as well! Above all: report false positives to their respective vendors’ bug trackers. (Many times it's a mobile port of WebKit that has the problem; while it may not exist in other WebKit ports, you can file these at the WebKit tracker regardless.) That is the best way to get these issues resolved, and helps Modernizr to be a great feature detection library. Browser bug? We agree that browser bugs should be detected instead of assumed for given UA strings. This is how jQuery.support works. However, Modernizr detects features and will not be collecting bugs. We do recommend you file the issue with the appropriate vendor and blog about it or post on Stack Overflow to get the word out there with your proposed fix. Thanks Modernizr will strive to report accurately, even if the browser is returning a false positive for the correct detect. [Less]

Summer is over, back to work! We’ve released Modernizr 2.6.2 with a number of new detects, bug fixes, and test improvements for your modern development needs. Some notable fixes include: Fix for a hilarious edge case in Safari where if you ... [More] set your body or html element to overflow-y: scroll and apply styles to the webkit-scrollbars (see demo), the browser spontaneously refreshes HTML5 Shiv got a fix for better compatibility with jPlayer Generated Content false-positive fix for IE7 Fix for our download builder and turning off css classes Better Travis CI output for unit tests using grunt All incoming pull requests are tested against our test suite with Travis CI Detects We’ve also added some new detects: Content Security Policy CSS's object-fit position: sticky; @supports : CSS's new native feature detection viewport unit tests: vhunit, vmaxunit, vminunit, vwunit input[form] attribute new iframe attributes: sandbox, seamless, srcdoc PointerLock API Test improvements And lastly, there have been updates to these tests: background-size: cover css filters css subpixelfont elem-track - reflecting partial support by IE10 gamepad api For more details on the exact code changes of this release, see the full changelog on Github. We thank our great dev community who have contributed much of the work for this update. Thanks to their moms and dads, too. [Less]

Modernizr 2.6 is now available. Below is a summary of the major changes. The full diff is also available. You can download the latest at the builder. You must upgrade if you're using geolocation or flexbox; otherwise you only should upgrade. ... [More] Detects We’ve added a lot of new tests, many of which by the community, and updated existing ones: Geolocation used to be a trivial detect but two issues have come up recently that make it trickier. If you're using your own detect, read the details. The ESR release of Firefox exposes MozWebsocket whereas every other supporting browser uses the standard WebSocket. We've quickened and simplified our detect accordingly. We got a last minute pull request from David Baron, the czar of Gecko, who recommended we don't allow Modernizr.testProp('pointer-events') to pass, and instead require the camelcased equivalent: pointerEvents Opera fixed a bug affecting the <input type=color> detect, so we've sped up and simplified our detect. Our detect for flexbox has been updated as the new spec had naming changes. The detect for the flexbox implementation that you see in older mobile WebKit is now available as flexboxlegacy (without a hyphen). Our WebGL test got much faster, though it is less reliable. We made this decision because many Modernizr users include all tests they don't use and the earlier WebGL test could last for 500ms sometimes. If your site or app relies on the WebGL test, make sure you also have a fallback in case the context creation fails. It can fail due to inadequate GPU or lack of graphics memory, see also recovering from a lost context. Plenty more inline documentation added about detection weirdness. The source comments are a fun read. As well as tightening up support for existing tests, we've also added a number of new detects, many submitted by the community: blob-constructor css-backgroundposition-shorthand css-backgroundposition-xy css-calc css-filters Detecting the new CSS filters, but not catching the legacy IE filter property. css-lastchild css-mask This correctly finds the WebKit mask property without a false positive on Firefox's SVG mask support. css-regions Contributed by Adobe. css-subpixelfont exif-orientation Did you know iOS Safari is the only browser to use the orientation bit in EXIF and rotate the asset accordingly? Well, Modernizr does. forms-fileinput Detecting <input type=file> not working on iOS <6 dart network-xhr2 Which has an interesting testing story style-scoped svg-filters Only detects SVG filters appling to SVG content. SVG filters on HTML is awaiting. vibration You can view all of these detects on Github and add them in the download builder today. Dependencies html5shiv is now up to 3.6, fixing some edgecases users ran into yepnope was updated to 1.5.4 Development Workflow: We're using EditorConfig to keep our whitespace policy consistent GruntJS powers our automatic linting and minification now. We are integrated with Travis, so after all commits, Travis runs our test suite in a headless WebKit via PhantomJS. Up next, we're going to clarify our touch detect: Is it detecting touch devices or touch events; and which touch event model? We're also going to redesign the download page and update the documentation with some more approachable documentation. As always, if you'd like to get involved, hop into the Github issue tracker. [Less]

Modernizr 2.0 came out more than eight months ago; we’ve not sat still in the period since, and today we’re proud to announce the release of Modernizr 2.5, our biggest update yet! New in 2.5 The list of new things in 2.5 is too big for Github ... [More] to handle, but here are the highlights: More than 60 new feature detects for emerging browser features; check out the full list or peruse all of the community-driven tests in our feature-detects folder. We now have a super robust and integrated test suite. Paul did a great video detailing how it works. Brand new embedded and included micro-libraries: html5shiv 3.2 and yepnope .js 1.5. Modernizr.prefixed() can now detect prefixed DOM features and give you a hook. E.g.: Modernizr.prefixed('requestAnimationFrame', window) // rAF function Bugfix for possible false negative when browser support for prefixed CSS Transforms is sunsetted. We now ship with a Function.prototype.bind polyfill included by default. You’re welcome! Modernizr 2.5 introduces some minor backwards-compatibility breaks due to changes in features and behavior. We no longer include Respond.js in the builder. If you still require Respond.js in your project, just include it manually. Modernizr._domPrefixes has been renamed to Modernizr._cssomPrefixes, and a new, lower-case Modernizr._domPrefixes has been introduced. We’ve removed KHTML prefix testing, due to lack of usage. We encourage all users to upgrade to Modernizr 2.5, as there should be no regressions. If you do happen to encounter issues, please file them on github. Thanks This great release would not have been possible were it not for the many contributions from people who volunteered bug reports, bug fixes and all new tests. We’ve made a dedicated page to thank everyone who contributed to Modernizr 2.5; this release has been the most collaborative effort yet for Modernizr, and we couldn’t be more excited about that. We’re similarly excited to announce the expansion of the team. Ryan Seddon has been made an official member at last, and we also welcome Alexander Farkas to the team. And speaking of Ryan, he’s done a great Learnable course on Modernizr, so if you’re relatively new to the library you should check it out! Elsewhere While not a Modernizr effort, we do want to bring some attention to a very useful new reasource, ideal for people who use Modernizr: HTML5 Please. Together with Can I Use…, these two sites should cover all your questions over which features are reliable and safe to use based on what audiences you need to support. We’d also like to note that our HTML5 Cross Browser Polyfills wiki is still growing, with many more polyfills having been added. Modernizr 2.5 is the best starting library for anyone taking advantage of the latest in HTML5 and related technologies, and we hope you’ll enjoy it. [Less]

Modernizr 2.0 came out more than eight months ago; we’ve not sat still in the period since, and today we’re proud to announce the release of Modernizr 2.5, our biggest update yet! New in 2.5 The list of new things in 2.5 is too big for Github ... [More] to handle, but here are the highlights: More than 60 new feature detects for emerging browser features; check out the full list or peruse all of the community-driven tests in our feature-detects folder. We now have a super robust and integrated test suite. Paul did a great video detailing how it works. Brand new embedded and included micro-libraries: html5shiv 3.2 and yepnope .js 1.5. Modernizr.prefixed() can now detect prefixed DOM features and give you a hook. E.g.: Modernizr.prefixed('requestAnimationFrame', window) // rAF function Bugfix for possible false negative when browser support for prefixed CSS Transforms is sunsetted. We now ship with a Function.prototype.bind polyfill included by default. You’re welcome! Modernizr 2.5 introduces some minor backwards-compatibility breaks due to changes in features and behavior. We no longer include Respond.js in the builder. If you still require Respond.js in your project, just include it manually. Modernizr._domPrefixes has been renamed to Modernizr._cssomPrefixes, and a new, lower-case Modernizr._domPrefixes has been introduced. We’ve removed KHTML prefix testing, due to lack of usage. We encourage all users to upgrade to Modernizr 2.5, as there should be no regressions. If you do happen to encounter issues, please file them on github. Thanks This great release would not have been possible were it not for the many contributions from people who volunteered bug reports, bug fixes and all new tests. We’ve made a dedicated page to thank everyone who contributed to Modernizr 2.5; this release has been the most collaborative effort yet for Modernizr, and we couldn’t be more excited about that. We’re similarly excited to announce the expansion of the team. Ryan Seddon has been made an official member at last, and we also welcome Alexander Farkas to the team. And speaking of Ryan, he’s done a great Learnable course on Modernizr, so if you’re relatively new to the library you should check it out! Elsewhere While not a Modernizr effort, we do want to bring some attention to a very useful new reasource, ideal for people who use Modernizr: HTML5 Please. Together with Can I Use…, these two sites should cover all your questions over which features are reliable and safe to use based on what audiences you need to support. We’d also like to note that our HTML5 Cross Browser Polyfills wiki is still growing, with many more polyfills having been added. Modernizr 2.5 is the best starting library for anyone taking advantage of the latest in HTML5 and related technologies, and we hope you’ll enjoy it. Update Feb 8: we’ve included another couple of small—but significant—updates, and have released Modernizr 2.5.2. Notably, this latest update includes html5shiv 3.3, which features an up to 16x performance increase over the shiv that was bundled in Modernizr 2.0. The html5shiv team (Jonathan Neal, John-David Dalton, and Modernizr team member Alexander Farkas) has been hard at work (view changelog) making this foundational piece of the HTML5 infrastructure fast and robust. (To be clear, this is the exact same shiv available in Remy Sharp's googlecode repos.) Plus, using Modernizr 2.5 (with the included html5shiv 3.x), you no longer need innerShiv; the fix is automatic. Additionally, our download builder now ships with Yepnope 1.5.2. We also want to highlight a few more changes from 2.5: We’ve toughened up canPlayType checks for Firefox 3.5.0, 3.5.1 and 4.0.0 - 4.0.4 In iOS5 Private Browsing mode you can use localStorage.getItem but it throws an exception for setItem. We test it out and set Modernizr.localStorage to false if we cannot store. We now have a <datalist> detect with no false positives! It’s accessible through Modernizr.input.list [#146] If you use the transitionEnd event, we’ve documented the correct IE10 and spec’d behavior. If you, by chance, have a class of oh-no-js-oh-my on the <html> element we wont remove it anymore as part of our no-js to js switch. The Modernizr wiki has been reorganized. Much cleaner! [Less]

Sometimes, members of the team get asked how we ascertain and verify that the features we detect are accurately detected. It’s not always a simple process, but over time we’ve put together a test suite that helps us out a lot. Paul has recorded a ... [More] screencast discussing how this test suite for Modernizr was built. The brief summary: initially built with QUnit, the test suite has coverage over the full API surface area of Modernizr, even using kangax’s detect-global script to assure no globals are introduced beyond Modernizr and yepnope. After that it gets interesting—as verifying the results from Modernizr’s detection of the current browser’s features isn’t straightforward. We end up using APIs from both Caniuse.com and Github, using projects like Lloyd Hilaiel’s JSONSelect, Lindsey Simon's ua-parser (ported to Node by @tobie), some ES5 polyfills, and some real sexy jQuery Deferred action to elegantly handle a bunch of $.getScript calls. 20 minutes of javascript and feature detection action below. [Less]

Sometimes, members of the team get asked how we ascertain and verify that the features we detect are accurately detected. It’s not always a simple process, but over time we’ve put together a test suite that helps us out a lot. Paul has recorded a ... [More] screencast discussing how this test suite for Modernizr was built. The brief summary: initially built with QUnit, the test suite has coverage over the full API surface area of Modernizr, even using kangax’s detect-global script to assure no globals are introduced beyond Modernizr and yepnope. After that it gets interesting—as verifying the results from Modernizr’s detection of the current browser’s features isn’t straightforward. We end up using APIs from both Caniuse.com and Github, using projects like Lloyd Hilaiel’s JSONSelect, Lindsey Simon's ua-parser (ported to Node by @tobie), some ES5 polyfills, and some real sexy jQuery Deferred action to elegantly handle a bunch of $.getScript calls. 20 minutes of javascript and feature detection action below. [Less]

One of the most common requests around Modernizr is for it to be made available on a Content Delivery Network. Back in the 1.x days this made a fair bit of sense: there was only one version of the library, and so the compressed version would be ... [More] useful to have on a CDN for performance reasons. With the advent of Modernizr 2, however we’ve (re)introduced modular builds of the library, which make the value of CDNs less self-evident. We now make you create a customized build of Modernizr—using only the tests you actually need—when you want a production-ready, minified & compressed version of the library. But with over 40 embedded tests, supporting all possible combinations of tests is impossible, aside of being downright undesirable. This has caused some confusion, so we’d like to explain the right way to use Modernizr under the various different scenarios that occur. Development, local: General development and/or learning When you start building a new project, or if you simply want to learn, you should download the latest development version of Modernizr. This is typically a stage where you don’t know yet which feature detection tests you’ll eventually need by the time you go to production, and don’t need to worry about minification. If you’re building your site or app locally, this is the version to use. Development + CDN: Test cases, one-offs, partial control-situations If you’re creating a quick test case using something like jsfiddle, or are writing an entry for a contest like 10K Apart, using a CDN can be not just useful, but downright necessary. If your situation relies on externally-hosted code, use one of the CDN releases. But be warned: these versions contain all 40+ tests! That means they are full-fledged libraries with almost certainly a lot of things you don’t need in a final product. That’s why the Microsoft CDN and CDNJS releases of Modernizr are essentially just Development versions, but hosted somewhere for you to use. Custom build: All production uses Are you priming your website or app for production? Then it’s time to head over to the custom download builder, tick all the tests your project makes use of, and hit that Generate button to make your own special build. All production uses of Modernizr should be using a latest custom build from the site. This ensures that you won’t run into any (old) bugs, and will have the absolute minimum amount of code and execution time needed for the best possible performance. As an added bonus, these custom builds now include a directly-usable Build link that allow you to make small tweaks—change a setting here or there—without having to figure out your requirements all over again. It’s also helpful whenever a new stable build is released: just revisit that Build link from your custom build’s source, hit Generate again and you have a new, updated stable build. Always be sure to test! We hope this simple guide helps you figure out when to use what version of Modernizr. [Less]

One of the most common requests around Modernizr is for it to be made available on a Content Delivery Network. Back in the 1.x days this made a fair bit of sense: there was only one version of the library, and so the compressed version would be ... [More] useful to have on a CDN for performance reasons. With the advent of Modernizr 2, however we’ve (re)introduced modular builds of the library, which make the value of CDNs less self-evident. We now make you create a customized build of Modernizr—using only the tests you actually need—when you want a production-ready, minified & compressed version of the library. But with over 40 embedded tests, supporting all possible combinations of tests is impossible, aside of being downright undesirable. This has caused some confusion, so we’d like to explain the right way to use Modernizr under the various different scenarios that occur. Development, local: General development and/or learning When you start building a new project, or if you simply want to learn, you should download the latest development version of Modernizr. This is typically a stage where you don’t know yet which feature detection tests you’ll eventually need by the time you go to production, and don’t need to worry about minification. If you’re building your site or app locally, this is the version to use. Development + CDN: Test cases, one-offs, partial control-situations If you’re creating a quick test case using something like jsfiddle, or are writing an entry for a contest like 10K Apart, using a CDN can be not just useful, but downright necessary. If your situation relies on externally-hosted code, use one of the CDN releases. But be warned: these versions contain all 40+ tests! That means they are big, full-fledged libraries with almost certainly a lot of things you don’t need in a final product. That’s why the Microsoft CDN and CDNJS releases of Modernizr are essentially just Development versions, but hosted somewhere for you to use. Custom build: All production uses Are you priming your website or app for production? Then it’s time to head over to the custom download builder, tick all the tests your project makes use of, and hit that Generate button to make your own special build. All production uses of Modernizr should be using a latest custom build from the site. This ensures that you won’t run into any (old) bugs, and will have the absolute minimum amount of code and execution time needed for the best possible performance. As an added bonus, these custom builds now include a directly-usable Build link that allow you to make small tweaks—change a setting here or there—without having to figure out your requirements all over again. It’s also helpful whenever a new stable build is released: just revisit that Build link from your custom build’s source, hit Generate again and you have a new, updated stable build. Always be sure to test! We hope this simple guide helps you figure out when to use what version of Modernizr. [Less]