 Good morning, and that hopefully woke you up as much as it woke me up. I'm so excited for Sunday, you guys. So welcome to this talk, which is called that, which is a mouthful, and it was originally shorter than that, and then I had Sam start to talk about singularity, and now it's longer than it was, and now it's ridiculous. So this is kind of how I'm thinking of it right now. So the mic, oh, that's better. So yeah, this is the right way to do RDBD. There's no other way. Questions at the end. So this was probably two years ago at DrupalCon. Somebody was giving a talk about responsive, and posed the question to the audience. So is responsive design hard? Again, I'm trying to shout into the mic now. All right, so it's responsive design hard, and I thought it was kind of a trick question, because people were hesitant. I don't want to seem dumb. So I stood up and said, well, yeah, it's design. So yeah, that's me. And the thing that I want to keep in mind, and this is a talk about technique, but the reason that I wanted to say this now is that all of these techniques, they go to serve the greater good of the design of the project, the experience of the project. So the techniques might be somewhat difficult, but you guys are going to learn something, or you already know it, and you're going to learn something at this session. So 45 minutes from now, you'll know something hopefully that you didn't know. But it's the process of thinking things through and designing. That's always hard. It's always going to be hard. So who are we? I'm Mason Wendell. I'm a senior front-end developer at NBCUniversal. Twitter and most other places I'm coding designer, but because GitHub doesn't make it easy for you to change your handle, I'm Gennari Mason. Do they change that? Soon, I will be the helping coding designer everywhere. Yeah? And actually, if you guys want to find, like, heckle me, I am a coding designer on Twitter, and you can throw me off my game, because I'll be checking it. I'm a co-organizer of Team SAS, along with my friend Sam here, and some very other wonderful smart people. And where I live in Philadelphia, I organize the Philly SAS Meetup and the Philly RDB Team. Good morning. I'm Sam Richard. I am also a senior front-end developer over at NBCUniversal. I am Snuggag on Twitter, GitHub, generally speaking, the Internets. And I'm the co-organizer of Team SAS and the upcoming SAS conference. So if you're interested in SAS, follow Twitter, and you will get... you'll see fun announcements next week. So before we get started, let's get a few things straight. Everyone, hold up your hand if you own a smartphone. Hold up your actual phone. Hold up your actual phone. Awesome. Keep it raised. This is participatory. I do have mine. Lower your phone if and only if. You have the same device, make and model, with the same operating system as your neighbors. That's what I thought. So to get started with this, we will be working on the premise that you are building device agnostic, because if you design for specific devices, you're divisist. But because responsive web design, it's not about current devices and known unknowns. It's about future devices and unknown unknowns. Now I'll sit down. What's the right way to do things if we're not targeting devices specifically? We start with content first. Probably everyone in the room knows who Jeffrey Selman is, and I think he started to talk about this when he was redesigning his blog. But it's something that I've found in my work that it's actually kind of hard to design something, and so you know what it is you're designing. And since we're working on the web, and everything on the web is content, with very rare exception, it's a good idea to know what the content is. So start writing it. Start understanding it. Get a feel for what the flavor of the content is if you don't have the actual words and images. So we do that, and then we design for our most constrained device or system that we can come up with, and that's usually the mobile phone. It might be something new in a few months. But for now we're talking about mobile first, and I'm not going to belabor that point beyond that. We're going to use web standards. We're going to use best practices. We're going to listen to our industry, and we're going to talk to our industry to make sure that we're all moving in a really good direction. I don't know what phones you guys have. I don't know what device I'm going to have soon enough. So we're going to try to anticipate. We're actually not anticipating. We're going to try to just assume that the web is the web, and we're going to meet you there. Like good little folks. So what else do we do? Why are we here in this particular room? Well, we know SAS, and SAS is the key to writing CSS the right way. Because this isn't a beginner course, a beginner session, I want to get set a couple of ground rules. So if you're working with SAS, and you're in here, I'm going to assume you know about variables and nesting. If you don't, please don't go. They're not too hard to pick up, and you pick it up as we talk, but we're not going to go over exactly what's going on there. You've used some mix-ins, kind of the same deal. The things that we're talking about are just mixed-in packages. Hopefully you've tried Compass. Compass is, we're not going to get into the specific functionality of Compass beyond its ability to import extensions, but Compass has a lot of really great features, especially for writing CSS 3. So let's learn some SAS together. We're going to start off without any of the special packages, just some vanilla SAS for writing media queries. And I want to talk about breakpoints and I'm going to... So everyone's probably heard the term breakpoints, and it's probably not too crazy what tweakpoints might be. But I think of it in terms of when you've got large chunks of stuff that you're trying to move and you're reacting to screen dimensions, perhaps. So you've got a layout going from two columns to three columns to six columns to 28 columns, or whatever it's going to be. I would think of those as large changes, big breakpoints. But to try to illustrate the difference between that kind of responsive web design and massaging little details, I think the term tweakpoints makes sense. So there's a reason I don't like writing things this way. And that's the context of what I'm trying to change when I'm writing that. So I've got here two selectors, one for menu and one for subnav, and we're changing some padding when we get to a 500 pixels wide. And what I'm actually trying to do in this example here is change something within the context of either of those selectors. So under the selector of menu, when we get to a thing, I want to do something else. Same thing with subnav. So when I'm writing this, when I'm watching this, I'm watching that padding and the eight other characteristics on the CSS that I'm changing in the real world. And that's all in the context of menu. If that would split up so the menu was 200 lines above the media query for menu, I would have a hard time visualizing that as I'm writing. And so what SAS gives you the ability to do is to nest your media queries inside your selector to put it in the context of that selector. So one level nested from menu is our media query, and that's going to compile out to CSS that looks just like this. And this is a lot easier to write and to visualize than this. Especially when you get into complex selectors and complex media queries. So is it a problem that we're breaking up our media queries into these fine-grained things from a performance perspective? No, it is not. There have been tests done. It's not going to affect the speed at which a browser can interpret the CSS. It's not going to affect your download size by any significant amount, especially if you can't compress your CSS, which we all are, or should be doing, Drupal certainly does that out of the box. So don't be scared to write your media queries in a granular way. It'll make your life a lot easier as an author. So what breakpoint? Sorry. Breakpoint is the outcome of a little bit of frustration I was having writing media queries and that I was writing a lot that looked the same. Again, I had recently written an article on SAS and how you can use SAS to make sense to make media queries run a little bit more efficiently, but I thought that the logic that I had worked into that was a little bit lacking. So I started to play around with assigning breakpoint variables, breakpoint values to variables, and it saved my bacon on that project and actually opened up a lot of cool things. And I showed it to Sam and Sam jumped on and kind of helped out a little bit. Barely committed a project. Still a little patch. So why would I want this? Why do I do this? I started off, like I said, just to kind of put a value to a variable and be able to pass that around. And I'm writing a lot of men with media queries. And so I said, OK, well, how about I just set this one value, the number of the men with media query to a variable? And that's pretty cool. It simplified my little ones, and then I abstracted that a little further in the extension so that I could have that same kind of simplified syntax for complex media queries, because I don't just write men with ones just mostly. And then I found that I was assigning those meaningful names because I can't just call it breakpoint one, two, three, four. That's kind of boring and not helpful. So I got a name based on why I needed a media query. And then this was the unintended consequences. I'm now managing my media queries by their purpose and by their context. So actually, I'll come back to that in a second. So if I've got a media query that I'm writing because my menu at one state is so long and then another state is so long and I want to do something else, then I can have that be assigned to a name as a variable, and I can have other things kind of trickle down from that effect. So if we're going to start using breakpoint, this is where we go. That's on GitHub. And these slides are online. I'll put the link in the last slide so you can go and check all that out. And these links work. So on your command line, this is how you would use any compass extension, by the way, so this is going to go for a lot of things. So gem and solve breakpoint in your command line. Require breakpoint in your compass.rb file, and that's the file where you configure your compass project. There are a lot of other configurations that go in there. And then in your working SAS file, you're going to import breakpoint, and that's going to allow any SAS that you write to use the breakpoint mix. So let's get on to getting started with breakpoint. Just hands up, who knows when to break the movie? It's good. Okay, cool. So less than half. No, that was like 78% of people. That's how I saw it anyway. Point break the movie. 1991 class at Patrick Swayze, Keanu Reeves. Look it up. 100% pure adrenaline. All right, cool. So this is the basic use of breakpoint. That variable at the top, basic 500 pixels. I don't know if you can read the great comments very well on the screen, but that is the breakpoint variable. That's as simple as it gets, and that's what I use most often. So Johnny Utah is a character in point break. And his default color is coffee. He looks like coffee before anything cool happens. And then, once we get to 500 pixels, he's the color of badass. So that's how you use breakpoint, and it just compiles like hopefully you would expect it to. Just makes him in with MediQuery. It's pretty simple. The real benefit there is that we've given it a name. When it gets more complex, that benefit is compounded. But one of the other cool things that we can do is we can start to be a little bit more accessible without any extra effort. If somebody is, for whatever reason, changes the default font size on their phone or on their device, whatever, your pixel-based MediQueries will blow up and be not what you would expect it. If you use M's, and I'm talking about device M's, that's always going to be based on a 16-pixel value, then when they change their font size on their device, on their browser, that value will then be usually what you intend when it actually renders out. So all I did was change that as variable, breakpoint to M's, and set that to be true. And that converted my 500 pixels to 31.25 Ems. And if you think that's easy to calculate in your head, I think you're a very, very smart person. Good for you. It's not for me. I'm very dumb. So I think I've belabored this point. So why, again, is this cool? This is what we had written before. We had those two 500-pixel MediQueries. But what we were doing is reacting to the size of the menu and the size of the menu needed to have you something in 500 pixels. We create breakpoint. We assign a value to the variable. Okay, we just kind of juggled some code around. It didn't change anything for us. But in the real world, things happen. The menu, we get another item. We change the wording. It gets longer. So now we've got a more real-world value there. That's 642 pixel value that I made up. It's a fake real-world value. But we change it in one place, and that affects all of the other places that had to react for that same reason. And most of the time, that actually works. That actually lets us have that same effect when we just needed to change a value for it in one place. We might have had three different reasons for having 500-pixel MediQuerie on our site, but if only the menu changed, we only changed it based on the menu-based MediQuerie. It was nice. Works out. There's our compiled CSS. So like I said, MediQueries aren't the only kind of MediQueries we write. And I wanted to give a shorthand syntax for as many that made sense. And Sam and I started to call these fenced values, because we're fencing in a min and a max, usually width, sometimes height, sometimes other things, value. So by default, we're hinging on width. So if we pass breakpoint to two numbers, like so, that's going to result in a min, max, width, MediQuerie. And there we go. And I've leapt it to shoot up pixels so that we don't have to do any kind of mental gymnastics and get through this faster. But normally I would have breakpoint to m's turned on by default. We can also have explicit tests and values, so max width or anything else, if you send it a string and a number, we get, there we go, max width, 1,000 pixels. And we can combine the tests. Just like in a normal MediQuerie, if you wrap your tests in parentheses, you can hand them out as far as you need to go. So this, probably predictably at this point, is going to be max width, 1,000 pixels, and orientation portrait. And orientation portrait is two strings, so we handle two strings as well. And actually we have a little bit of error correction in there too, so if you'd written in portrait orientation, it would still turn that around for you. And so there we go. Max width, orientation portrait. And we can combine lots of this. We can just go down the line. These would all be handed together. And if you had a comma in there, we can create an OR-based MediQuerie. We've built in support for, I think, every conceivable MediQuerie you might want to write. It's a bit comically robust at this point. And there we go. Min width, min height, max height, orientation. It's pretty nice. And those are kind of the most basic uses. That's my day-to-day. The little hand does say it's time to rock and roll. Chalk full of wisdom is quoted here. So the other thing that really makes this stand out from writing MediQueries yourself or anything else I've seen for writing MediQueries is we've got support for fallbacks for when a browser doesn't support MediQueries at all or doesn't support the feature that you're working with. So what I'm illustrating here is something that's really, really future-friendly because, Sam, you would know, correct me if I'm wrong, there's no browser that supports this at all. Correct. Yeah. So this is CSS level 4 MediQuerie selector stuff. And just because this is exciting, I'm going to say what this is. So we've got breakpoint no query fallbacks to true. That means it's going to print out our fallbacks. But then that touch variable is our breakpoint variable for this example. And we're testing on the pointer test, and we're testing to see if it's coarse. And there's two values that you can test on for pointer. And, like we said, this isn't supported anywhere yet, but it's the standard and it's going to be. So we can test for fine pointers and for coarse pointers. Fine pointers are going to be mice. Mice with little tiny one-pixel endpoints that are very fine. Cores pointers are fingers or something else that might be coarse. So that will give us a CSS native way to test whether we're working with a touch device or a kind of mousey point mousey device. What would that be? There's no name for it. Mousey device, yeah. Good. You're welcome, everybody. So what we've got here is a test that is going to test for something that doesn't exist yet, but we do want to have a fallback. So after the comma, we've got two strings, one for no query and one that's called dot touch. No query is a flag that says next thing is going to be this selector that we're going to spit out for our no query support. So let's click through to see the compile and have this kind of go to the fall into place. What happened was we rendered out the value for free fall before anything happened. And then our media query for pointer course and then we've got our color badass for that. And then finally, we've got our no query fallback or our fallback for when that's not supported, dot touch, hash free fall, color badass. And we can use modernizer, let's say tool like modernizer, or we can use modernizer for testing whether or not a device supports touch and to add that touch class to our HTML element. And then right now we're supporting it and in the future when the browser does support it, we don't need that modernizer anymore. We also support calculating resolutions and if you've ever actually hands up, who's written the resolution based media query? Yeah, and it was kind of crazy, right? Like there's a lot that goes into it or at least there was when I looked into it. So there's a lot of different ways that you can write it. So you've got dpi, dpbx, and the standard is dpbx, which is dots per pixel. But it's not supported anywhere yet. Is that right, Tim? He doesn't. She doesn't help? Yes, it does. Cool. I said she. I think Firefox is the correct name. She's pretty. It's okay. It's supported in one place and it will be supported elsewhere. But you don't want to have to write comma separated resolution media queries by hand. So we took that over and if you input dpbx, it will calculate your device pixel ratio, which is vendor prefixed, and it will compute the resolution for you. And if you give it resolution, it'll put out the device pixel ratio for you as well. So it's just a nice, easy way to start to think in dpbx and let somebody else do the hard work for you and have that come out in a nice way. And what I'm not showing is how this can compound the complexity if you've got other tests inside of that. So if you're testing for resolution and min width or and height or and monochrome, all of that comma separation will work. Breakpoint sets out what you need, but it's really hard to manage if you're doing it on your own. So there is a few things that I've not mentioned, but there's one crazy advanced use that I promise you, well I promise you, you guys are awesome and smart. But I don't have very many uses for it, except for when we're writing other projects that would like to know about where we are in a midi query. So we've got breakpoint context. And that is a function that you can call in a mixin that will spit out what the value of a breakpoint of a midi query is for a given test. So up at the top, we've got a breakpoint that's going to be min with 500 pixels and a max height of 600 and 800 with an orientation landscape. And then as we go down, three occurrences of breakpoint get context. The first is checking for min height, the second for orientation, and a third for max width. And the third is a trick question. Because as we see, it spits out correct values for all three, but just the third is false. So we can write a mixin that is aware of the context in which it's being called, and create really awesome things like Singularity. And so I wanted to hand this over to Sam because he's been doing the lead dev on Singularity really. Thank you, mixin. So Singularity. Singularity is a grid system. Using Singularity is pretty easy. github.com, team-safs, that's Singularity. That's where you're going to find it. Gem install Singularity GS for grid system. Require Singularity GS. And import Singularity GS. Now, let's talk about grids a little bit, super quick. Who here uses grids? Raise your hand. Who here uses Twitter Bootstrap Reserve Foundation? All of you leave, please. No. Talk again. I can't be off the talk. I'm doing the grids talk. I'm going to push you up. Don't insult me. These are nice people. Okay, very nice. So let's take a look at some grids for city layouts because grids happen to work well if we're looking at both design for print and design for cities. And we're going to go kind of counterish on making it up. Let's look at Toronto first because Toronto is really bad. If you take a look at Toronto's map, you'll see that it really doesn't have a grid system. And because of that, if you were to be plopped down in Toronto, you would kind of need to memorize all of the streets to figure out where you need to go. Something I have found is somewhat similar to here in Portland. Sorry. And it's kind of a pain in the ass to get around. DC, on the other hand, has a little bit of a grid system. But it was a grid system that's a very generic grid system. It's squares. And because it's squares, it's hard to visualize exactly where you are at any given point. To me, DC is kind of like the grids that you get with Twitter Bootstrap Reserve Foundation. They're generic grids that same with 9.6 to really any of that. They're generic grids designed for generic uses, but don't provide the type of complex depth that you need in order to have a grid truly work and be super great for your users. Let me go to Philly, where Philly has a unique grid system. But Philly didn't quite stick to their grid. So while you can generally figure out where you are, there are times, little side streets where you're just not going to know where you go. So sticking to a grid is important because otherwise people will get lost trying to find your house. And then finally, we come to you. I was going to say Ben Franklin. That's where it happened. I don't think they can hear you because you don't have a mic. Ben Franklin found his way around Philly. Oh, he lost his 11 in mind. Thank you. That's how you hear him Philly. And then finally, we've got New York. And now New York is interesting. New York not only was able to rigidly stick to their grid system, but they built a grid that was unique to the layout and landscape of New York. Unique to the content of New York, if you will. And because of that, it's very, very easy, just even from looking at the map of New York, to be able to visualize where you are, where you need to go and how to get there. If you're dropped into New York and just described with a grid super quick, you'll pretty much be able to get around. Now, why do we use grids in web design? Because grids provide order for your design, order for your design instruction for your information. And the best grids are specific to both your content and your design because they are extensions of both your content and your design. The singularity is built with these ideas in mind and these ideals in mind. And because of that, it provides lots and lots of power for you. But before we go anywhere, let's take a look at the box model because the box model is kind of terrible. So everyone, the right box model, content box, that looks familiar? Yes, that is the CSS3 standard box model. Box model on the right, border box. Who here hates Internet Explorer for changing the box model and means to do IE hacks for that? Yes, everyone does because we're all front-end developers and Internet Explorer is terrible. Well, it turns out they got this right. So if we take a look at the description for box model, that yellow bar dividing everything, that is a fixed height or fixed width. And in the content box box model, padding widths and border widths go on the outside and border box box model, paddings and borders go on the inside in both margins down the outside. So what that means is if we were to use content box and I asked you to tell me the width of something that is 25% wide with 20 pixel paddings and .2M borders, what would that width be? Laugh is what that width would be. With border box, that would be 25%. And that makes it possible for us to use fluid grids. And that makes it possible for us to be able to use a grid system in our responsive designs, let them be fluid and not have them be static adaptive grids. So let's cheat a little bit at CSS. Import compass will give us all of compass's mix-ins. And then we're going to use the star selector, star before and star after to include box sizing, border box on everything. Now, I know someone's going to yell at me for using the star selector. It turns out that the star selector on its own is just as performance as any single tag selector. So in this case, it's totally cool. And this will change all of our box models to border box, which means we can use a natural box model for everything. And that makes us happy campers. So let's get started talking about grid singularity. Singularity provides two different types of grids, allows you to write two different types of grids, symmetric grids and asymmetric grids. Symmetric grids are what you're used to in things like foundation and bootstrap in 960. They are grids where every column is the same width. So in this example, all of our columns have a width of one, and we have 12 columns, 12 equal sized columns. Gutters, gutters are the places that go in between, that's our margin, that's fluid as well, and that is a ratio of gutter width to a column of width one. So because all of our grids are width one, our gutter width is one-third, and one gutter will be one-third of each column. And that looks something like this. This is actually the column layout of the 960 grid. If you're familiar with 960, 60 pixel-wide columns, 20 pixel-wide gutters, gutters one-third of a column. Asymmetric grids are a little bit different. And asymmetric grids are really where the power of singularity comes in and where you can start to build grids specific to your content and design. So we're all familiar with the holy grail layout, the tryptic layout for web design. It's a sidebar on the left content in the middle and a sidebar on the right. Now while you may have heard me say sidebars are false constructs and they are, what we can do is we can set up a grid that actually looks like the design we're trying to build, so we don't need to remember how many columns we can expand for each different piece. And we can do that using an asymmetric grid. So this grid example, we have three columns. We have a column of width two, a column of width eight, and a column of width two. Gutters are still one-third, but the thing to remember here is this gutter is, again, still one-third of a column of width one. And we have our first column is width two. So this will actually be one-sixth of the width of our first column. I know that kind of seems strange, but if you take a look at what that looks like, it kind of makes sense. It kind of resembles what you would expect if you had built actual divs on top of a 12-column grid. Now, singularity, you don't need to use a 12-column grid. You can literally use anything you like. We're just using this as a good example because people are generally familiar with a 12-column grid, but really you can use anything you want. So that grid starts to actually look like that magical, triptych, holy grail layout that we all really love, or our product owners really love. And we can do it with just three columns instead of all the 12 and remembering a lot more stuff. Singularity is what's called a semantic grid system. Now, that's not to say it's semantic because its classes are really well-named. What that actually means is it doesn't provide classes at all. And what you wind up doing is you wind up applying the grid spans, applying the grid itself directly to the elements that you want on the grid. That means that it becomes easier to see how grids change, and we can use nesting and media queries and breakpoint to see how our different widgets change as we want them instead of needing to rely on looking at the HTML and injecting classes everywhere, which we know is super easy and fun to do in Drupal. We can do it straight through all over CSS. So let's talk about spanning the grid. This is the example HTML we're going to be using for this. We've got class of main, class of first, class of second. We are going to do the triptych, because I like the triptych. We're going to do add, include, grid span, 1, 1, 1, 2, and 1, 3. What does that say? That says I want to span one column starting at the first column. So it will be using the two. I want to span one column starting at the second column, and I want to span one column starting at the third column. That makes using this grid a lot easier than the alternative, which would be span 2, 1, span 8, 3, and span 2, 10, which is a little bit harder to remember than 1, 2, 3. And that's what it winds up looking like. It looks exactly like we would think it would look like. The light, stamina, color is our visualization of our grid. The red is the actual place of pieces of work. Yes, and we'll go back, but all of this code is in our slides online afterwards. So the point of the code isn't for you to be able to copy the code down now. It's for you to be able to get inspired to go look at our slides later. Cool? Awesome. And this is going to get a little bit long because we have got big code examples, but we can also do responsive grid contexts. So if you're used to having three or four big grid layouts, big breakpoints for grids, we can do that with Singularity as well. So we're going to start with a 12 column grid. This is building mobile first. And we're going to add the 282 grid at 700 pixels value I made up. So first, we're going to span 3, 4. Then we're going to span 1, 1. Then we're going to span 6, 7. And then 1, 2, and so on. And what you wind up seeing, it's easier to visualize, is you wind up getting something that looks like this. Start with a 12 column grid. Second section is to the left, then first, then middle. And then we switch to our triptych grid. And not only do we get a new grid, but things move around as well. We're able to move around because we're using what's called the isolation output style. And that gives you essentially pulling and pushing that you'd be used to with a traditional grid system baked into how you want to position the grid items, which is super useful for doing stuff like this, what's called content choreography. Again, just look at where the second section lives. Second section is the first item. And then when we switch, yay, it goes all the way over there. So we're not changing our HTML, but because we're using an intelligent grid system, we are able to change the visual ordering without changing our source order. Middle section is still the middle side second. It goes to the front and then it goes back. It's all topsy-turvy, wibbly, wobbly, and fun. We can also nest grids. So this is the HTML we're going to be using. Just bear with the HTML. The pictures are pretty, and that's really what matters is to get the visualization. So grid span 1, 1, 1, 2, 1, 3. And we get that grid that we saw before. Then we can use the layout mixing. Layout mixing and singularity is super useful. What it says is that grids and that gutter variables, those are global contexts. That allows us to know where we are and not need to pass in our grid definitions every single time to grid span to specifically tell grid span where we are. What layout will do is layout's a chunk that we can say, for this chunk of code, I want you to use something different. In this case, I want you to use an 8 column grid instead of the 282 grid because we're in the context of 8. And then we can do grid span 1, grid span 1, 8, grid span 6, 2, 2, 4. And we wind up getting something that looks like this. So we now have put a new grid inside of the middle piece. This is something important with singularity that distinguishes it from other grid systems. Has anyone used SUSE grid system? S-U-S-Y. So for those of you who are familiar with something like 960, all of those grid systems work based on the thought that your container is something fixed, even if it's fluidly fixed, and that your grid are pieces of that predefined container. So for 960, each column is 60 pixels plus the 20 pixels plus the 10 on the side. That lines up to 960. It's based on the container. Singularity, on the other hand, works off of the thought that there is no container. The container is whatever you put it in. Because at the end of the day, all a grid is is a ratio of a whole. And that is the only assumption singularity makes about your grids is that what you want is a ratio of 100%. So what we've done here is we have not only changed our grid context, we have changed the physical type of grid. We have changed from an asymmetrical grid to a symmetrical grid. And we're able to do this and do this on the fly because singularity doesn't make that assumption about your container. So what we wind up having is grids inside that line up to the gutters on the outside, but do it because we've chosen to do it. And then, of course, we can nest even further down. Layout 6, 6 column grid. And we wind up getting something that looks like this. And I think that is what we have. Cool. So thank you guys very much. Thank you. Looks like we have a little bit of time for questions if anybody wants to. There's a mic in the center. Yes, come ask us questions. We have microphones. Hi, guys. Hi. So I'm curious, is there a way to make one of those grids sides fixed, for example, if you have a 3 column grid layout to make the third knot flex? So singularity offers this thing called output styles, which allows you to define basically how the CSS gets written. It comes with two different output styles, float and isolation. The way that you would need to do that is through display table. And if you would like to, you can write your own output style to work with display table. It does not come with an output style for that, but if you have one, you are free to write it and use the same singularity syntax on top of it. Cool. It looks like you guys are using the Omega sub theme. No. Okay, it's 960. No. Do you have a preferred theme that you'd like to go with? Or is it theme agnostic? The great thing about working with SAS is that, for me anyway, is that it's really theme agnostic, droop agnostic, platform agnostic. It works with any web system that we're going to throw it into. It's just authoring CSS, and the same goes for Breakpoint or Singularity or any of these SAS-based tools. So you don't have a preferred theme? No, we have a preferred theme. Can you share with us? My preferred theme is Aurora, but I'm a little bit biased because I wrote it. But that being said, I prefer Aurora because it's built from the ground up to use these tools and is super minimalist. It doesn't give you anything out of the box. In fact, it strips away a lot of the default settings that triple themes have. But it is built out of the box to support these tools. It is not a good theme for people who are brand new to theming or if you're really used to Omega-3, it is kind of the empty Omega-3 base theme. But these tools that we use just because Aurora is optimized to use them doesn't mean you can't use them because you don't want to use them. Okay, and just a follow-up question. Do you guys have a working example that you've done at NBC where you've taken all of your SAS and you've got the default breakpoints and you can kind of gut it so that we can kind of work off something rather than us trying to figure it out from scratch? No, because there are no default breakpoints. There's not... It's totally dependent on the needs of the content so we don't look at, say, the iPhone, iPad, desktop models and say, okay, we're gonna set these as breakpoints and then move from there. We look at the content and then to paraphrase Stephen Hay, you start small and you expand your browser until the content looks like shit, then you made a breakpoint. And so you just do that over and over until it looks good. Okay, thanks. So it's pretty easy to pick on the foundation's grid system, I think. So all the good things in foundation is very old-fashioned. But you didn't mention Susie and it looks to me like Susie pretty much does everything you're doing. You don't have the explicit asymmetric grid but you just, you know, crimp some bars and pass those through. Instead of, I remember, okay, this is a 2, this is an 8, this is a 2, but if I wanted nice inside that 2, you still have to remember that 2 is an 8. So what can you do in a single area that you can't do in Susie or, say, the upcoming Susie Next? Yeah. And a lot of the original core underlying features of Susie Next are based on this version of Singularity. That being said, Susie Next is significantly in flux right now, so I don't know how it's going to wind up panning out and if it's going to wind up being nearly as flexible as Singularity. As for the current version of Susie, Susie just simply isn't anywhere near as flexible as Singularity, and it makes the assumption that your grids are based on your container. That's the setting your columns to a width, four m's I believe is the default, and your gutters to a width, one m is the default. That makes, that puts you into the mental model and that it makes the assumptions that what you are doing is you're basing a grid based off of a desktop size. Susie is really a desktop first grid system that might happen to write its CSS mobile first. Singularity, on the other hand, is built and designed to be mobile first and designed to take advantage of preprocessing. It is a truly preprocessor first grid system where Susie is kind of an old fashioned grid system turned into a CSS preprocessor. One thing that you can do with Singularity, one really very specific example, is that you can do ratio based grids that don't have a common column denominator, like something based on a golden ratio or something like that. You can actually have that be true to the golden ratio. If that floats your boat of designer or not, that's up to there, but that's just not possible with an equilateral grid system. Have you checked out Salsa? Have you checked out Salsa? I have. Yes, I've checked out Salsa. He's actually part of Susie's next team. Again, all of the CSS preprocessed, all of the grid systems, of all of the grid systems none are quite nearly as flexible as Singularity, and they all work on a similar mental model of your final container, where Singularity is very different in that it totally ignores your container because it has no concept of your container, making it in the end a much more flexible system. All right, I'll give somebody else a chance. Thank you very much. I love SAS. Stoked about breakpoint. It's all great. Singularity is awesome, I think. My question is, why if the elements have their own grid, if I understand correctly, is there a background grid just for gutters, grid span, snap grid, or is there something else amazing? So that background grid was just a visualization of your grid. It is not an actual grid. Truth be told, base grids, I don't necessarily use them on all projects, but having a grid system is good for the widgets that you're working with. As for why have a background grid when you can just kind of make one as you switch, that is a very good question. The answer is you might find out when you have a flexible grid system like Singularity that you don't need one. And that that may be a construct of page printing web design. It depends on your project and your needs. All right, thank you very much. Hi, this is a question about breakpoint. It seems like a very monolithic approach to cram everything into a single mixing. I'm just wondering if you considered splitting it into more than one for maybe better readability or is you decided to go with the way for the reasons? I don't really feel like it is that monolithic approach. And if I were to do it to break it apart, I'm not sure exactly how I might approach that. As an example, on our current project, I believe this is based on some of the work you've done. We have a mix in this called If, Min, Width. Include If, Min, Width, 416. It reads like English, it's great. So actually, yeah, so inside of breakpoint, we've also included the respond to syntax which is an older project that has since been rolled into singularity. And what you wind up doing is instead of defining variables, instead of defining media queries using variables, you define them using strings. So the semantics that you wind up having are something like, I'd include something called inline navigation. But that being said, to your question of breakpoint's monolithicism is a word I'm going to make up right now. Breakpoint is designed as, it's designed as a system that you can use out of the box, but it also works as an API. So one of our users has created something called breakpoint slice, which is a syntax on top of breakpoint that provides some syntactical information that he really likes that at the end of the day calls breakpoint. So your if-min-with media query or mix-in, what that can do is you can have that mix-in and then in that mix-in call breakpoint. So breakpoint kind of becomes a media query API at that point. You might use it for the convert to M's or the other things. I just want to say, I think our work was actually based on that respond to stuff that you guys did. So thanks for the transform, how we did things. Can singularity do a fixed-with gutters or is it always ratios? Fixed-with gutters are a function of padding. And what we have found out as we have worked with grid systems and grid frameworks is that padding is really hard to keep track of and it compounds very, very quickly. So we did not include a fixed gutter output style in singularity but like the question of fixed sidebars and fluid stuff for an output style, if you would like to make one, you are free to make one. And we encourage if you want to use fixed gutters for you to make one yourself so that the mental model works the way that you expect that to work. But it's doable with output styles or with different output styles. We just haven't built one. And if you were one of the proponents of competing grid systems, what would you tell me the downfall of singularity is? And as a maintainer of singularity how would you dispute that? The biggest thing with singularity which is the biggest problem with singularity is it's a very large mental model shift from other grid systems. Other grid systems really take the concept of a page to heart whereas singularity totally destroys the concept of a page. And it's grids for grids. So the biggest issue I found when explaining singularity is that you're not making grids. You are building ratios that wind up writing out something that resembles a grid. And it's a tough problem for us as for me as a maintainer because it's hard to explain to someone and I've actually given trainings on this this week where someone understands what singularity is doing and then the mental block between I understand what you're doing but it's also not what I think it is. That's really somewhat hard to get over sometimes but I don't know how to fix that in singularity because that's the core system. That's singularity's secret sauce is that it's not a page but it's a grid system. It is a web-based grid system. So that's probably the worst thing with singularity is it's a totally new mental model. Okay. I've been using SAS. Got a couple of SAS responsive sites on my belt. Three or four I've been using the respond to which I like being able to put the response right in that same selector. But I got to a site where it broke down as a front page that had JavaScript changing things on the fly and so I found that in order for everything to line up both horizontally and vertically as the screen width is changing devices are changing compounded with the fact that the content was being replaced and the height of things were changing with JavaScript. I had to revert to basically kind of styling JavaScript having it measure widths and heights and apply CSS that way. So I guess my question is did I not try hard enough or is having the DOM changed out from under you a legitimate reason to do it that way? So it's hard for me to say because I haven't seen your project. I would definitely try to avoid writing actual CSS styling with JavaScript. I would try very hard. That said, maybe it was just so complicated the thing you couldn't get around it with adding classes or reacting in some other way. But yeah, I would do that as a last resort. Yeah, certainly. I agree. Generally speaking, I find I try very, very hard not to ever do any styling through JavaScript and instead apply classes and respond to specifically won't help with that because all that you can respond to in Breakpoint does are media queries. So if you're having issues with your other CSS, I'm not sure I don't think Breakpoint or Respond to would have ever been the solution that you were needed to deal with. Because you can't respond to the DOM trade. It's not a real time, it's just not about CSS. So I think what you should be trying to do is applying classes and see if you can fix your problems using CSS or potentially creating more predictable patterns. And then that will produce that will allow you to write better CSS. I mean, my only pushback is just that a class cannot replace measuring a width and then applying a margin or width value based on a percentage of that width. The class could never do that. Right, so I mean if what you're saying is there are some things that you need to do in JavaScript that CSS can't, then yes, that's true and I don't know how to fix that in CSS. All right, Gawd, I completely agree. It sounds like you did your due diligence. Thank you. Hey guys, I'm mostly back and my team is mostly back in. More and more projects are requiring more fun in work and so have started using Compass and SAS and so on, but totally new to Singularity and Breakpoint. So I'm a beginner that came to an intermediate session. This is really exciting, looks like some awesome stuff to do, but you went so fast and you're like, do you have... I mean, I can obviously search for resources, but you guys are experienced and know what's good. Does anything pop out as a really good place to go from here to continue to learn? If you're new to SAS, there's a blog that I contributed to about a year ago that still has really great content. What's there is fairly evergreen called The SAS White and I think that the maintainer is going to start that up again if he does. And there are a lot of resources on SAS now. I can't think of another one that's, you know, that targeted, but a good Google search for any particular issue you're having would... So just generic searches and stuff. What particular... Anything particular that you wanted to do that to, or just SAS in general? The two gems that you mentioned in particular. Both of them are. Just the documentation. Yeah. They're very well documented because I refused to launch them with that good documentation. Okay, thanks. Hello. I was wondering if you have used intent.js which is, I think, a tool to help you do element queries. So it's like a media query that responds to the size of an element and just wonder about that and that style of doing things. And if Singularity can kind of help you do that because you have sort of a contextual sizing or styling. So I'm aware of it, but I haven't used the... Yeah, so as for Singularity, it isn't going to help with element styles, element queries. It might help you to write better grids for when you do have an element query, but it won't help specifically with element queries. As for element queries itself and generally speaking, there's something that are very, very hard. I've written in element queries to a responsive image solution I have and... or what essentially amount to element queries. And one of the big issues with element queries is lots and lots of elements don't get sizes until you've put something into them and if you're trying to query what their size is before the content is in there that it requires to know what size it is, you get this kind of chicken and egg and that is the perpetual issue with element queries besides the fact that they can't actually happen natively in HTML or in browser. So you can use them if you would like. I would, as much as I hate to say don't because they're super useful, don't. They're not reliable. Right? Just I try to do pretty much as much as I can in the standard tools so HTML, CSS and what I have available there. Thanks. So please don't laugh and this isn't for me, it's for a friend, seriously. But Singularity and .dat Is there... Do you know of anything... So these tools are back-end agnostic so as long as your front-end developer is able to work in a real person environment or really if they're able to install Ruby on their site, which is Ruby installer or on their local machine, rubyinstaller.org then they'll be able to use SAS and compile. So as long as they're able to compile SAS and use Compass they'll be able to use Singularity and Breakpoint. The output of either of these is just CSS that's what SAS gives you. It gives you an authoring environment for running CSS. So as long as you can find some I found some tools about .NET and SAS so as long as you can find that then the rest is pretty much just what it is. The other thing is the way that we work in Drupal is we don't use Drupal to compile our SAS. We compile our SAS through our Ruby stuff. So maybe the search you should be looking for isn't necessarily how to integrate .NET with SAS but rather how to author SAS on the operating system environment that you're doing your local dev on. With SAS I've noticed that inside of media queries it's a lot harder to use the mixin. I've had troubles with mixins and other ones because... Extendables. Extends, yeah. Since you're putting media queries in the code in multiple places in the context of what you're doing how do you work with those kind of things? I don't think that there is any technical constraint on mixins but there certainly is with extendables. Okay, maybe it's just this. So the rule on extendables is you can't extend a selector inside of media query. From outside of media query. So if you define your extendable outside of media query you can't extend it within one. Inside of media query, then you can extend it. I think that's confusing but that's why I think it's land. So I try to avoid that. So I might have a duplicate definition of my extendable where I define it as a mixin first then apply it to an silent extendable class. Then I can extend it when I'm not inside of media query if it's just the way it works. Excellent. To chime in on that I saw a talk yesterday where we were using placeholders so the percents so if you put all your extents as placeholders and include them in a partial file the way you're bubbling media queries is to become a pain in the ass but if you have like here's my big chunk of my big breakpoint thing and then you have your little pain points like my menu needs to breathe but if you have like breakpoint you could have, yeah you can include a partial with all your place holders at every big breakpoint and then reference those from within that media query. It just depends on the problem you're solving for the project. Yeah, if you've got a large layout and you somehow need to extend that, that could work. I think though that that's probably not something you're going to extend very often because it's usually something you define once and use once rather than need to verify greatly. Most of the time when I use placeholder selectors, they are for things that will not be changing depending upon media queries. So I don't use selectors for grids for example, but I'll use placeholder selector for font definitions and for colors and for basic padding and stuff like that. Style guide type things and style guide type things tend not to change very much based on media queries and the changes are tweaks that you would need to not use placeholder selectors for anyway. I can see theoretically like you say you have like a menu style, lots of menus, might have like a placeholder for that that you can pull into mobile or something, but then you don't use that there anyways. The other thing you can do is you can use media queries inside of placeholder selectors that get extended and that kind of solves that issue. Okay. Yeah, so if you've got a drop down that you've created that needs to look differently at different sizes, you could put the media query inside that and then that would work for that specific widget that you're styling. Yeah, cool. This is more of a philosophical question and maybe not a lot useful, but it seems like the biggest assumption of singularity is that elements are self-similar or fractal. And I was wondering whether you went out of your way to create kind of a complexity theory approach singularity. I'm not sure I entirely understand the question. Sounds deep though. It does sound deep. Well, just the idea that your elements aren't based like on a page paradigm, for example, in that you can nest elements inside elements inside elements and have similar properties, no matter where you place them in this hierarchy. So nesting is not like the central philosophy singularity was built on. Nesting is a byproduct of singularity's non-page assumption. So we didn't go from the let's be able to do the most intricate thing out. We went from let's just not assume a static page and in from there. In fact, the layout mixing that I showed was one of the last things we added to singularity before it actually launched. So I don't think, I think the answer to your question is no, we didn't do that. I was wondering about the breakpoints module and is it just an API so that James can hook into it. The breakpoints module is a terrible piece of shit. Okay, that's kind of what I thought, but I was going to ask it as a nice one. And also the picture module, is that another sort of using the same concepts but in a module form so you can download it. So to me, the big issue with both picture module and breakpoint module is they're both, especially how they're in points in Drupal core, which are both Drupal modules and not SAS things. Right, yes. Is that they are both, they're both designed and predicated on the assumption that your site will have four breakpoints or basically device breakpoints and those device breakpoints probably are on our iPhone, iPad and desktop. And that is just the wrong assumption to make. When we build responsive websites, we use 20, 30, 40 breakpoints. And the assumption that A, all those breakpoints belong in an API that can then be referenced by other things and B, that those breakpoints are things that would be useful even if we put them in is a bit silly in my opinion. It's not just silly, it's short-sighted. It was, both of those were really designed for a very specific use case and that very specific use case is wrong. Not that it's wrong, but it doesn't follow best practices. And in fact, the practices it follows haven't been the best practices for years now. Well, it doesn't hold up when you look at it past the month or so when it was conceived. A while ago, it made sense that we only had iPhones and desktops and iPhones and iPads and desktops. And it seemed like we were in that world, but we're not. We're just not in that world. So having something where you've got a system for managing these device breakpoints is just going, it already has fallen apart. It's going to fall apart when you use it. So try to be device agnostic, future-friendly, some of the earlier content should look at a device of the given characteristics, which device that is. Push back on picture a little bit. And all of those IMG is going to be wrapped in like a width 100% in CSIs. So if you have a limited amount of breakpoints, you're still serving a smaller asset at that size, which can be beneficial. I'm not saying that responsive images are a bad idea. I am saying the implementation of the Drupal module picture and the Drupal module breakpoint is poorly done. I agree that we need responsive images. I don't believe that the picture element with the breakpoint module, the picture module and the breakpoint module are the correct solution for that. But it's still. But not as good as Borealis, for instance. I did, did not. So given that, how do you then create resize images within Drupal specifically for the organic breakpoints you're talking about? So I have created a module called Borealis, Borealis Responsive Images. It uses element-based media queries, which means it will work for about 80% of what you want, but it won't work for the instances where something needs to be sized based on the inline content inside of it, generally like flex sliders and stuff like that. But for the 80% of use cases where that does work, it uses element queries and it does it all behind the scenes and you don't need to choose what different styles you say. I want this style to be responsive and then just use that image style and you'll get Borealis and you'll get responsive images based on element queries, which means you can use the same image style multiple places on your site and have those images be at different points. That is my preferred solution to responsive images in Drupal because it's a million and a half times more user for all technically pictures user friendliness is zero, so I think it's infinitely more user friendly than picture element. I know, I should be nice. But it's much more user friendly and it works off of element queries instead of device break points. For the 20% of the time that it doesn't work, then you need to use a picture fills up a different solution that is based on Viewport. Picture fill is one of them. It is not the only one. And are we using it through the module or are we just actually doing it? We're using the library but not the module. What we tend to do is we don't use modules for JavaScript libraries. We use the JavaScript libraries because we have much more control over them. Another similar example is we don't use the Flexlider module. We use Flexlider, the script because we have more control over it and it's actually easier to work with. The other thing with responsive images is right now every single thing is a hack because there is no standard. So saying picture is the end all and be all solution because it might get in even though Chrome refuses to add it to Chrome at the moment. Picture favorite hack. Picture has its place, so it is Borealis. Picture module I don't believe is the correct solution. That doesn't mean picture fill isn't a good solution, but I don't believe picture module is a good solution. That was useful. I'll take a look at Borealis. Cool. Is that it? We've kind of gone over our time, but we'll have to answer more questions. We'll stand here forever. Forever and ever and ever and ever. Thank you, guys. Thanks, guys. We'll go this way. The SAS way, sas-lang.com. Yeah, that's the official site. And it's got the basics and tech stuff. Compass-file.org is the Compass website and that has usage for all of its mixins. My blog has stuff. Mason's blog, if you don't have stuff, you should have stuff. I took off stuff when I tried to redesign one. Yeah. The SAS way has covered the best articles to grab a bunch of it together. You're welcome. You guys have... Okay, so you'll wait. We'll see something specific. I don't use sidebars, or it doesn't come with sidebar regions.