Luckily for you, Ryan Seddon will be joining us here on the forums to answer your questions. Come along and join us on October 15 at 2pm (PDT).
Ryan is a Modernizr contributor and he has a deep knowledge of its inner workings. He’s even made a Modernizr 3 course on SitePoint Premium! When Ryan isn’t busy making courses and working on Modernizr, he’s also presenting talks at various events and writing for some really great blogs, his blog included. Ryan is an active tweeter and contributor to open source software, so be sure to follow his work.
We’re sure you’ll have many questions for Ryan but if you don’t know whether you can join the chat, feel free to jump the queue and leave your questions here ahead of the event. You’ll have to log into your SitePoint forums account to be a part of the written discussion - these are not the same as the your SitePoint Premium account. Alternatively, leave your questions on Twitter using #RyanChatsModernizr.
When is this happening in your timezone? This link should help. Now that you have that in your schedule, type up your questions below. Ryan will be writing his responses during the event.
Need some help with the SitePoint forums? No problem, here’s an FAQ about our Q&A’s.
I believe I’ll be in attendance, but just in case I’m not able to be free due to some upcoming life events…
Ryan - first, thanks for doing the Q&A here on SPF
Question 1 - What do you view as the single most important new feature in Modernizr 3 that sets it apart from previous versions? Is it the ability to very easily build your own custom Modernizr file, or is it something else?
Question 2 - Where do you see Modernizr going in the near future? What’s the end goal for development? To continue improving, fixing bugs, adding detects, etc? Or do you have more sweeping goals on the roadmap?
HUGE Thanks for sharing your knowledge with all of us.
Compound Question: One of the ways to use Modernizr is to target legacy browsers, IE specifically, based on their lack of support for specific features in certain technologies, CSS being one of them.
Part 1: What are your thoughts about using Modernizr vs. Conditional Comments in the <html> (Paul Irish’s method) to address CSS issues?
Part 2: Is it worth the additional request if one’s strategy is addressing CSS issues in legacy IE’s?
I’m still doing your Modernizr 3 course, but I would like to know what’s the real impact in web performance of using that javascript library.
I mean, I think it adds an HttpRequest and a collection of tests that the browser must execute.
Is it worth to use it thinking about performance?
I’m not trying to be critic and I appreciate much your work.
Today we have Ryan Seddon joining us on the forums to answer your questions on Modernizr 3! Please feel free to login to your SitePoint forum account, and type up your questions. Ryan is here and ready to go!
What do you view as the single most important new feature in Modernizr 3 that sets it apart from previous versions? Is it the ability to very easily build your own custom Modernizr file, or is it something else?
The biggest and probably the most controversial was there was no core detects file, neither do we intend to ship a prebuilt file. We really want to push the custom build route as including all the tests is incredibly detrimental to performance. For example some of the video and audio feature tests actually include base64 video files (very small ones) which is an unnecessary load on the client if you don’t need to test for those features, another big one is the webgl test which in some browsers can slow down your initial page load by 250ms as it creates a 3d canvas context.
Where do you see Modernizr going in the near future? What’s the end goal for development? To continue improving, fixing bugs, adding detects, etc? Or do you have more sweeping goals on the roadmap?
Our goal is to be a useful library in a front-end developers tool belt, and continue to offer the best and most consistent feature detects. As for the immediate future we’ll be trying to keep releasing often to fix bugs, add new detects. We don’t have a master plan or some super road map.
There is an interesting shift in new features being only available over https e.g. push notifications which are controlled through service workers, so you could only infer support through the existence of the serviceWorker property on the navigator object. There is even talk of removing support for exiting browser apis like geoloaction, getUserMedia etc in non secure websites so only over https. This could create potential challenges for Modernizr in being able to detect support for very new advanced features, so there’s some interesting challenges ahead for Modenrizr!
I’m a team lead at Zendesk by day here in Melbourne Australia and I’m one of the core members on the Modernizr team and have been busily working on Modernizr 3. I have a great passion for front-end dev and digging into performance.
What are your thoughts about using Modernizr vs. Conditional Comments in the (Paul Irish’s method) to address CSS issues?
Conditional comments are incredibly useful for targeting specific IE versions and to do certain styles to get around the well documented bugs in IE. Modernizr can work well in conjunction with conditional comments for changing your UI based on what it supports I don’t think it’s really ever a Modernizr vs. Conditional Comments scenario.
Is it worth the additional request if one’s strategy is addressing CSS issues in legacy IE’s?
Depends on your companies approach to progressive enhancement, making oldIE being able to function and complete core actions e.g. if you’re an e-commernce website they should be able to add items to the cart an complete a purchase. But trying to make oldIE look and function like a much better browser like Edge or Chrome is a big sink in developers time. People using oldIE day to day are probably used to sites looking terrible, that’s their baseline, if you’ve ever tried to visit modern websites on oldIE it’s a pretty terrible experience.
Also it comes down to getting stats about your own traffic and making calls on catering for these older browsers, is 5% of your traffic worth %25 of your dev time?
I’m still doing your Modernizr 3 course, but I would like to know what’s the real impact in web performance of using that javascript library.I mean, I think it adds an HttpRequest and a collection of tests that the browser must execute.
Is it worth to use it thinking about performance?
One of the reasons we removed the concept of "core detects” in Modernizr 3 was for performance if people included these and didn’t need them it adds an unnecessary execution time, we’ve been discussing various performance changes and how we might improve performance of the checks that Modernizr does see issue #878 and #1224.
Depending on the size of your custom build if it’s small, a couple kbs, then you could inline the script and avoid the extra http request.
One of my detection needs is .js vs .no-js, but also for whether cookies are enabled. Is there a quick pointer you can give?
We have a detect for that! If you go to the download page you can search for cookie and add that to your custom build. Then in the CSS classes it will either add cookies or no-cookies. You can also use the JavaScript Modernizr global to check in your code so doing if(Modernizr.cookies) { }
Just wondering how widely this library is used? Looks like almost everybody should.
There’s actually a really great website that tracks statistics like this for popular javascript libraries. Check it out here http://trends.builtwith.com/javascript/Modernizr from their stats Modernizr is used in roughly 33% of the top 10k websites!
I used Modernizr 2 on previous projects and really enjoyed it’s clean and simple API. I’ve found that some feature detection is easy enough to do with a simple if condition such as if (navigator.geolocation) {…}. Out of curiosity, which 1 or 2 browser features would you say are the most difficult to check for? In a similar vein, which browser features would you say are the most commonly checked for?
@Ryan_Seddon In my meagre attempts to learn JS, one thing that was drilled in was to feature detect, rather than assume a browser had a certain feature. It seemed this wasn’t only so that you knew if a feature would work or not. It was also to ensure the browser wouldn’t choke on a script it didn’t understand. Is that also one of the rationales for Modernizr?
