 Cool. We are going to start in a minute. I just wanted to make sure you could all hear me. Carry on. Take that back. We'll be mic'd anyway. Test? Yes. Cool. Okay. We're going to start a minute early just because there's lots of awesome stuff that literally happened last week, and I might go my entire hour. First and foremost, before I continue, all of these slides are going to be online. In fact, they're online right now. Snugg.com slash munic, S-N-U-G-U-G dot com slash munic. That will have the links to all my slides, as well as the links to go rate the session once this is done. If you could rate the session, that'd be awesome. So, responsive web design with Sassin Compass. Come on, get sassy. Who am I? Well, my name is Sam Richard. I'm a front-end developer. I'm Snugg-Ug all on all of the internets. I'm the organizer of the New York City Responsive Web Design Meetup, co-organizer of the Sass Meetup in New York, and one of the organizers of the first ever SASS conference that will be taking place in New York next year around the end of April, beginning of May. It's going to be awesome. I hope you come check it out. What is this session? This session is very specifically an intermediate session. It is not an intro to Sass session. I'm not going to try and convince you to start using responsive web design. I assume that from all the mobile talk that's going on, you're already convinced of that, and I am not going to teach you how to compile Sass with Drupal. In fact, you will only hear Drupal one more time throughout this talk. The session will, however, give you a basic overview of responsive web design, specifically because everyone has a little bit of a different opinion on what it is. And all of these tools that I'm going to show you all are based on the viewpoint that I'm going to present very quickly at the beginning. I'm also going to show you some Sass-encompassed tools that make responsive web design and progressive enhancement really awesome. And I think you're going to dig them. So what is responsive web design? Responsive web design is a set of tools and techniques and best practices that all come down to a single point. The web is an inherently unstable medium. Ethan Marcote, about two years ago, wrote an article for a list of part that really coined the term responsive web design. In it, he described three features that you absolutely need for good responsive web design. The first is fluid grids. The second is media queries. The third is flexible media. But it's not just features that you need to successfully do responsive web design. You also need to follow a couple of principles. You need to be designing for mobile first. That is not just devices, but that is mobile user experience and the mobile user context first. You need to be putting content and navigation as your primary concerns on your website and make flashy design and your social sharing secondary concerns. You need to embrace progressive enhancement and build on web standards. That's HTML, CSS, and JavaScript. You need to design on a grid. Ideally, you need to design on a grid specific to your design. That means that those 960-grid Photoshop files that you have lying around everywhere, throw them all out. You want a grid that is specific to your design because ultimately, responsive web design is about you and your content in your design. And finally, you need to design in browser because you can't articulate fluidity on paper. So tools of the trade. This is what everyone came to see, sass and compass. I'm going to be talking about a couple things today. I'm going to be talking about the SUSE and the Singularity Compass Extensions. Those are two semantic fluid grid extensions that will allow you to design custom grids for your work. The breakpoint and respond to Compass Extensions, which make working with media queries awesome again. And the toolkit Compass Extension, which is a set of useful bits and bobs that I've written for progressive enhancement. You also need to use Modernizer or something very similar to it. Modernizer is modern feature detection. The way that we have in the past always done feature detection is we've UA sniffed and then guessed what features are available in the browser based on our UA sniffing and what we know about those browsers. Why can't we just feature detect? If I want to know if something supports touch, why detect if it's an Android device or an iOS device and then assume that it has touch based on that? Why not just see if it has touch? That's what Modernizer does. And Modernizer does it in an awesome way, providing you with CSS hooks and JavaScript hooks that you can get into. You need a text editor. I really like text-made or sublime text. It doesn't matter what you use. You want something with syntax highlighting, but you need a text editor. You don't want to be doing this in a WYSIWYG markup thing like Dreamweaver. In fact, you really can't. You need a modern web browser. These are modern web development techniques. You need a modern web browser to develop them in. I really like Google Chrome. It renders everything really nicely. If it works there, it generally works most other places. It's nice. It's friendly. It's awesome. You need Live Reload or something like it. Live Reload is this awesome little app that will soft reload your assets in browser for you, allowing you to design in browser. Basically, my workflow is I have my browser open and I have my text editor open. I save a change in my text file and I immediately see it in my browser. It turns my text editor and my browser that I'm actually going to be producing into my IDE. And it's awesome. I've used it awesome a couple of times and I promise I won't use awesome anymore. You need Adobe Shadow and you need devices. Adobe Shadow, if you haven't heard of it yet, is this great little thing. Since Adobe stopped supporting Flash on mobile devices, they've decided, hey, instead we're going to be the world's most awesome HTML company. And they've done a couple of really cool things. They're proposing amazing specs to bring the power of these graphic design tools that we've had, like Photoshop, into the browser themselves so you literally can totally drop Photoshop. They are working on a new HTML editor called Brackets, which is great. It's a total HTML-based text editor. And then there's Adobe Shadow. Adobe Shadow is this nifty little extension. It runs off of Google Chrome. Another reason why I like Google Chrome. And apps on your Android and iOS devices. And what it lets you do is it lets you take your desktop computer and all of the connected Android and iOS devices and navigate around the web on your desktop computer. And then wherever you go on your desktop computer is immediately mirrored to those other computers or to those other devices. So you can have three Android smartphones, a couple tablets, an iPod Touch, an iPhone, and an iPad all in a row with your desktop. And you navigate one place with your desktop and you see it everywhere. It's instant feedback for all of your devices and all of your different breakpoints. And I can't begin to tell you how cool it is. You just kind of need to see it. And you need to really be testing on real devices as opposed to software emulation. Because while software emulation will get you so far, there is nothing quite like user testing on an actual device. And then finally, you need a vector graphic program. One of the pieces of responsive web design, one of its facets, is resolution independence. And one of the easiest ways and most accessible ways to start with resolution independence is SVG images, scalable vector graphics. SVGs are great. I'm going to get into them a little bit later. But you need something to create them, be it Raphael.js, which is a JavaScript drawing library, or a really illustrator or something like it to draw them on your computer using tools that you already know. But there's also some stuff to avoid. Avoid browser plugins like the Plague. Like I said, Adobe a year ago decided to drop support for Flash on mobile. And as of literally a week ago, they are no longer accepting installs. That means that there is not a single device in the future, be it an Android or an iOS device, that will have Flash installed on it. You just can't use Flash on the mobile web. And really, you shouldn't be using Flash anyway. Its time has come, and its time has passed. This includes Silverlight as well. Single browser prefixes. Now, I'm not against browser prefixes. I like them. They allow us to try out experiments and code. The issue with browser prefixes is when you only use one, like only using WebKit device pixel ratio, or only using Moz border radius. The point of the prefixed properties is for you to test out experimental features. But you always need to have a fallback to the real feature, even if the real feature doesn't quite exist yet, just in case you become standard later on. So don't skimp on prefixing. You can either do this through LiveRoo's prefix-free JavaScript, or because we're in SAS and Compass land, Compass will prefix pretty much anything and everything you want under the sun out of the box. It's awesome. You need to avoid CSS frameworks. CSS frameworks generally give you three things. A bunch of pre-designed stuff. A grid that has half classes and half semantics. And then media queries that, because of the nature of CSS frameworks and needing to appeal to a wide audience, generally are device-based breakpoints. If you're any good at your design job, you're not going to want any of the design crap. We have tools to make custom grids, to make our designs really awesome, and you shouldn't be doing device-based breakpoints. So CSS frameworks generally give you nothing that you actually want to work with. They're OK for prototyping, but you really don't ever want to use them in production. The phrase, pixel perfect. You must drop this phrase from your vocabulary now today. It is something that doesn't exist in response web design. In fact, I only write pixels so I can convert them into Ms, because it's easier to find stuff in JavaScript using pixels than Ms. But don't use pixels. Pixels don't exist. Pixel perfect doesn't exist. There's no such thing as pixel perfect when you're dealing with a fluid responsive design. Photoshop. Everyone uninstall Photoshop right now from your computer. Not quite. But Photoshop really is a bitmap editing tool. It is not a web design tool. As pretty much I'm going to guarantee every one of you has ever done, when you've gotten a Photoshop file, you've needed to use that as a basis to do the actual design in browser. Because things like fonts, and colors, and vertical alignment don't really work in Photoshop the same way they do in the web. So when you're designing in browser, it provides you with the tools that you can actually use on the web. And if you're designing in Photoshop really what you're doing is you're translating a print design to the web. We want to be designing for the web. And device detection and designing for specific known current devices. Device detection, as we just discussed with Modernizer, is kind of junky. But more importantly, there are a billion different devices. Even things, even good device detection that doesn't spit you out an actual device, but rather groups things into mobile, tablet, desktop, TV, all of that throw it away. The device doesn't matter. It's your content that matters. And you also don't want to be mimicking native apps, native apps in your design. Because really, if you're trying to dress a cat up like a dog, why not just buy a dog? Your device detection is bad, and you should feel bad. Why? The desktop is not the web. Today, we have laptops, we have televisions, we have smartphones, we have e-readers. That's the web today. But tomorrow, everything will be the web. So please, everyone, repeat after me. Responsive web design isn't about current devices and known unknowns. It's about future devices and unknown unknowns. Repeat after me. Responsive web design is bad. Thank you, I think. To quote Brad Frost, the point of creating responsive sites is to create functional and hopefully optimal user experiences across an ever-growing context of web-enabled devices. Now, that's out of the way. Let's get to what you all came for, our SaaS and Compass. But before we go anywhere, let's cheat at CSS. So first things first, I'm going to be discussing a lot of Compass extensions. In fact, pretty much everything I'm going to be talking about is a Compass extension today. Compass extensions can be thought of as modules for SaaS. There are ways for developers to package SaaS and JavaScript and stuff that they've written and give it to a user in a nice, easy-to-use way. And they're super awesome. And there are a bunch of Compass extension developers in the Drupal community. And there are a bunch of us who actually contribute straight into Compass itself. So whenever you see gem install whatever, that is installing a Compass extension from the command line. Yes, we're going to use the command line. We're big boys. We can put on our big boy pants. Plus, the command line isn't as scary as everyone thinks. Whenever you see require extension, that goes in your config.rb file. That tells Compass that I actually want to use this extension to go find where it lives. Whenever you see add import extension, it's generally a best practice amongst Compass extensions to have a partial named whatever their extension name is, that you just import and you get the whole extension. This isn't always the case, but it's the case 99% of the time. Check with your local listings for more. This goes either at the top of your working file, so style.scss or sasss. Or if you're using base partials, like I would suggest you do, it goes at the top of your base partial. Import it, base partial, use it everywhere, golden. So first thing we're going to do, we're going to import Compass. This gives us everything Compass has to offer with none of the CSS output. This will give us all of the CSS3 awesomeness, all of the typography awesomeness, all of the vertical rhythm awesomeness. Basically, every single mixing that you'd actually want to use from Compass, it gives you to use right off the bat, so you don't have to worry about importing anything else ever again. And it doesn't hurt compile time. Remember, all of these imports that you see like this are compile time imports. They are not in browser imports. So you won't get any performance from them. First thing we're going to do, star, add, include, box sizing, border box. Everyone knows the box model. Everyone hates the box model. I have a 20% width div. And then I want to add a 1 pixel border. And then I want to add a 3M padding on each side. Can anyone tell me how wide in percentages my div is? I take it by the laughter. The answer is no, not without kelp. Box sizing, border box, and specifically this syntax, is a nifty little thing Paul Irish suggested we started using about a year ago. And it's awesome. It gives us a natural box method. What it allows us to do is that 20% width, no matter how big the borders are, or how much padding we add, it will always be 20% width. Why is this important? For fluid grids. It means that our grid system, we can throw anything we want on a semantic grid. And it will stay the width that we want. And it will be happy. And it will be nice natural box model. I've literally used this on every project that I use. And what's great about it is it has support from IE8 and up. So you can use it anywhere. And you cannot feel bad about yourself. So that's cheating at CSS. First things first, responsive grids. First one I'm going to talk about is SUSE. SUSE is a responsive grid system written by a guy named Eric Meyer. Not that Eric Meyer, a different Eric Meyer. That is a semantic symmetric grid system. SUSE requires SUSE, imports SUSE. It comes with a bunch of defaults that are pretty sensible, 12 column grid, column width, and 1M gutter width. And the grid padding, which is the padding on the side, is the same as your gutter width. Now you might be asking yourself, well, why have we set column width and gutter width in Ms if we're building fluid grids? And the answer is, SUSE comes with a container wrapper that, using this math, will figure out a max width for your grid. You don't want to use container. You don't have to use container. And really, it doesn't matter. But it's nice. Container is nice. I like container. And I like SUSE. In fact, I like SUSE so much that I like SUSE so much. And a lot of the Drupal community like SUSE so much that the Drupal.org upgrade is being written using SUSE. So SUSE rocks. And using SUSE is pretty drop dead simple. First and foremost, if we've got a page wrapper, so this is the HTML that we're going to use. We've got a page wrapper. Inside the page wrapper, we've got a main div. We've got a sidebar first div. So really, the source order is page wrapper, main, sidebar first, and page wrapper. I'd include container for page wrapper. That gives us our container. I'd include span columns 8. I want my main to be 8 columns wide. Sidebar first, I'd include span columns 4 omega. What omega does, it's omega tell SUSE. I want this column to be the last one in the row. And then I'll do some nifty things. But 8 plus 4 is 12. I've got my math right. Cool. What does it spit out? Well then, six lines becomes a whole lot more than six lines. And this is where SAS is awesome. Because this is the actual math that you would need to figure out in order to do it. And this is the actual math you need to set up a semantic grid. But we call three mixins, and we're good. So page wrapper, you'll see it gives us a max width plus a bunch of gobbledygook. That gobbledygook is IE support. Columns, clears, stuff like that. It's IE support. Main, widths calculates the width for us, including our gutters, floats it to the left, gives us a margin right for our gutter. Display in line, same with sidebar first. All pretty simple. Susie is also awesome for nested grids. So if we have that sidebar, and we have inside that sidebar, we've got a div for our username, and a div for a social icon of some sort. We want the main column to be, or the username to be three of those four columns. And we want that icon to be one of those four columns. Now, if I just did three columns without the context, so span columns three, comma four, four is the context of how many columns it's in. What we'd wind up getting is we'd wind up getting strange percentages. Because really, we're not looking for three columns out of the 12 columns. We're looking for three columns out of the four columns. So we've got context there, username, social, that includes span columns, one omega, four. And what do we get? We get fluidities, and we get awesome. One thing that I do want you guys to look and bear in mind is take a look at our margin write and our width for username. So three out of four, if we were doing that math by hand using the good old fashioned target divided by context times 100%, we'd come out with 75%, wouldn't we? Well, that doesn't actually work. Because we need to take into account gutters. Now, if we remember two slides ago, our margin write was about 1 and 1 1⁄2%. Now it's something like 5 and 1⁄4%. Susie does all the math for you converting the percentages to make sure your columns and your grids line up. It's very, very pretty, very, very nice. And really, Susie will work for just about 90% of everything that you want to do grid-wise. That is, of course, unless you like symmetric or anti or asymmetric grids. By a show of hands, who has heard of grid-set app? The cool, awesome thing by Mark Bolton, who actually is giving me a talk next. OK, who knows what an asymmetric grid is? Raise your hand. Cool, the same people who know grid-set app. Awesome. So the 10% of the time where you don't want a symmetric grid, you're going to want a crazy asymmetric grid. Susie doesn't handle that. But there's another grid system called Singularity. Singularity does. Singularity actually was specifically built to handle asymmetric grids. First started by a guy named Scott Kellam. And then myself and Mason Wendell, who is creative director over at ZivTech, have been helping him refine it, as well as John Albin, who proposed an awesome way to position columns that we're actually using in Singularity. So Singularity is easy. Gem and Thal Singularity require Singularity, import Singularity. So Singularity, of course, will do symmetric grids. Let's say you want a crazy little grid. Let's say you want a crazy little asymmetric grid, an 8, 4, 2, 2, 3 grid. Sure, Singularity can handle that. What about if you want to compound two equal grids together and get a totally different crazy grid? Singularity can handle that. What if you want a repeating grid? What if you want a 3, 2, 1, 3, 2, 1, 3, 2, 1 grid? So 3, 2, 1 repeated three times. Well, repeating grid will handle that. What if you want a grid based on a ratio, like the golden ratio, because the golden ratio is awesome? Well, ratio, whatever you want your ratio to be, and then how many columns you actually want. So in this case, that's golden ratio in four columns. Singularity will handle this and pretty much handle anything that will spit out a list of unit list numbers. And it will turn that into a grid for you. Using Singularity is ever so slightly different than using Susie. Columns are the same. Gutter, we need to set the gutter and our columns to be the same unit. But once we've done that, we're good. The way that Singularity differs, however, is how you call what column you want. Because Singularity is designed as an asymmetric grid system, we can't always assume that you're going to go across the board like that. So you need to call not only how many columns you want to span, but which position in your grid you want it to sit in. So I'd include grid span 1 says I want it one column wide, and I want that column to be the first column. And that will be our first column. And I have middle grid span 1, 2. I want that to be one column wide as well. But I want it to be in the second column spot. And I'll handle that. Grid span 1, 3. Same deal again. Grid span 2, 4 is a little bit different. Grid span 2, 4 says I want to span two columns, and I want it to start at the fourth column. So this will span our fourth and our fifth column. Now bear in mind, these aren't equal grids, so you're going to get some pretty odd shaped things. But because they're not equal grids, that's why we need that context. And what does Singularity spits out? Singularity, like I said, is a little bit different. It's designed to be a little bit modular. So you'll notice that it spits out the border box for each and every one of these, or the box sizing for each and every one of these, because it doesn't assume that you want box sizing for everything, which can be nice or not so nice. It will clear fix everything for you, which is a requirement for John Albin's method. But it's OK. I can deal with clear fixing. And then it'll spit out the margin right. The margin right and the margin left really are where all the magic happens in John Albin's method. But it does all the calculations and everything. Nice about Singularity, though, is Singularity has another way that you can use it. Singularity, if you've used Grid Setup or if you've used any sort of grid system, will know that generally grid systems come with 30 kilobytes worth of classes that have every permutation of possible grid layout that you can have. Singularity can spit that all out. But instead of spitting it out as classes that you can then go apply stuff to, it can spit it out as a new SAS 3.2 silent selector, placeholder selector, which means that you can extend off of them like normal, but only the ones that get used actually get printed, which is pretty nice. It can cut down on overall output. So Grids, Grids are awesome. Grids are nice. But that's only the first part, fluid grid. The second part, media queries. And that's where Breakpoint comes in. Breakpoint is Compass Extension, started by Mason Wendell and the two of us just went off on it and are having great fun playing with it. This is a media query handler. And for our intents and purposes, we think it's probably the best thing on the block. Gem install Breakpoint, require Breakpoint, import Breakpoint. It comes with a couple of defaults. Default media is all. Why did we choose default media? All because of an article I read from Bruce Lawson, who is a dev over at Opera. He said that the Opera set top boxes, or the Opera browsers that are going to be embedded in upcoming televisions put forward that they are screen type media because everyone's been writing their media queries only for screen. And that's an issue, because if they made it a TV media, which is what I would like, because TV has a totally different pattern for everything than all of our desktops and mobiles, no styles would be applied. And they don't like that idea. So we decided that all is best so that we can ensure that no matter the media type, you're going to get your styles. The default feature is MinWidth, because we're designing mobile first. We're going to go up. MinWidth is our default feature. We can do pairs as well. Pairs of numbers will give you a MinWidth and a MaxWidth. By default, you can change the height, whatever you'd like. Breakpoints to M's false. If we flop that to true, I'll show you the magic of that in a minute. But you now might be asking yourself, well, you said a couple slides ago that device breakpoints are bad. How do I do breakpoints if I don't do device breakpoints? Well, Stephen Hay probably has the best quote on this. Start with your small screens first. Expand till it looks like shit. Time for a breakpoint. That's what I suggest you do. So this is sample code from a navigation that I built. Starting at my small screen layout first, which is navigation, vertical block layout. I expanded it until it didn't look good anymore. And then I set a breakpoint. Main nav inline is 482 pixels. Then I kept on expanding, kept on expanding, and saying, hey, look, at this point, I want to move my navigation from here to right next to my logo. That happened to be at 823 pixels. So let's write some CSS. Main nav, clear both. Clear both is Susie's way of saying, I want this to span my entire grid. List item, display block. That's my vertical list item. That include breakpoint, main nav inline. That's that pixel of value. Display inline block. That will transform my vertical list to horizontal list. Outside of that nest, include breakpoint, main nav inline large. That includes span columns, 9 omega. So moving it from spanning everything to spanning nine columns, very last of the row. Pretty simple. What do we get? Well, we get main nav clear both. We were expecting that. We get main nav li, display block. We were also expecting that. Here's where the cool happens. We have a media query written. We nested a mix-in. We got a media query. Media, there's no media at all. One of the neat byproducts of us using all as our default media type is that by spec, you can drop the media type in the end, producing even if it's slightly smaller output code, it's still smaller output code, which we think is cool too. There's a variable flag to put it back in, but we think it's cool like this. Main nav li, display inline block. At media, minwith, 23 pixels, and all of our sass awesomeness, or suci awesomeness. One thing that I am going to point out before I go on is that there is currently no way to condense all of these media queries into a single-like media query. There are actually some cascading issues that can come from that, but there are currently a issue open to allow us to do it by hand. That Nathan Weisenbaum, who is the maintainer of sass, finally has agreed to go forward with. So it's coming. It's just not available yet. That will mean that you're going to have these media blocks scattered throughout your output CSS. It's not ideal, but I personally am OK with that trade-off for the much more maintainable sass that I have to write. Now, back to that breakpoint M stuff. Let's turn it on. Same CSS, except that our features are now different. Our features are now M-based. Now, first question you may ask, well, why the hell do I want them M-based? So pixel media queries are OK, except that they're totally not accessible. They fire at a pixel width of the v-port. M-based media queries, however, are based on the browser's root Ms, which means the browser's base font size. What this means is M-based media queries will fire based on the user's choice of base browser font size. So if they increase the font size, your media queries will fire. If they decrease the font size, your media queries will fire again. If they choose to have a larger base font size, your media query will fire again. What this means, and this goes back to the first point of responsive web design, or Brad's point on responsive web design, it's about creating hopefully optimal user experiences regardless of user context. And that's what M-based media queries are for. Now, something that we added in last week is the ability to create no query fallback code. This is something that it was highly requested, and you can now do it, and it's super cool, and it's a neat little layout pattern I'm going to show you. There are three ways that we determine that people would want to create no query fallback code. The first way is they would want a wrapper of some sort, be it an ID or a class, inside the same CSS file as their main styles, as their break points, as their media queries. The second way we determine people would want it is with no wrapping, but in a separate style sheet. And the third way we determine people would want it is with wrapping classes or whatever in a separate style sheet. So we've given you a way to do all of them, and it's pretty easy to set up. So in the case of a layout, we would create a layout partial, background red, that include breakpoint, 567 pixels, something I made up. And then we pass in no query with a class for wrapper class or true for no wrapper. And then inside style, we set our variables, breakpoint no queries to false, breakpoint no query wrappers to false. We are using this third, wrapping selectures in separate file sheets. And then we import layouts. In our no media query CSS file, breakpoint no queries is true, and breakpoint no query wrappers is also true. And we import layout. Let's see what we get. On style.css, we get foo with background red and our media query. In no media queries, we get our wrapped foo with background of green, exactly what we want. So this is a way for you to essentially write one layout file and be able to spit out anything that you want, including, for instance, a desktop-only CSS layout for IE or something. It's cool. Trust me, when you start using it, it's very cool. And finally, there's respond to, or not finally, but finally for media queries, we have respond to. Respond to is semantic breakpoint naming. It's the breakpoint compass extension underneath, but with a more semantic syntax. Some people prefer the semantic syntax. I happen to be one of them. So that's what it is. Essentially, you create a list of your different media queries. This is the exact same code that we had before. The big difference is the semantics. Instead of add include breakpoint may nav inline, we now add include respond to inline may navigation. I find I tend to be more verbose when I'm dealing with strings as opposed to dealing with variable names. So that's why I like this. And then add include respond to inline may navigation loaded right. And we get the exact same output. So we've got two down, one more to go. Fluid grids, media queries. Finally, we have flexible media and progressive enhancement. So toolkit, toolkit for modern web design. Gem install toolkit, require toolkit. Now, you could import all of toolkit, but I'm going to show you all the pieces of toolkit separately. So we're going to import them as we go. But first, a note on flexible media. SAS will not magically give you flexible media. Nor will Compass, nor will Modernizer, nor will Drupal, nor will NEJS or CSS Framework. In order for flexible media to be a reality, we need a new web-based standard. There are currently two standards proposed, a picture element to the W3C and an image source, or a source set element attribute, I'm sorry, source set attribute for the image element to the WhatWig. Both of them are competing. Neither of them have been accepted as standard and have been recommended. So until the time that one of them becomes recommended, everything's a hack. Choose the one you like. That being said, there are some things that you can do in CSS and therefore SAS that make flexible media pretty friggin' cool and pretty friggin' awesome. And I'm going to show you how to do it. First, toolkit fluid media. Add import toolkit fluid-media. First things first, our standard little image CSS. Max width 100%, height auto. What does this do? We'll take our image, and it won't expand it if our holding container is large. But the moment that our wrapping container becomes smaller than our image, our image will scale down. But it will also, because height auto, scale and proportion. It's neat, it's small, it's little, it works, it's dirty, it's cool, use it. Second piece, scale elements. Did anyone read the intrinsic ratios article on a list apart two weeks ago? No, cool. So I'm about to blow your minds. Intrinsic ratios are this neat little, not white property, but property-ish of CSS children, or of HTML children, where with the right combination of CSS hackery, you can force a child to maintain a certain ratio based on its parent's top padding. What this means, and it works for all elements. So what this means is you can embed a YouTube clip, or embed an iframe, or have a video tag, or really anything that you want. Have an intrinsic ratio on its parent, and it will scale with no JavaScript. Yes, you heard me right. Luaid YouTube embeds without JavaScript, pure CSS. The first time Scott Kelham showed me this, I couldn't tell you how happy I was. It was something that he had come up separately from this article, and it was one of the greatest days of my life in the past summer, because I had been trying to hack around doing this in JavaScript, and now I don't need to anymore. And what's even better is now you don't need to anymore. Foo, that includes scale elements. Scale elements is a mix-in in fluid media that assumes three things. First thing it assumes, the scale media mix-in assumes three things, I should say. It assumes that you want a 16 by 9 ratio. It assumes that you want your child to be 100% of the width of the parent, and it assumes that you want it to apply to all children selectors. This is a case where we do need to use the asterisk all selector if we want it to apply to everything, because we need to be targeting children of the parent selector. It's a little bit hacky, it's a little bit not nice, it's a little bit ugly, but it works. You can also change that to be just the tag that you want to target, but by default it's all. So we're just going to deal with it. You can also change the ratio by passing in ratio for whatever you'd like, four thirds in this case. What do we get out of it? Will we get intrinsic ratios? Foo and bar are extended together to reduce the amount of CSS that's actually output, position relative, height, auto. Their children get connected together into comma-separated lists to, again, reduce the amount of CSS output. And that whole chunk there, that is the magic of intrinsic ratio. You can study it, you can figure out how it works, that is the magic. And then in Foo and Bar, we get the width of what we want our children to be. And we get the padding top, which is the calculated percentage, which gives us that fluid responsive awesomeness. Intrinsic ratios, they will make your life so happy. Next, toolkit for progressive enhancement. Now, like I said, Modernizer. Modernizer is awesome, you really need to download a development build of it, but assuming that you download a development build, what it will do is it will create CSS classes that we can hook into from our style sheets to have essentially feature detection in our CSS. The way that it does this is generally puts a class or a set of classes on our HTML element that we can then jump into. Kind of like how we always put no JS or JS classes on in case we need to have different CSS depending on JavaScript being enabled. So two very simple little mix-ins. Enhanced width and degrade from what you're using inside of the mix-in is whatever the base Modernizer classes or whatever the equivalent Modernizer detection you're doing is. So for Modernizer, touch will give us a touch class or a no-dash-touch class. We want touch. So enhanced width touch, degrade from touch. And what do we get from the output of that? We get dot touch dot foo, whatever our min height is. And no touch foo, and also no JS foo. Because again, this is progressive enhancement. So we need to assume that if no JavaScript is enabled, we need to assume the degraded state. So we include no JS as well. That's cool. That's neat. That's little. You can do it on your own. Really the reason those mix-ins exist is for semantic purposes. But then you get to this. This looks like a lot. And it is a lot. And it's even more when you see the CSS. Let me explain what we're about to do. Text replacement with background images in CSS is pretty standard. But we have a problem. It's not in the least bit resolution independent. So I came up with this strange little pattern that I particularly like that essentially is text replacement combined with Modernizer SVG detection to either replace my text with an SVG image, which is resolution independent, or a ping image if SVG is not available. You can also, with Compass, create image sprites. So I'm going to combine that with Compass's image spreading to do some really awesome, crazy stuff. So first, set a variable, use of our icons. This is the folder that your image sprites are stored in, or that your individual images are stored in. The way that image sprites work with Compass is Compass will only do it with ping files, or will only sprite ping files. And they all need to be in one folder. What you wind up getting is you wind up getting an image of all the ping files in that folder. So in our case, it's Assets user bar. So I have all of my sprites, or all the images I want, part of the user bar sprite inside of there. I also have all of their corresponding SVG files in there with identical names. So if I have a user.ping file, I have its corresponding user.svg file. If I have a necktie.ping file, I have its corresponding necktie.svg file. So I have user bar icons. I'm going to include the sprite map generator mix-in. This will make us a sprite map, but it will make us a smart sprite map that will only be used if we call this replace text progressive enhancement mix-in. So include replace text pe, user bar icons, and the name of the icon that we want. This second one is the same thing, except that we're not gonna inline the SVG. I'll show you the difference in a second. So, repair to gasp. This is the CSS and output you get from that. That's quite a lot, right? What's even scarier is this is the absolute minimum that you need to write in order for this to work. So, what has Compass done? It's created an image sprite for us. It's created a ping and an image sprite for us, that it knows where everything is. We didn't have to create an image sprite to use an image sprite. How cool! Bar in Baz. There are two different ways that you can replace text. If an item is an inline element, you squish it into oblivion. If it's not, this is actually Scott Kellum's replace text mix, or replace text code, which is basically indenting everything off-screen or out of the div, so that's cool. Then we go back to our degrade from mix-in. No SVG and no JS for barn, no SVG and no JS for Baz, background image, whatever our sprite is, background repeat, no repeat. Now, what's important about this is I've gotten a question saying, well won't that download anyway? No, no it won't. Those styles should never apply, especially if you're loading Modernizer in before you get to your HTML. But because those styles will never apply for an SVG enabled browser, you're never gonna need to download that. That's one HTTP request gone. Then, for bar, we have it set up to include the heights and widths, so we can make sure that everything is nice and compact. Background image, URL, nonsense. I've base 64 encoded the SVG directly into the CSS. Now why would you do that? Well you do that because the HTTP request to grab an SVG is actually larger than most SVGs you're gonna use. So why would you add that extra HTTP request? Sure it makes your CSS a little bit larger, but you're blocked on your CSS anyway. Instead, base 64 encoded into your CSS and then it gets cached with your CSS and it's one of those HTTP requests. It's a trade-off I really love. But if you don't so much love that, you can then inline SVG false will spit out a URL for you. And background position. It knows where your images live inside your sprite. You don't have to figure that out. Which again is one of those friggin' awesome things. Now if you wanna use Toolkit, Toolkit is essentially my way of giving back to the community and saying that entire talk you just saw, you don't have to remember it. Just download Toolkit and it'll figure it out for you. If you require Toolkit in an existing project, you can gem install Toolkit and you'll get all the stuff you'll see on the next page except for the grid systems because it assumes you already have a grid system. But if you're creating a new project, compass create my project dash R Toolkit, that's required Toolkit, dash dash using Toolkit slash Susie, Susie, which will give you the entire Toolkit stack plus Susie plus breakpoint. Toolkit Susie dash respond dash two which is that entire thing plus respond two. Singularity which is singularity and breakpoint. Singularity respond two which is all of that. So it's literally a one line, it's literally one line to get everything that you just saw. And what do you get? Well, you get all of compass important for you. You get Toolkit, you get either Susie or Singularity, you get breakpoint or respond two, you get the border box model. You get a development build of Modernizer with Yep-Nope built in. Does anyone know what Yep-Nope is? Raise your hand. Higher, higher and higher. Cool, so not most of you. Yep-Nope is a condition-based asset loader. So you can do something like see if Modernizer touches true and if Modernizer touches true, you can load in all of your touch JavaScript and not have to load it in if it's not true. It's awesome and I love it. So I've included it in the development builds of Modernizer that you get. Loader.js which is a silly little JavaScript file specifically designed for holding Yep-Nope tests and it actually comes pre-populated with that test for touch to load in HammerJS. HammerJS probably has the coolest website of any little of these .js modules. It's MC Hammer. I don't know why they called it HammerJS because it's a library of awesome touch events but it's HammerJS. And what HammerJS will do is HammerJS is a JavaScript framework independent which means you can use it even if you don't use jQuery. Wave for you to attach just about every touch event you'd want from swipes to holds to double taps. It's awesome and I really love it so I included it. And they'll give you SAS style sheets, default partials, partial layouts, your base partial, all of that. Now what's even better is that everything you just saw, everything you just saw is back end independent which means you can use it for any project regardless of its back end. So with that, go forth, be responsive, I may just SAS you with you. Thank you. Now before I take questions, tomorrow afternoon in I believe the Athens ballroom for three straight ball sessions, I am holding SAS balls. Yes, three straight ball sessions that damn near close to four hours of SAS. We're gonna start with the basics and go all the way through some really advanced stuff. So if your question doesn't get answered in the 10 minutes that I've got left, come there and learn. Please do rate the sessions. All of this stuff is online, snuggug.com slash munic, SNUGUG.com slash munic. All of my slides are up there with links to my sessions so you can rate it. All of these orange words that you've seen throughout my presentation, those are the links. They will take you where you need to go to learn more and to download all this and to generally be awesome. And I have 10 minutes. Questions? No questions? All the way in the back. Funny you should mention that, print isn't really supported. Specifically if we're talking about Google Chrome, the print media type straight isn't supported in Google Chrome. There are a bunch of things that have print shiv that will give you print media query media types or that will allow you to use media types. But yes, all does mean all media types. If you don't like all, change that variable to whatever you'd like. You can change it to screen and it'll all become screen and then you won't have that issue. But it's not necessary that it fucks with print types, that it applies them to print as well. Any other questions? There is a Drupal-based theme using Toolkit, actually. I have a base theme called Aurora, Drupal.org slash project slash aurora, A-U-R-O-R-A. That has a big, giant book of documentation that goes along with it. That will include all the options for Singularity or SUSE as well. That you can build off Singularity or SUSE. Everything's on that project page. It's entirely SaaS-encompass-based. It doesn't provide any CSS and it does some optimizations. I'm using it for all of my base themes. If you would like to too, go ahead. That's what it's there for. But yeah, it'll give you all Toolkit as well. Other questions? Cool, so if you were too shy to actually ask a question in front of the group.