 Okay, those technicians are gone. All right, well, thanks for coming to the session. I hope everyone's enjoying DrupalCon Portland so far. Can everyone hear me? That's normally never a problem. So the session's called Meet the Modernizer Module. Awesome. And who am I? I am Chris Ruppel. I'm a front-end developer at Four Kitchens. We are one of your lovely sponsors for DrupalCon. So thanks to my fabulous employer for putting up some dough, paying for those games in the middle of the trade show floor. And stop by our booth and say hi. We've got a photo booth with like mustaches on it. It's pretty cool. Anyway, enough about that. Why should you pay attention to what I'm about to say? That's always a good thing to answer right up front. I do a lot of open source stuff. I am the maintainer of the Modernizer Drupal Module. I'm a co-maintainer. I didn't start it. I contribute to Modernizer the library itself. I am the creator and maintainer of Respond.js, but don't use it. I've worked with some D8 stuff and I've also helped with the D.O.T.O. infrastructure so I get around. I love Drupal and obviously you do too. That's why you're here. So before we start talking about web development, I wanna talk about a different type of media that has had all the same problems that we're going to have except ours are gonna be way worse. In the future they already are pretty bad. So let's talk about TV a little bit. When you have a TV channel, you want to, and when we have websites, we want to remember that we want to strive to deliver the best experience possible everywhere. That does not mean deliver the same experience everywhere. What it means is deliver the best experience everywhere. So all browsers are different. Browsers are even version to version. They're not the same. A lot of times I tell people that like just like two people with the same name, two browsers with the same name are going to have very different characteristics. There could be another guy named Chris or a girl who goes by Chris and I'm gonna be very different from the next person and so are you when someone has your name. And so all browsers are different. And so we kinda deal with this, right? Even the same version of Chrome is gonna be different whether you're loading it on a smartphone versus a desktop machine. So we've got a very fragmented landscape here but TV's kind of the same deal because TVs have lots of manufacturers. There are different shapes of TVs. There are different color capabilities on TVs and resolutions and so forth. And I've got a couple links here. These slides, the wifi was killing me. I couldn't push the slides but I'll get them up there today, I promise. There's a couple links in here. Pretty much all of the stuff that I'm telling you is has prior art. This is not my material but I'm kind of standing on the shoulders of giants here and delivering a message that I've heard at JavaScript conferences and stuff like that. So there's all the material that I'm kind of condensing down for you in three links. And the idea here is that just like TVs we are going to deliver tiered adaptive front end experiences. That's what your website should be. It should be kind of, you know, it should change its shape and you can remember this because tiered adaptive front end experiences, the acronym is TAFFI, all right? So that's what your website should be like. And the idea is that we're going to customize the experience to the capabilities of each web browser. And like I said, not a consistent experience but a fast, reliable experience is more important than consistency. So just to take another comparison or take another look at TVs when we look at like really old TVs, they've got black and white, they're lower definition and all of that. That's just like an old web browser, right? And then we've got new TVs. New TVs are very large, crisp. They've got more colors, they've got more pixels. They have internet connectivity. They can literally do lots of things other than just TV picture making. And those are our new browsers, right? They can do all sorts of stuff that when the invention of the TV, AKA web browser, you know, all those, they weren't, they didn't even know that we were going to be able to do this stuff when they made a web browser at first, which is awesome, technology is great. And so then this awesome save by the bell is, that's your content, that's your website content, right? And it's going to show up on all these different channels or channels is a bad word, but I meant that in like the marketing sense. It's going to show up on all these different devices, right, one channel, a TV channel. And you've got to make the picture look consistent or you've got to make it look good on each one of those things and it's not going to be consistent. So we've got a picture of three TVs here and kind of just take a look at each one. On the left, you've got a black and white TV showing a black and white picture. In the middle, you've got a color standard def TV showing a color standard def picture. And then finally an HDTV showing a crisp, beautiful HDTV image. So TV already solved this problem. They did it with standards just like we do on the web. However, when we talk about building websites, we do it this way a lot of the time. All three of them are black and white and standard def and the content is limited by the lowest common denominator and that's no good, right? This would be silly if you saw it on TV and yet this is what we do a lot of the times because whoever, like your client says, well this has got to work on IE, stupid. And you're like, okay, all right. So you said you wanted a responsive site and I guess we just won't give you one if you want X or Y or you want this feature. So I'm gonna go back to this picture here for a second and who here has heard of graceful degradation everyone has and then progressive enhancement. And everyone's like, oh, that's the same thing, right? That's what we're all told. So the only difference here is that when you're gracefully degrading, you're building that HDTV content first and then you're stripping stuff off of it backwards as capabilities fall off. Now you can see in this black and white TV that those flowers aren't very visible because the image was a color image originally and so losing that color information makes it very difficult to see on black and white. Whereas if you started with a really high contrast image and then added color or something to it then you would have the concept of progressive enhancement because all the information, all the vital information is present in the simplest format and that is the crux of mobile first. Even though we always say mobile first, we really just mean simple first, basic first, lowest technology first. It should be there no matter what and if you're putting content on the web and you think it's important then it's probably important to everyone, not just the rich people with smartphones. So that's kind of what we're going for here as we go through the rest of this. All of the little code snippets and all the examples I'm gonna give are ways of ensuring that your experience is really fast and reliable but also very rich and interactive when the browser can handle it and when it's appropriate and when it's easy to do without making the whole website slower. So what I'm gonna basically show you is approaches that you can use to attempt to solve problems with device diversity, fragmentation in between versions of browsers, fragmentation in between browsers running on two different devices, backward compatibility, and future friendliness. All wonderful words that we've probably heard before. So how can we solve this stuff? Our go-to in the past was user agent sniffing, right? And everyone's done it, it's no big deal. Did it for years. And you'd say, okay, the iPhone's the new thing, it's really easy to make a mobile site for so I'm gonna make a mobile site for the iPhone. So I'm gonna grab that user agent string and I'm gonna find the word iPhone and I'm gonna serve up an iPhone page. Also, except not because iPads have the word iPhone in them. I could make my user agent string say iPhone even though I'm running Firefox or something like that. Opera for a long time didn't bump up its version number because when it went from nine to 10, things that, pieces of code that were reading opera version strings would find opera space one and not read the zero after it and say your browser's too old even though it's the newest version of opera. So opera, the user agent string, I think is still at 9.81 or something like that even though they're on opera 12. So user agent string is an outright lie and it is a bad practice. The solution that I find more appealing is to detect individual features in each browser using JavaScript. So this does a couple things right off the bat. Number one, if you can't run JavaScript you're gonna fail these tests but if you've built the content to withstand failing every test, well it's still going to be perfectly fine. So you can still ship a website and be sure that your content is getting to everyone regardless of the capability of the browser. Now when the other really strong advantage to this is when tests are actually passing and you've got JavaScript, well you can do really cool things because what you've done is you've moved the decision making from a server to the web browser and so instead of having one server making decisions for all of the devices that are accessing it, you can push that decision making down into the layer where it actually matters. So all the web browsers are making decisions about formatting their own content. It's a novel concept. And don't fear if you're averse to writing a bunch of feature tests as I am sometimes. There is a library that does this for you and it's called Modernizer. Ta-da! You can go get it at Modernizer.com. Before we talk about what Modernizer actually does, I want to kind of still talk about a little bit of why we use feature testing and when it's appropriate and all that kind of stuff because this is pretty important. When should you use a test? There's a website called Can I Use which is linked here. You can find it by typing Can I Use into the web browser and you'll find it and it stays current on browser feature support and it's pretty awesome. In fact, let's see. I'll try my luck with the wifi. Awesome. So we've got all these tests here and I can just search for like inline SVG. There we go. So this is a compatibility matrix that says how reliably you can use inline SVG and then it's got a little, that's kind of hard to see but I can zoom in. It's got a current near future and further future and so you can look at this stuff and say oh, for the feature that I want, actually inline SVG is a really safe option here in this case and then global, it gives you a global stat count so 81% of the browsers that are picked up by Can I Use can manage to use inline SVG which is pretty cool. There's gonna be other stuff that is different. Like okay, geo location is 84% that's even better. Filters maybe. Yeah. But anyway, you can go through here and if you look at the full list, we're gonna go to the index. We're gonna go to, you got a lot of features here that you can test. So you can go here and you can kind of decide whether or not something is worth testing for because you might not need to test for it sometimes. And you can also go to HTML5 Please which is another site. It takes Can I Use data which is pretty awesome. So these are all API-ified. It takes Can I Use data and it says, basically it attaches a label to the percentage. And so like right now box reflection has poor support so it says void. And then it says border image used with fallback. They say use with fallback. We're just use unconditionally. So it's a nice little way to get a pulse on how the web is supporting a lot of these features. So those are a couple sites that you can use for reference. And you might find yourself in a situation where you don't need to use Modernizer for a lot of stuff. Border radius there just said use. It didn't say use with caution. It didn't say use with anything. And that's because border radius has a natural fallback setting which is zero pixels. So that's pretty cool. You're not actually like losing information by not supporting border radius. And then gradients also. CSS has this built in where you can say my color is this, my gradient is this. And if it doesn't understand the gradient then it shows the background color. Awesome. However, there are sometimes apps where you really need a feature, right? A location based app isn't gonna work unless you know where you are in the world. So you're gonna want to test for geolocation if you have a location based app and serve up some JavaScript that will provide that functionality if a native API isn't present in a web browser. And also like I mentioned inline SVG is pretty awesome and it's supported most everywhere but still that's a nice to have technically. And so you can inline things in addition to supplying fallbacks for it. And there's no download penalty in this case. So it's a pretty good thing to build into your system. If you want a nice resolution independent graphics for logos and other things like that. But by and large I mostly don't use a modernizer if I can manage to order the CSS such that a fallback will naturally be present. So like I said, border radius doesn't explicitly fall back to zero but if it's not supported then the corners will just be sharp. And gradients are the same. If you're using a fancy tool like Compass it takes care of all this for you by ordering things in the proper order and so you don't need to hide your background gradient behind a feature test that is in the smallest sense of the word bloating your code base. So what should we test? Or when should you test? Like I said, if you have a location based app and this is mission critical information you should test for it. If you need CSS transitions and you're providing vital UI movement and sugar you should test for them. And maybe fall back to like jQuery animation or something like that. If you need HTML5 audio or video, test for them. If this might not be vital if it's just like one little thing on your site but if you're running a site that shows lots of videos and you want to put the video tag in there and you still want people to support it if they don't have a new browser then you need to test for that. Inline SVG, web sockets, data URIs, all this stuff. Are you noticing a pattern here? Test for everything. If it's vital and it's gonna break your UI if it's not present then it's good to test for it because when you test for it like I said you can either enhance the UI or create a fallback behavior for it. So how do I enhance the UI or provide a fallback Chris? Conditional loading. As you might guess, conditional loading is, the ability to like load things based on tests. So we're talking about testing things and now we can load things based on tests. Conditional loading comes in three major flavors. You can test like a property of the browser. You can test a built-in like native API. A property would be like a JavaScript variable or something like that. The features are what we were just talking about like actual feature detection tests. And you can also test user actions or preferences. So if a user, you know if you like do a little data collection on your site and you're noticing that your first three nav items are not clicked that often but the fourth and fifth one are then you can like kind of store this information or I'm sorry if the user is doing that often if they're like using lower pieces of nav or more often in their mobile UI you can kind of like collect that data in the background and then later on in a page load you can like reshuffle your nav or reshuffle tags or something like that. So it's not just about using like new cool feature, new cool browser features but also kind of like using data to predict user actions as well. So all this stuff can be done in JavaScript if you really want to. And making these decisions in the browser is basically the core mechanism for tiered experiences. So like I said, when you're doing user agent sniffing you're making a guess on the server. You're like just making a guess and you're hoping that you're right. And what really sparked my interest in this topic here was when I started working at Four Kitchens which was just a couple years back and before that I'd never worked on any like high performance Drupal sites and I got there and I said that I want to do mobile stuff and I'm a front end developer guys so let me have at it. And they were like sure all of our sites are behind Varnish. How do you deal with that in mobile? And I was like oh I don't know. Because if you're not familiar with Varnish what it is it's like a static site generator that sits in front of Drupal. And so when a page loads it gets cached and so if you've checked the user agent and you've like made it a mobile theme if you've sent a mobile theme down the line and Varnish has cached that then your desktop users are gonna get that mobile theme as well. And so I was like this is an interesting development. What can I do about this guys? And so I immediately this was like late 2010 and I immediately started looking into responsive web design which ended up being a thing. And responsive web design is the concept of driving these decisions down the line to the web browser. So we talk about media queries and all that kind of stuff. CSS is just being executed and applied conditionally to each device. And that's what responsive web design is. So we can take that thinking that we've all gained and we've all gotten accustomed to in terms of media queries and layouts and CSS that kind of stuff and just apply that to everything on the web. Cause that's what needs to happen in order to kind of provide these rich experiences while also not hurting other ones when people don't have as fancy technology for us. So how do we use modernizer load? This is basically the anatomy of modernizer load. I wish I had a laser. Oh, it's not bright enough. All right. So modernizer load here is pretty simple. It starts with the modernizer object and then dot load is a function here. And it takes a test object in between these braces. And the test object is made up of a couple things. One is the test itself, which is a modernizer.gl location in this example. And basically modernizer takes all of its tests and stuffs them into this big object of Booleans. And so any tests that you add to modernizer will say either true or false when you execute it. Modernizer.com and see this in action. So I am going to do two things here. First, I'm gonna show you that when this web page was built, we'll zoom in, that says class noJS, that's no-JS. And that's it in terms of what classes were put in the source code. Now when I pop open my web inspector here and I bump up the font size a little bit, you're gonna see that there are tons of classes in the HTML tag now. And a lot of them start with WF and that means web font, but the other ones say a bunch of features, right? And so it's put all the tests into basically the HTML tag which allows us to kind of like give it them in a convenient place, right? And you'll notice that it says no touch here because my laptop is not a touch device. And that's what happens when you fail a test is it just puts no-dash in front of it. The no-JS at the beginning was just like a global one because if you can't execute JavaScript at all, you will never be able to change that class and thus you can make no-JS styles as well. So back to the modernizer load command. That's a modernizer test. Oh, yeah, actually hold on. Sorry, everyone. Now I'm gonna go to the console and show you the modernizer object. What I'm doing is typing modernizer. This is a global window variable, all right? And it says object here, so I know that it actually loaded. And ignore all that crap. And then you look at here and you can see the results of all the modernizer tests that fired when the page loaded. So there's just a bunch of true and false there. It's pretty cool because that little object is the way that you manage all this stuff. So then you can make decisions in your code. Bam, back to modernizer load. So based on the outcome of modernizer.gl location, it'll say either true or false. And then you can put a couple options in there. In this example, if it's false, which is nope, then it will load this particular file that I've specified here. So assuming that the browser can't handle geolocation while then it's gonna load up geo.js. And then there's like a little callback function which allows you to initialize the function. This isn't a real library, I just kind of made up the code example for brevity. So that is a conditional load based on the absence of a feature. Let's talk about, or I'm sorry. Yeah, that's when you're loading something when the feature is absent and you want to load something extra. It can be used the other way around too. You can load stuff only when it's needed. So this is the progressive enhancement side of things rather than avoiding graceful degradation, which is what we were just looking at there. This is a very similar test. So it checks the, modernizer has a media query evaluator built into it. And so MQ is that evaluator and what it says is hey, modernizer, how wide is the window? And if it's at least 42 M wide, I want to load up an Excel CSS. And Excel CSS has a bunch of big background images in it that aren't being loaded unless you have a big screen that can handle it. And I will just go ahead right now and point out that you can do this particular example can be done in CSS only. It can now, it couldn't like a year ago, very reliably, but this particular example you don't need to modernize it for, but this is like a very basic example that kind of gets the point across. And I like to refer to this as the idea of one less JPEG. So, you know, you can manage to like, I've got a blog post here that describes this. If you Google one less JPEG, I'm sure you'll find it. And I basically added one line of code to a website and I sliced the website's size in half, which is pretty cool, right? Because then it loads faster and people are a little more happy with the experience and so forth. Here, actually, I can show you this in action. This is pressflow.org, you may have heard of it. It's got this big old mountain in the background because pressflow scales and your Drupal site will scale and scale ability, all right? And then what happens is though, when I shrink this down, that mountain is a little off to the, the mountain's kind of sad and small. And so on page load, I'm gonna reload here. Modernizer checks to see if the window's big enough, right? And if it's not, which it's not anymore, it doesn't load that mountain. Bam, even on conference Wi-Fi, that was fast. All right, so that's the idea. And I've got some like data network graphs and stuff in the blog posts, which I won't go over right now. But the idea is that you can do this very simply and you can make very small changes that affect your website in a large way, which is great because then like I said, faster, more reliable UX on your website. Because people actually prefer fast UIs over pretty ones, even if they don't realize that they do. So, this talk is called the Modernizer Module. What about the module, dude? How does the module help me build tiered experiences? I'm glad I asked. Drupal APIs, there's not enough of those are there. So, there are two APIs in the Modernizer Module. There's a test API, and what it does is it allows modules and themes to say, I'm gonna need this particular feature test. And there's a load API. And this allows modules and themes to load things based on tests that they requested, right? Pretty cool. Because not everyone is a JavaScript developer, not everyone is even gonna touch the theme and they're not familiar with that kind of stuff. And so I wanted to have a way to allow people to use this type of technology without being hardcore about their front end development. So, you can do this from like theme info files and you can do it from a Drupal hook if that's what you prefer. It's pretty rad. So, let's talk about the test API first. Modules can use a hook. It's very, very simple. This is pretty much all the code you need to tell the Modernizer Module that you're going to need a particular feature test, in this case Geolocation. Everybody likes Geolocation. And then themes can use the info file. It's very simple syntax. You say Modernizer, Tests. And then you say which test you need. And it is an array, so you need to put those little brackets just like your style sheets and all that. And then finally, after you've added this to your code base, you'll need to rebuild Modernizer. Which you do by going to Admin, Config, Development, Modernizer, or something like that. But you can go to Admin, Config, yep. There we go. So this is the actual page. I think it's under development. So then you'll get a page like this. And right now this is showing you all the tests that are in my Drupal installation. Which is pretty cool. People tend to get annoyed if you, well, people who care about this stuff, say, hey, don't put a 7K JavaScript file in your thing. It's slow and it is. If you load up all the Modernizer tests in this case, they're kind of right. So the idea is that Modernizer can like make custom builds, right? And so what this does is it makes sure that all of the modules and themes in your system that are requesting Modernizer tests will have them when you rebuild Modernizer. So we can go click here and we'll see geo-location. This one is kind of a system level thing. Actually those three are this is Modernizer load. Then we got a border radius test which is completely contrary to what I just told you a minute ago. And CSS transitions and all these things, right? So then I'm gonna click build. You'll see here that this interface has loaded up and it's ready to download already. It's pretty hot. So you can see border radius is checked. Geo-location, inline SVG, printchip, Modernizer load, et cetera, et cetera. There was one that right there that I checked. But the idea is that you can take this thing and it's ready to go and you just select all and you drop it into your code base. Which I hope is convenient for you. I find it convenient. So that's the test API basically. And you might be thinking like, man I don't do this very often. But so like Drupal 8 is coming out and it's supposed to be a CMS on top of a REST server. And there's all this fancy stuff that we're gonna be doing with it. And people are gonna be building single page apps and people are gonna be doing a lot more stuff with HTML5 as time goes on, right? So this is gonna be a lot more useful because then you're gonna install a module that uses WebSockets or something like that. And it's like, I'm the WebSockets module but then you don't have your Modernizer test built into a Modernizer for it. And you'll be like, why have my browsers not working? And this is why. So keeping, letting Drupal report what tests it has and what tests it needs is gonna become a little more complex and it's gonna become a lot more mission critical too in the future. So we're kinda like trying to skate where the puck's gonna be here on this one. And I think in the future it's gonna become pretty handy. Right now there's like seven or eight modules that implement this hook. Geolocation field is one, font your face is another one. Themes have it, Aurora has it. But anyway, if you like writing tiny little hooks and making patches and stuff then come talk to me afterwards. Yeah, so that's the test API. The load API is similar. So just like the JavaScript that we were looking at before you can write a hook that makes a Modernizer load command. Pretty nifty. So in this case you just say, it's basically the same syntax but kind of arraified because you're not doing Drupal unless you're building an array of something. So the test there is Modernizer Geolocation in a string this time. Do not just print it out without quotes. The nope in this case is the path to geo.js but it's inside this geolocation module. This does not exist, this is not a real example. And then, I'm sorry, then the callback. And then this turns back into an identical version of what I just showed a second ago where you test for geolocation and then you do sites all modules, blah, blah, blah, then it does the initialization. So then how do themes do this? Cause themes don't have hooks, right? This is actually the very first thing I did to make this thing. I was like, how can I make conditional loads in a theme info file? And I'm scratching my head trying to figure this out and then I realized, oh we do this all the time. Every time you write style sheets all bracket, you're making a conditional load but what you're doing is you're saying all, you're just saying true always, right? And so that little style sheets all thing in the theme info file can contain min width 16 pixels or while that'd be a silly media query but still you can put media queries into style sheets in that little all thing. And so modernizer uses the same syntax. You can see here the modernizer keyword is the name space that this module looks for and then the test follows and it says modernizer CSS filters. You can put yep, you can put nope, you can put both or load or callback or complete in there, the whole API is there and then you put your final name, right? And then the module will know that which theme this came from. In this case it came from mytheme.info here so that's might be the missing link that wasn't in the code block. And then it says modernizer load. Look for CSS filters and then if it works then load sites all themes with my theme. CSS super fancy, CSS. There you go. And then if you really, really are a coder and you like doing theme hooks, my theme modernizer load alter works because themes can only use alter hooks that can't use the real ones. So cool, here's a bunch of docs. The module itself is at triple.org slash project slash modernizer and then if you click read documentation all of the links that are on this page are straight away in the read documentation section of the module and then also like I said if you check the session page later today when I find some wifi that can handle a git push it will be up on the session page. So these go through the basics of feature detection, installing the modernizer module because you have to like kind of put modernizer in the right place which is sites all libraries. And then it shows you how to like do all the stuff that I just said but with more written words to help you out. You didn't expect to see that, did you? So pitching compatibility is an interesting thing and perhaps probably the most palatable subject that I'm going to talk about because we've all built a site and then like I said the client wants to turn it into a black and white TV show and you've made this HDTV thing for them. And you're like, come on man but instead of just like rolling your eyes and just dealing with it we can kind of start to change and educate people in order to get them to accept that the web is an inherently inconsistent medium, right? So there's a link here to a talk, Kyle Simpson is a JavaScript developer in Austin, Texas. It's called browser versions are dead and he does a fantastic job convincing you of this better than I ever could but basically if you're not up on how Chrome and Firefox and well at least those two they release a new browser every six weeks. So like Chrome 24 is different than five which is different than 26 and so forth and it's just constantly moving. So there's no such thing as like a version of Chrome. You know the dev channel and the canary channel the experimental channel they get updated every day. So it's one of those things where if we say that we support Chrome we're basically lying. Like which version of Chrome do you support? And then even saying like a plus or something like that that's kind of silly too because who wants to write into a contract those kinds of numbers and then you have to support Chrome 20 plus like Chrome 20 six years later, right? And so my idea here is not to pitch compatibility based on browser names and versions but pitch them on actual features of a site. So instead of asking what versions what you know what browsers do you want to support ask what features do you want to support sit down and when you're doing your high level requirements gathering which I hope is going on before you're signing a contract you would say all right what kind of stuff are you going to want on this website? You know if it's just media queries or something like that there are a lot of tools that you can use you could even you know there's stuff that can get around those kinds of things but when we're talking about features it's like do you need geolocation? Do you need location based services? Are we going to need to supply HTML5 video all of these examples that I was giving you before? So the question is what is the site going to do not where is the site going to be shown? You know what a silly question really in perspective. So we can take all this data that we have like can I use it shows all that data right and it's compiled that's real it's not real time but it's very close it's better than any individual could do. So you can take your high level requirements both yours and the clients and plug it into can I use and you can kind of get a rough compatibility percentage so you can take all those numbers and be like well this many browsers are going to be able to support this thing this many browsers are going to support this thing. You can even do the flip side of it too if you want to transform the data a little bit and say okay given that the client wants IE support IE8 they want to support IE8 you can say all right with the features that you've asked for client you can have 83% of that without loading a bunch of additional JavaScript that's going to slow the web browser down. Now this is an option but also you know like your content is going to be this visible right to IE8 which I think is a fair thing to tell a client. This is my opinion. So modernizer three which is not out yet the modernizer library three has this type of project estimation in the roadmap. We've been kind of thinking about this. Already and so tests now include dependencies and links to can I use individual feature tests too which is sweet and systems like Drupal using a modernizer module are poised to take advantage of all this data in a very automated fashion. So I'm just kind of like daydreaming here for a minute but this is an example test and it says this is CSS animations the important stuff's right here. So you see the name the property which is like the modernizer slug that's going to drop into the HTML classes and be used in the object. I mean then there's a can I use slug as well and then a couple other things like links to polyfills and then like warnings and maybe like an article but really what I want to focus on here is the can I use slug that's in here and what this means is when you go and build modernizer you'll be able to basically get a snapshot of you'll be able to get a snapshot of how compatible your site is right now. So since the modernizer module can show you this page I was showing you guys this without being zoomed no one said anything to me. That that didn't that wasn't very nice. Sorry everyone you deserve to see this. All right does that make a lot more sense now? This is what the config screen of the modernizer module does. It shows you all these tests and it shows you what they do and then it lets you click the download button. All right so given that Drupal can know about all the HTML5 features it needs and then we can link all this data to a current compatibility chart you could at any given time have like a compat page on your Drupal site that says in the browser that you're using it is 83% compatible and the browser that you're using it is 97% compatible in the mobile phone that is loading this page it is whatever you know. So this is kind of like my vision for this. This is something that is not in the module right now but it is definitely doable and we're working both within the modernizer team and on the Drupal module to be able to get you a little more leverage when you're trying to build modern websites that use all these features and so you don't just get shot down because like an old browser doesn't handle it you have leverage and you have a little more data to work with and you can be like well if you would just make this one concession we can do this much awesome stuff and you're only losing 4% of site functionality here you're gaining a bunch on this side. So that's the idea here and the module is basically it used to just be like a Drupal Edge.js but given all these enhancements I think it can be a lot more and I think it could be a tool that could help you build better websites for your clients. You could build using more fancy features that are frankly pretty fun to work with if you're a front end developer like me and also like I said you can use it as a business tool and say hey look you being a stickler about this particular browser is only hurting you. It's not hurting anyone else it's only hurting you and your users so kind of chew on that client and see what they say. That's why they don't let me talk to the clients. So that's my idea for you know like yeah all of them are laughing pretty hard back there my coworkers. So that's kind of my idea for helping move the web forward there's a lot of ways to do it but I think that this could be a pretty powerful tool if we put it in the hands of lots of Drupal developers so something I'm gonna be working on this week is like putting more hooks into other modules so that this works a little better for you and then also I am working on Node.js integration which is gonna allow Modernizer to be built out with a Drush command and I would totally demo it but it's broken so I know better. So I'm gonna open it up for questions now. Anybody got questions? I got a couple Modernizer stickers which are like limited edition if you want one but you gotta ask a good question so yes ma'am. Oh, so Modernizer yes I technically wrote the question was are we moving into Drupal 8? So I was involved in getting the tiny stub of Modernizer that we have in Drupal 8 into core and then what we did was we just put the add test API in there so that now you can write an inline Modernizer test at any time so if you need one it's available to use in Drupal 8 already so the tests that came with the library that are in core now are very few and even just the other day someone asked for box shadow and for whatever reason it was decided that it's not gonna be added because it's not like super vital which is exactly kind of what we were talking about before but I will, I don't know how to make Drupal 8 PHP so or symphony or whatever it is but I'm going to try and get the module running really soon on Drupal 8 because as I said like people will be building a lot of single page apps and stuff like that and it's gonna be much more useful in Drupal 8 than it is in Drupal 7 and I think it has a lot of potential already in Drupal 7 so yeah. How does Modernizer deal with like reflowing of in a smartphone from portrait to landscape or tablets that's not really a new page load or anything? Yeah so the question was about reflow and page load and you can do a Modernizer MQ evaluation on window resize or something like that. Another thing that's in here is event device orientation motion which is a test so you can test and see if that happens and then use whatever API is there so Modernizer is not specifically it's not a development tool it's kind of like a meta development tool right so it's a tool for your tools and we're writing a Drupal module for a tool for your tools and that's pretty crazy but yeah the idea is that Modernizer fires once a page load so like my example about Modernizer MQ and screen width and all of that if I expanded that page out then no the mountain in question does not appear and so for that reason someone might choose to use a media query and they'd be perfectly legit in doing so right because then it's gonna reflow and it's gonna show that thing but you can also say on resize reevaluate one particular test or something like that you know it's like four lines of code it's not that tricky and yeah if you do some sort of like debounce thing and make sure that you're not doing it like on every pixel change then you should be good to go thanks. For a project I'm currently working on I'm using a just a you know Modernizer build that checks for CSS column future support and in some browsers it does support it such as one specifically Firefox the newer versions of Firefox comes across as being supported however it doesn't fully support the spec as you know it's kind of currently in flux still how do you suggest handling that when you know the spec isn't fully fleshed out certain browser. Tried carefully. Yeah okay. Yeah so actually there is a Modernizer test for Flexbox and that there's one called Flexbox Legacy and Flexbox Legacy believe it or not used to be called Flexbox so basically what happens is times change and we've got to change with them and when you're using specs that are you know on the edge and they haven't become candidate recommendations yet which is the fancy way of saying web standard then you're kind of like you know using at your own risk right so in general just have a fallback set of styles and then you know make sure that it's working and test that's my cop-out answer for everything but it's not really cop-out answer it's the real answer it's always test. Yeah. A scalability point of view how does it sit with you know aggregating your style sheets and scripts? That's a great question from scalability how are we supposed to handle aggregation and so the proper way to use Modernizer is to not aggregate it with everything else without making too many people fall asleep here the reason is that when a browser is downloading a chunk of JavaScript it halts the rendering of the webpage it blocks the UI is what we normally say and so what happens is Modernizer's actually can be a very visual it's a script that has a very high visual impact on your webpage and so you want to separate it out from your aggregates and put it in the head of your document Modernizer belongs in the head of your document whereas most scripts that rely on DOM ready like anything that uses jQuery or Chibi or any of those belongs in the footer or in the before the body closing tag right but by not aggregating it and by including it at the top of the document it takes a very minimal amount of time to execute and then your features are there your CSS classes are there and your styles can be immediately applied and so forth and so the module handles all this for you you don't have to decide where you're going to put the script if you're using the module because it just puts it in the right place it works with all aggregation and it even works with heavy handed themes that were doing their own aggregation to force things to go into a particular spot and it will never get lumped into aggregation unless you do something really crazy and you probably want it to happen anyway so yeah, does that answer your question? Cool. With regards to conditional loading the example you gave was an image in the CSS file but CSS transitions was another example that's in there where you very much you might have a whole chunk of CSS that isn't relevant to a lot of viewers what are your recommendations for how you break up your CSS structure so that you've got a core component and then conditionally loading those additional elements? Man, I wish I had another week to answer that question so actually that gets into the topic of CSS builds and then when you look at the black and white standard HD comparisons those don't have to be one modernizer test we were just talking about that in a conceptual sense but you could literally build that type of a system and you can have a black and white standard a color and a high def version of your website and what you do is you can just concatenate a couple modernizer tests together so you can say your standard is just like I can't execute JavaScript or I fail all the tests and so you're gonna get a certain set of assets or if it passes these three tests like transitions, inline SVG and those two then you're gonna get like this enhanced CSS and say it can't handle transitions for example well then you're gonna wanna fall back on something like JavaScript animation which is not as optimal for reasons that are kind of outside the scope of this talk but you can make little builds of CSS and JavaScript that are correlated to sets of tests so then you've got a literally a standard color high def version of the website so if something can pass all six tests that are needed for HD then send it down the pipe I'm experimenting with a SAS compass extension called Jacket to make builds like this I don't have any code working or I would like gladly show it to you because it's some really cool stuff and there was an interesting presentation about a month and a half ago by an engineer at Google called his name is Ilya Grigorek and it was called Breaking the Thousand Millisecond Time to Glass Barrier and he mentions some crazy stuff you can do like inlining your vital CSS that shows up above the fold and conditionally loading everything else and Jacket and Modernizer alone can do basically that well, a little bit of deploy scripts are needed but still you're gonna need some other tools to get the whole website working properly Modernizer alone cannot do that but it will still be the decision maker that in a perfect world would be deciding what build of the website that the user is gonna be seeing Thank you Yeah, any other questions? Cool, one last slide here if you could, I'd love it if you'd rate the session the session page has the URL now, I'm told I trust them even though it wasn't there before I started the short link is right here if you don't wanna type it all out j.mp slash meet-modernizer and then there's like an evaluate session thing but anyway, thanks for coming everyone and I hope you enjoyed it and see you around DrupalCon