 Thank you all for coming. Some lot of great sessions right now, and so I take it that you are going to get something out of this one, and I hope to answer any question that you may have over the course of the presentation. My name is Chad, I'm a front-end developer, sort of a user experience geek, working at RxWiki here in Austin, doing some noble work, reducing healthcare costs and creating the largest medication encyclopedia, peer, perpetual peer review. It's pretty cool, check it out. We use Modernizer for a couple tests, but personally I've used it on every project ever since I found out about it a few years ago. I always find something, even if it's just one thing that I need Modernizer for, like it's there. And so that has been... Can you speak out a little louder? Yeah, sure, let me just move closer. So yeah, when I saw that it got into Drupal 8, I was really happy because I was a big fan of Modernizer and I wanted to see what the reasoning was and what it was being used for, and also the fact that it was just greatly legitimized by that move. So to start off, okay, it's a little different, but I've been thinking a lot about Modernizer lately, preparing for this. And I started dreaming about it and I had this really vivid dream and I converted it into a little short story. And it sort of covers the philosophy behind Modernizer and it's science fiction and that's kind of cool. So if you don't mind, it's short. This name of the story is 100 Roving Robots. So in this imaginary world, there's a band of 100 Roving Robots and they show up at people's houses, willing and able to help with whatever you want them to do. There's a whole variety of them, there's new ones, there's old ones. So they'll do whatever you want them to do, but you have to speak their language, right? Only if you're capable of doing it, kind of like a web browser. So if you command a robot to do something and it can't do it, it errors out and it leaves. Web browser. So these robots require you to give them commands as soon as they show up. So you kind of have to have your command list ready for them as soon as they show up. So there's new and old robots, you want to take advantage of all the features of the new ones. So you spend your days studying up on all different types of robots, manufacturers, models, operating system, programs, versions. So you have this master list that's always growing, of every functioning robot and you have this intricate plan of what you want them to do. So it takes you a long time to create, maintain and update. Finally, today's your day. The robots show up. 100 of them, you have plans for them. Plans for them to tear down your house and rebuild a mansion in one day because that's something that robots can do. So you send them their command list, your command list. 75 robots, they just error out and take off. 24 robots tear down your house and carry off the rubble. So you didn't predict that the robots would be models, you didn't know existed. And that many of these robots were actually different than what they reported themselves to be. One robot is building something. By the end of the day, you have a little tiny room. So your neighbor passes by, it turns to you, he says. Forget the model number, manufacturer, OS, the programs, it's just a losing battle. There's too many different types of robot. There's new ones made all the time and some of them don't even tell you what they really are. So you say, how do I get them to do what I want? He says, will you prefix your commands with capability tests? Test for flying. If the robot can fly, use that robot to work on your roof. If it can't fly, test if it can move sideways. If it can move sideways, have it work on the walls. If it can't fly or move sideways, test if it can landscape and so on. Brilliant, you say. Then he gives you a list of capability tests that work, compiled by many of those who use this method. Thanks, I'll use it. So you wait in your tiny room for the robots to return, pull you ready to command every robot effectively and age passes. Finally, the robots return. You use the capability testing to command the robots to do your bidding. They build your mansion and it was beautiful. The end. There's an epilogue, but I'll save that for another time. So, let's move on. So it's not about who you are, it's what you're capable of. Names don't matter. And I was looking at this phrase and I was like, okay, wouldn't that solve a lot of problems in the world if this thing was understood as a philosophy, I guess? So it's deeper to me than just browser detection. But in this case, we apply it to the web world using Modernizer. So Modernizer is the feature detection library that detects what a browser can and cannot do and won't do anything on its own, but you can take those results and act on them. So Drupal Core, the Modernizer build in Drupal Core has like four tests and some functionality, but you can use like over a hundred tests, although I don't think that any site will ever need that, but you never know. So there's lots of fun stuff in HTML5 and CSS3. And browser support's weird and you shouldn't have to be able to or shouldn't have to be an expert at what browser does what. You just build the features that you want on browsers that support it and then come up with a fallback using Modernizer when they don't support it and then it just works. If the older browsers or, you know, browser gets updated and it has the capability, then it will just not use that fallback and it'll join the rest of the browsers with the latest features. So using this philosophy, you can sort of modernize yourself in your site without holding back because of all this varying browser support. And to me, kind of like has been a big deal deeper than just like, oh, this is cool because I don't like being held back in any way and Modernizer has allowed me to like, when I would perhaps previously get to that wall just be like, what do I do? Like Modernizer's that tool that really takes me through it and so it's been sort of missing for most of my life but it's here now and obviously it's important enough to get into Drupal 8 even if it's just a minimalist build. So Drupal 8 supports HTML5 so, you know, it made sense to go with Modernizer because that is what it is really good at. So in the past, not something that I really ever did but I know that it was common practice was to look at this user agent and that is rough business. It is a friend for life, prone to error, maintenance nightmare and just sort of ugly and annoying to deal with, definitely not beautiful. So don't like this, doesn't tell you much, you're gonna waste your time trying to extract that information from this. So enter Modernizer, test for SPG, if you support it, true, so simple. All right, so Modernizer didn't come from some void, well, a void for a need but it was created by people and the developers are amazing and they've made it free and open source and they have an awesome website, we can download these custom builds that are minified and it's awesome. So these names are directly off the Modernizer website and of course there's a lot more contributors in this and you can find that on GitHub and mad props to these people for moving the web forward. So there's a lot of talk, let's talk about how it actually works. So it's a tiny script that loads at the, I guess the top of the page, like before your other scripts and it creates a JavaScript object with your test results, whether it's true or false and all these tests, you can find them on GitHub, you can see how they work and everything and they're all super small and basically cover every browser. And so once that object is created that has true or false per test, it adds those classes to the HTML element so you can use CSS. So let's start at the beginning. So the source of your page put no JS because if you load your page without JavaScript, that will be there and it's similar to conditional classes which is popular for, with the older versions of Internet Explorer, you can put conditional HTML tags and then you get different classes up in the HTML based on which browser it is. But this is sort of takes that concept to another level. So when Modernizer runs, it replaces that no JS with JS because obviously Modernizer has run. So now you know that you have JavaScript and that's sort of like just the beginning. What I like to do is periodically work on a project, turn off JavaScript and then kind of see what's broken. And then in some cases using this no JS class can help you fix stuff for I guess the rare case when people don't have JavaScript working. So it's sort of the core concept but it goes a lot further. So this is what your HTML element looks like in Drupal 8. You can install a core Drupal 8 off of Drupal.org and you will see this once your page loads. And so it shows here that there was a touch test run, an SVG test and a HTML5 details element test. And I was on Chrome for Mac so it says no touch instead of touch. If it was a touch-enabled device, it would say touch. So with that you can change styles and also because that exists, that JavaScript object exists with which you can run different scripts and you can do conditional script loading and we'll talk about that later. So the Modernizer object in JavaScript just called Modernizer. On this page you could go to your console and type in Modernizer at touch and it'll give you false. And so from that object comes those CSS classes. So just with these, basically yes or no, true or false, you can do like a whole lot and you can combine them and it's not useful. And the reason that these ones in particular were chosen is because they were needed for a Drupal core. They needed feature testing and Modernizer already had it all figured out. They didn't have to roll their own special thing. It was out there. So I can show you some examples of how you can use these. They're not complicated in any way. They'll just sort of give you an idea the patterns that you can use. So in this case, the header by default has a fixed position but if you have touch, then it goes back to being static. Like that's simple. A lot of sites don't have the proper sort of responsive framework and then on a tablet or phone, any kind of fixed element gets all super wonky when you zoom in or out or anything like that and this would solve it right there. Like one test, do you have touch or not? You don't have it. You get the standard CSS positioning, which is static. And Drupal core uses that touch test, I believe for dragging fields up and down and weights and stuff like that. So the Drupal admin experience is touch capable and it uses this test to make it work properly on touch and without touch. Another popular use of Modernizer is for SVG. Most browsers support it, but some don't and you don't want it to break. And so in the Drupal 8 toolbar, it has really nice icons now and they're all SVGs and it has a fallback and it uses this pattern basically. They don't have to use the dot SVG before it. You can, but then I guess you run to an issue that if Modernizer doesn't run, then you wouldn't get anything. So you should probably just leave off the first SVG and just leave the no SVG. Basically, whatever your default is, you don't need that Modernizer prefix, but you want to use that on your fallbacks. So, and this is a good example of how Modernizer is kind of like a go-to guy because the original build for Drupal 8 didn't have this SVG test and then there was an issue about how do we get high DPI icons in the toolbar and then it was decided Modernizer would be the way to do it. So they just updated the build with the SVG test and up and running. So you can also use that JavaScript object to run a script based on it. So this is, you're not going to want to use this script on your site, but it's just an example of how you can use it. So if you have your SVG embedded, it's going to break on certain browsers. So then in that case, you just swap in the, swap in a PNG or whatever else. So they're better ones where it'll look through your images and see what has SVG at the end and replace it with the PNG or whatever else. So there's a lot of different ways to do this one. So yeah, don't use this. And then this details element is a really cool HTML5 element. Like we know all of our Drupal has always been those field sets that you can open and close and as part of HTML5, you can do it straight in HTML. Like no jQuery, JavaScript required, but well, weirdly enough like Firefox, I think doesn't have support and IE, but Opera WebKit do. So in this case, what you see here would just work. But then for the other browsers, then you'd save modernized details as false, then you have your fallback. And so then once those browsers do support this, they won't need that fallback, but it's a way to support HTML5 and then not break it on older browsers. Or browsers that just haven't, they're not up with it. So the question is how does it get into Drupal 8? Well, there are issue threads on Drupal that you can read through and they're great examples of how the community comes together and makes this kind of thing happen. They make wise decisions about the future and where things are headed. And so when I found that thread, the conversation was already over, but I had gone through it a few times and obviously it was an effort to get it in there, but then once it was realized that it was not a feature, but rather like essential for supporting older browsers and HTML5 features, it was decided that it would end up in Drupal 8. So there's only four tests and I guess four different, I don't know the word for it, but sort of like supporting functions. And we've kind of gone over the touch, SVG, the details element, and the input types is HTML has all these new input types like color and number and date and stuff. And same deal, you have to have a fallback for that. So they needed that in Drupal core. So there was the test ready for them with Modernizer. And of course, there's like over a hundred other ones. So then the utility function, some of them are requirements for those tests, like I believe test styles and prefixes are required for the touch events. And then the add CSS classes is required for Modernizer to inject those classes into the HTML tag. And so the only thing that was really not totally required that got into Drupal core was that add test, plug in API. What that lets you do is run your own tests that are just like the tests that you can get from Modernizer.com, but you can test for whatever you want. What's cool about Modernizer is that it's not like jQuery where I guess you could break certain things by installing new versions. And so the idea is that with Drupal core, we'll be able to keep upgrading Modernizer along with it because the part of it that you interface with, whether the object, true or false, or that CSS class with no before it or not, is the same. So you can do all sorts of backend stuff to make it better, figure out compatibility tables like from caniuse.com. So hopefully we'll see Modernizer 3.0 in Drupal 8. So when I've told a lot of people about Modernizer, they're like, feature detection, like that must be like super heavy, like are you sure, like that's a good idea. But like it's super tiny and basically negligible. It's like, when it's g-zipped, it's tiny. And it gets cached and just it runs in whatever I read microseconds, which I guess is a millionth of a second. So you usually don't have to worry about Modernizer causing any performance issues. It's fast. I was on the Wells Fargo website and I was looking at their source and they had the fully uncompressed version of Modernizer with like, you know, 50 different tests or something like that. And like, I couldn't tell the difference, but obviously it was slowing something down. They have since changed that, but I think it was funny. A lot of sites you can just open up your inspector, look at the HTML tag and then if you see, there's like telltale signs that is Modernizer. You'll see touch a lot, SVG. And then there's a bunch of ones that aren't part of like the core tests, but are used to decent effect. So this is how you add a test. This is if you didn't wanna replace the Modernizer library, you could add a test to it. I guess, you know, if you have Drupal 8 and you don't wanna add an extra weight of the module or I don't know, but you can use this and you can do a test. For example, this is for jQuery course. It's a cross origin resource sharing. You can do Ajax calls onto different servers. And the way it works is, let's see if I can do this right here. All right. So this right here is the name of the test. So that's what comes back. SC in the bottom there, Modernizer.core is true. And then it puts in an HTML tag. And then basically this would have to be true. And this would have to be true. And if they're both true, then the test comes back as true. And you can work with it from there. And so I just got this from the GitHub repository. There's tons of different tests there. And usually you wanna add something like this to your Modernizer build, but you know, you have the ability anywhere in your document to add a test like this or intermodular theme or whatever. All right. So you're definitely gonna want to augment the functionality of Modernizer in Drupal 8 and in Drupal 7 too. Drupal 8 is such a minimalist build. You can really just do a little bit with it. But if you are going to use it to its full potential, you need to download the uncompressed library and then work with it. And then once you know what you need to use, then you can customize it and minify it just like we did for Drupal 8. So let's see. All right, number one, modernizer.com is again an awesome website. There's documentation, there is this downloader tool, there's resources, there's news. So right here, you can see this is, I clicked the link for the development uncompressed version. So basically everything is checked off. I see that the media queries one is not checked by default. That's a good one to use. And so this is sort of usually where you begin. And right now, if you're working with Drupal 7, that's where you start. And in Drupal 8, once there's a module ready, you're gonna want to do that too. So today, there's amazing integration with Drupal 7 and Modernizer. So, but it's good to know because it's gonna persist into Drupal 8. So in Drupal 7, that HTML5 shiv is required basically for IE8 and below to understand HTML5 elements. But in Drupal 8, it's included by default. So you're not gonna need that in Drupal 8, but Drupal 7, yeah, probably. So when you download this one, you'll be able to see, I don't know how visible it is, in that gray box there is the file. And at the top of it is always gonna be a link with your entire build. So actually if I go back one and look up at the top, you can see up in the URL, there is a long list of tests. And so in every minified Modernizer file, you have the entire list of tests that are included in it. All right, so we're still on Drupal 7 here and the Modernizer module is a must have. Yes, you can just include the Modernizer library manually, but this module will put it in the right place and it'll give you integration with other modules and hooks for modules and themes to utilize it. So that's one of the modules I use on, put in by default whenever I start a new Drupal site, this is always gonna come in handy. So what's really cool about it is that it just uses all the Drupal-y things, like being able to declare tests in your theme info file is really awesome. And then in PHP in your modules, you can use a hook to run tests also and it'll convert that code into a JavaScript that does all the Modernizer magic. So this will be available for Drupal 8, I'm sure of it, and I'm going to try to work on my PHP chops a little bit, see if I can contribute, but it's great. Okay, you have Modernizer, you have the module, now you have the tools. Yeah, now you can build a site using feature detection and generally it's for polyfills, fallbacks and enhanced user experience. I've gone a little Modernizer overboard at certain times and I just try to use it for everything and then I realized that maybe it wasn't the best use for something and that there's sometimes natural fallbacks or that it can get too convoluted from using too many different tests. So it's a tool and sort of once you use it a bit and understand it, you'll come across a problem and it's like, oh okay, Modernizer is the solution for this and it's going to save me a lot of time. So the one thing that is not part of Drupal 8.4 and really like, I don't know, nerfs the whole library is not having Modernizer load. I understand why it didn't get in there but this is like the essential piece to Modernizer that you just have to use it because it's Modernizer superpower. So what Modernizer load lets you do is conditional resource loading based on test results, asynchronous so it doesn't block anything super fast and it's really easy to understand and your site's gonna be faster if you use this sort of thing in the right situations. So this is just an example of a polyfill using Modernizer load, it's a situation where it's this example that's used all the time but the geolocation you always have to use a polyfill in some way. So this test is basically testing to see if geolocation's true. On HTML5 browser it would be and if it's not, then it loads this polyfill and to your app or whatever it is, it doesn't have to know about that polyfill, it's kind of separate from it. And so your app does what it does and then on the browser side, if it doesn't support your location, you have this polyfill and then your app just works. So that's really popular use of Modernizer load and it doesn't just have to be nope, you can also have yep and yeah, it really is a yep and nope. In this and they released that separate from Modernizer, it's just called yepnope.js and it's awesome. In this case, this is more of like a user experience enhancement using it. So there's a tiny bit of code, basically test to see if Modernizer touch is true and if so, loads a couple of JS files and then when it's complete, runs a function. So it can load at any point basically and the people who don't have touch never have to load those or deal with that sort of thing. So the sort of concept of doing a test and then from there, loading JS or even CSS, you can load a CSS file and add styles to a page or background images or whatever you want. So you can get creative with this on user interface and it's fun. So yeah, I mean, getting creative, you can take it pretty far. You can say, if you have touch, small screen width, I'm gonna give you a big button, whatever you want, but it's tempting to use it all the time. I'm guilty of that. So in this case, fallbacks can be a creative exercise. They don't just have to be let's make a fallback. Like you can have fun with it. So I don't know, if you think like 8-bit or something like that, you can create a good game today on like an 8-bit type of console. So yes, this is very pink and I have an example here. It's used a lot because there's no good way to test for a box shadow, basically. So let's say some designer comes up with this design. Let's say maybe it's white or gray where the modal window is the same color as the background and they want a drop shadow or something. So it's not gonna work on a browser without box shadow. So what do you do? Come up with a fallback that has a bit of creativity to it. I know it looks better than the drop shadow, but for demonstration purposes, someone on IE8 is gonna see that white border. And you know what, drop shadows and rounded corners and stuff can be really tiresome. So maybe they never updated from IE8 because they don't like to see drop shadows and rounded corners. And so you're giving them what they want. Nice corners of a box. So the way this will work is pretty simple. If it's IE8, you're gonna get that no box shadow class up in the HTML element. And then your default CSS is to have that box shadow. And then if you don't have box shadow, you get the border. Everyone's happy. You don't have to worry about which browser support what. You just know that if there's some browser out there that doesn't have it, they're gonna get your fallback. So there is a lot of information out there about Modernizer, modernizer.com. Chris Ruppel did a really good presentation at Portland and I've used that slide deck a bunch of times for reference. You can also just, you know, Google search Modernizer and you'll find all this stuff. So I hope that I was able to get the core concepts across about Modernizer and how to use it. And I'm happy to answer any questions that you may have. So if you need something more for Drupal 8, like more than just the basic tests that are enabled, like you shed box shadow right there, what's kind of the practice for, I mean, do you disable the Drupal 8 version of the script and then put your own in or what's kind of the approach there? As I understand it, that'll be the way in Drupal 8, when you install the module, you'll be able to override the core Modernizer with whatever build of Modernizer you want. Thanks. Do you know of like a resource where you can see which browsers have which features and based on Modernizer stuff? Oh yes, caniuse.com. That is the place, totally updated. It shows you a few versions ahead, what's planned. So you can plan for the future. It'll show you like as far back as you really want. And there's going to be a level of integration between that and Modernizer 3.0 when it comes out, as I understand it. So yeah, caniuse, go to place, can't go wrong with it. Anyone else? You can just shout. Yes. One of the options for when you download Modernizer is to include the HTML5 sheave. And so my question is, do you recommend doing that or adding the HTML5 sheave separately on the script? In my experience, Modernizer does a really good job of handling that. And so since I put Modernizer on every site, I just include that sheave and it does its thing. I don't know entirely the reason why it was separate in Drupal 8, I'm sure it's some very good reason, but I just use Modernizer for that sheave all the time. Thanks. All right, I guess that wraps it up. Thank you all for coming. One quick one for you. Sure. As you said, that will be replacing the Drupal 8's Modernizer with our own. Is there a list so that we don't disable something that Drupal 8 should have, that we're gonna not include in ours sort of thing? I don't have the answer to that and I've wondered the same thing myself. You're about to find out how that works. Hi, I'm the guy that wrote the Modernizer module and there's a Drupal dependency, like there's a Drupal API for it, so when you, gee, too short, when you go to the admin configuration page, what it does is it actually asks all the modules and themes in the system, like what they want. And so it's just a hook, you do Modernizer Info, like my module, Modernizer Info, and it says, oh, I need Box Shadow, I need Geo Location or something like that. If you look at the Geo Location field module, it actually has the Modernizer hook implemented so you can get a good idea for how it works. So then what happens is that URL that Chad mentioned that takes you to the Modernizer page, it basically uses all those little slugs and auto-generates a URL for you to go there and grab your new build, and the ones that are in Core will be accounted for automatically in the Contrib module, they'll just be hard-coded in so that the Core ones can't be removed unless you go and do it yourself, which is possible. So you could break it on purpose, but it won't break by default. And also we're working on some like Drush commands and stuff like that to auto-generate all this stuff for you on the command line and just put it in the right place, so that's the quick version. Awesome. Yeah, so you don't go to Modernizer.com directly, you go to the Modernizer module in your Drupal admin interface and then not only will the Core items be requested by default, but whatever other modules are requesting certain tests and it'll take you to Modernizer, you can then add whatever you want and that sounds like a great solution. I can't wait to use that. Any more questions? So everyone knows how to use Modernizer now, right? All right, getting good. Thank you.