Don't Use My Grid System (or any others)
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Suzanne, Miriam
I built Susy, a Sass grid system that can generate any grid technique you like — but I haven’t used it in years. I’ll show you how various grid systems work, and how to avoid using them. For those few cases where a grid really is required, we’ll talk about the best ways to roll your own, so you’re not relying on a bloated library to make decisions for you. We’ll also look at the new layout toys, from flexbox to CSS Grid, and how to get started with only a few lines of code. When to use floats, CSS Grid, flexbox, custom properties, and other techniques. How to make grid-math simple, and lose the grid-system. How to make existing grid-systems work for you, when you’re stuck with them.
 So, don't use my grid system. Any questions? I, uh, what? That's the end of the talk. How did we get there? Yeah, we went too far. All right. Let's start at the beginning. The beginning is roughly there. I don't do Django. I have no idea what you all are talking about. It's a lot of fun being here anyway. There's some fun talks even if I don't know what you're saying. And then a few that, you know, accessibility. I do that. I'm like, yeah, I belong here. So, I'll establish some creds so you know why I am here. I found it odd bird with my brothers. This is, I think, our first planning meeting. Ignore the magic the gathering cards. You might recognize the middle one. He's usually here. I thought it would be fun to come do a talk with my brother. And then he ditched out. So, sorry. So, that's Carl Meyer if you don't know. So, this is our team now. We've grown up a little bit since whatever that was, 94 or something. We've got a team of seven. We're a small agency doing consulting work. And I do a lot of the user experience design and project management and front end design implementation and writing all sorts of tools for developers, us and open source community including which helps you manage abstract patterns and code like colors, fonts. They're not physical patterns like your buttons. That's sort of more abstract patterns that exist in a design system. So, looks something like this. You don't care. I don't care either. Herman helps you automate pattern libraries. Great. Fun. And then Susie which ended up being the big one. And it's, I don't know why, it's just another grid system. And I stopped using it right around the time it became really popular but I still maintain it. And that's a lot of fun. So, to go back a ways, blue, blue. The history of web layout and why we have grid systems and why you don't need them anymore. So that starts with UGG tables. Remember these? I used a pixelated image because it felt right. Like, oh, that's so ugly. And the markups all out of, oh yeah. Why do we do this to ourselves? I stole that from a talk this morning. Silly dev. Tables are for data. We know that. And you know, but at the time it was the only way we had to lay out a page. That was before we even had the basics of CSS. So, tables were what we had and we made do. But you've got really limited styling. There's a lot you can't do with a table. So you're really constricted there. The markup is really strict and it's ordered right for data. It's not ordered right for content. So you're always going left to right, left to right, left to right. And that doesn't always make sense. So it's an accessibility nightmare. And we know that that's bad because we weren't to the accessibility talk. Code is communication for this lots of places. I think it's really true. What we're trying to do is write something that is readable to both other people and to a machine. And if we succeed at both, we've written good code. So table layouts break all of that. They destroy meaning for everybody. They're not meaningful to the computer. They're not meaningful to me. When I read the markup, they're just not meaningful. Great. Chapter two, CSS is awesome. So that's the end of the talk. Any questions there? You've all seen this, I'm sure. And I just want to remind you that this is not a bug. This is a feature. And I mean that. This is what happens when you are too explicit about too many things on the web. This is also what happens when you don't specify your overflow. So CSS here is allowing you to make lots of decisions, even bad decisions. And this is you making some bad decisions and you're welcome to do that. And it can be fun. That's okay. That's not a problem with the language. A thing to remember with CSS is that it's easy to be fooled by the declarative syntax into thinking that it's a static language. That you put something in and you get a result and that's it. And that's not how the web works. With CSS, you're really putting in rules for how something is going to change across different browsers, across different platforms, across different device sizes, window sizes, all sorts of different changes that can come at you. And CSS is a set of rules and suggestions for how you might lay that out. So you're really wanting to define dynamic relationships between objects in a way that doesn't couple them too tightly. This is, you know, like programming. And you're designed for what happens if the content changes, gets really long, gets really short, what happens if the viewport changes, what happens if the context changes. We take this widget and we put it somewhere else and it has more or less space. And the client has control over what the final look is. And I don't mean the client who hired you. I mean the client browser has final control. And sometimes the user of that browser changing their settings using a different browser, they get control. And that's a complete paradigm shift from when we were doing print design, or many of us probably weren't doing print design. I was. But now we're dealing with this. So I write one piece of code and then all these devices see it and this is like some fraction of who might be looking at my layout. So it's not just the one orange guy with yellow hair that you're dealing with. You're dealing with all these guys and then all of these people too. And then these people, and you don't even know which ones have autism or some other color blindness, etc. So you've got to deal with a wide range of users and we're not talking just about WCAG accessibility. That and also being aware of people. So empathy is important and I think we all know that. That's the job. Rant. Complete. We heard it in the keynote this morning. Great. So chapter three, layout options. The different ways we could do or no, wait, concepts. Concepts. Okay, a few things that will help get you started with CSS layout. So one, fix the box model. This is the first step in any CSS layout. The box model is broken and you've got to fix it and it takes a line of code. This is the default box model. When you've got a box in CSS, it has a content box, a padding box, a border box, and then a margin. And by default, when you set width and height on an element, you're setting the width and height of the content. And then padding and borders and margin are all added on top of that. And that doesn't make much sense when you're laying out a page. Generally, you want it to be this way. You want to set a width and a height that define the outside of the box. Where the border, where the padding. So it takes one line of code to do that and that's it. It's a universal selector that changes the box model on everything to the border box. And there's a reason we do it this way and not this other way that's going around. There's a reason in CSS inheritance is important. You might have heard of the cascade in style sheets. That's inheritance is what that's about. And that means things can trickle down the chain, the DOM. And this is taking that and putting it to use by setting the box sizing once on the HTML element and then inheriting it everywhere else. But that's similar to inheriting your borders, similar to inheriting backgrounds. It doesn't make any sense. You don't want to inherit box properties. So don't do it. We want to avoid tightly coupled elements. So that means we want to build everything so that it can flex on its own in relation to other things around it. And that means we're really focused on building relationships between things in a way. So I say this will fill all the remaining space. This object will take up this space and this object will take the remaining space. And being too explicit about those sizes is a problem because then suddenly they're coupled. If I have to explicitly state how each object takes up space, and we'll get to exactly how that works. So part of doing that is going with a flow. And the flow in CSS is something like this. It goes left to right and top to bottom. And when I resize this one element, the other objects flow around it. And that's good. That's useful. We want that. So one of my rules for CSS layout is whenever you can, stay in the flow. This is what happens if you don't stay in the flow. Now we resize this one and nothing else changes and suddenly our layout's broken. And that's worse. So we want to stay in the flow when we can. Oh, right. I think I have a real use case. Let's call it that. It's Legos. Oh, that's now. Yeah, there we go. So I made it so that I can resize this one. And you can see by staying in the flow, it's resizing both. Great. So if we add a Lego to the orange, we take a Lego away from the purple. Right? A real use case. Good. All right, when I click in there, I got to get back out. So a few layout techniques, different ways that we could approach laying out a website. So when I first came to CSS, I thought relative positioning would probably be the way to go. That sounds the most reasonable, right? Layout is positioning. Let's try this. It doesn't work. It just pushes the box around and doesn't affect anything else. So that's broken. We're not going to use it. Absolute positioning or fixed positioning? No. Positioning just doesn't work. It sounds reasonable. It's not reasonable for layouts. Absolute positioning goes off of the parent element or the most recently positioned element in the ancestor of that, which is the only way relative positioning is useful. You use relative positioning to create an ancestor to absolute position off of, this is crazy. I don't know why we have it that way. But that's all they do. Absolute positioning and fixed positioning are great for one thing only, overlays. If you need to create something that is not part of the layout, something that's not part of the flow, separate from everything else, a tool tip, a drop down menu, something that's just going to come and go, that's when you can use those. So then we finally get CSS floats and they're like the least bad hack we have for a long time. Not terrible. They're built to do this, which they do perfectly. Like, oh man, you want to wrap some text around an image? You float that shit. It's great. It kind of stays in the flow. Look at that. Look at that flowing. And we can resize this, can we? Ah, yeah. And things almost kind of flow around it, but not quite. And again, that makes sense for floating text around images. You can see that that's basically what it's doing. It's making text flow, but not the actual objects themselves unless they're also floated. So that's weird, but it makes sense for text wrap. And what you need to fix that is a clear fix. And we've gone through like a million of these in the front end world before landing on this one, that now people use fairly regularly, micro clear fix. And all it does is create this little hidden element that I've just shown at the bottom of the screen that clears everything. It's a hack. It's not beautiful, but you can create a mix-in or you can create a utility class, however you like to do it, and you can clear your floats. And this is how we did layouts for quite a while. Now there's this new thing with terrible support that does that. This is a clear fix actually in the spec, and you can't use it. So just thought I'd let you know. The other way you can clear fix, this is a much simpler hack, but with some side effects. You can just put overflow hidden on an element, and it will clear its children, its floated children. So that's very clever, but then it's dangerous if you ever want to break outside of the container because you've just hidden everything that goes outside. So this is what you get. If you use the overflow hack also on something next to it, you'll create a box that can respond and fill the remaining space. So the overflow hack is also useful there. So we can have this be a fixed width, and this one will flow to fill the remaining space. We also use the overflow hack on the container, and now it wraps. So that's clearing floats. Floats are great for flexible markup. You can do as much nesting as you want. You can have this ugly divs that JavaScript, stop giving me divs in JavaScript. I don't want them. But you can nest all this shit, and you can still lay these things out. It doesn't matter. Those divs, because of the way boxes collapse around floats, those boxes will just disappear, and you can lay out elements that are not siblings. And that's rare in CSS. Often things have to be siblings, so this is kind of nice when we get free of that. With floats, you always want to define the width. They sort of automatically go to the widest that the content wants to go, and it's not reliable. So any time you set a float, you basically always want to set a width, which is not great. So you end up, sort of as I said earlier, with tightly coupled elements, because every size affects what space is available for every other element. There used to be this sub-pixel rounding issue that everybody got freaked out about, and there were some grid systems built specifically to handle it. It's not really an issue anymore. This is what it did. Every browser solved this math equation differently. So if you've got 25% of 50 pixels, what is that? And every browser had a different algorithm for figuring that out, and several of them would wrap to the next line when, obviously, 25% times 4 should really get you there. So that's how it was. Now you can see, so float isolation is the trick that people came up with, and that's on the bottom here. Now you can see those red lines appearing are when we get an error in the sub-pixel rounding. And right now the top part is just floated. You can see the browsers that fix this problem. So if you hear somebody telling you you can't do something because sub-pixel rounding, something, something floats, doesn't matter anymore. It works. If you really need isolation, it's kind of a weird hack, and you can do some interesting things with it, but only on rare occasions, and it's not for this anymore. Background images, for some reason, still have sub-pixel rounding issues, and there's no way to fix it, and I don't know why. So you can see the white lines are actually elements showing the correct widths, and then the red lines are they lining up right now? You can see that the red lines of the background and the white lines of the elements jump every once in a while because the background image still has sub-pixel rounding issues. And that's why a lot of grid systems that give you a gradient background, the gradient background's a little sketchy. We do that. Don't use my grid system. Some people for a while then started doing inline block layouts, mainly because you can do some vertical centering, but it's really invasive, and the hacks are really complex to make it work. You've got to basically set your font size to zero and then bring your font size back up for every element. It's weird. I don't recommend it. There's lots of better ways to do vertical centering now. Leave that one out. Display table. This one's interesting. You can now use CSS to mimic a table, even though you haven't put a table in your markup. So that means you can do a table layout that's semantically friendly, and that's great. It's weird, but it's great. So table layouts can do a few things. Like this is the same markup, top and bottom, and then I just added display table. And suddenly it puts them next to each other, and they all resize to fill the space. So that's interesting. Again, this has some of the same problems that tables did in terms of limited styling. It can be difficult to work with, but it does some clever use of space, solves some issues there. So worth knowing, worth keeping in your toolbox, you set display table or display table cell or display table row, and you can mimic those elements. Then we got Flexbox. And Flexbox is magic. It's the first thing we have that's not a hack. Like, this is actually built for the browser to lay things out. That's what it's for. And it's got really good support if you're scared of using Flexbox, don't be scared. Oh, I was looking last night, I wanted to get mayiuse.com, which would be like, can I use, but give you permission? Absolutely, you're welcome to use this. So if I can, I think somebody's squatting on it, maybe I'll go look for mayiuse.io or something. So you can do all sorts of things with Flexbox, I'm not going to get into all of it right now, but you can do equal height columns, you can do, you can align things at the bottom or at the top or the left. You can, all sorts of, you can rearrange your layout so it's right to left in a single declaration. There's all sorts of things you can do here. And you are finally setting up relationships. So this is some stuff on the container, you set display to Flex, align items and justify contents, we'll define how spaces distributed around elements vertically or horizontally. And then with the order property, actually it doesn't make sense for that to go on a container, that would go on the item itself. You can rearrange the order of your elements so you can have them in a reasonable order in the DOM and then move them around visually as you need to. And it's really, it's great. You get this flex grow and flex shrink and flex basis. And now you can really see where we're developing systems of relationships rather than static output. We're saying here's an ideal width, that's the basis. And then here's how much we're allowing it to shrink relative to other elements when there's less space. Here's how much we're allowing it to grow. So those are simple ratios. You can say flex grow one and if everything in the row is flex grow one, they'll grow equally to take the remaining space. And if you set one to flex one and one to flex two, the one set to flex two will take up twice as much of the remaining space. So it's not going to be twice as big, it's going to flex twice as much. Be aware flex basis defaults to a width setting. If you set width, your flex basis will use the width setting and your width setting defaults to auto. So if you don't set either one, your flex basis is auto, which is again similar to floats. So it's sort of the whatever size it thinks this content would most like to take up, which if you're using images that you're trying to shrink down, it can start pushing everything aside. So it's useful to set that explicitly and say what widths you're aiming for. And so you can very quickly with Flexbox create like a full height layout with equal columns. Remember when this used to be a holy grail of some kind? It's fairly simple with a little bit of Flexbox just telling things that they're allowed to use the remaining space and which parts should be static and which parts should flex. So I've set the two sidebars static and the inside is flexible, maybe a little too flexible, but you have a lot of control there. It's still one dimensional. It's still like floats. It goes left to right and then wraps. So you're still not dealing with anything vertically on the page. Well, you can turn it sideways kind of. You can set it to work in a column and wrap in columns. But either way, you're setting it to go in one dimension and then wrap. So that's a way to manipulate two dimensions simultaneously. So that's a limiting factor. Nesting also matters here. We need display contents is coming and display contents. What that will do is basically remove an element from being painted. So if you've got a div that's just sort of an extra div, you can just say display contents and its children will come up a level in the DOM. That element will just disappear. That's coming. It's not supported yet. That will help a lot because right now everything that you're flexing has to be siblings. It's really great for this kind of thing. Where we used to use floats some places, but when we're just dealing with little internal layouts, widgets that we're building, Flexbox works great. It has some performance issues when you're dealing with the whole page. It loads slowly trying to figure out all of the different sizes. It's not great. And being one dimensional, most page layouts are not. So it's mediocre for the big layout, but it's a great replacement for either tables or floats at the small level. All right. And here's where we get into grid systems. Although going back a little bit because we didn't have Flexbox when most of these grid systems came out. And this is sort of a historic detour into why we have grid systems and how they work. This is your average grid system. It's like 12 columns. They're all the same size and there's some gutters between them. And that's roughly the idea. And the idea is this provides some consistency for our design, right? We've limited ourselves to 12 different positions and then from each position of 11 or so spans that we can do from there. The downside, it enforces consistency. So when you've got a grid system that's being used by all of the projects across the Internet, Bootstrap, they all start to look the same. And that's boring. On the other hand, the real reason I think they started to spread back in 2007, 2008, they were sort of the first big thing. Besides Eric Meyer's reset, they were the first big thing that was open source in the CSS world. I don't remember open source in the CSS world before grid systems. It was like Blueprint came out and suddenly everybody was using it. And part of the reason is because in order to do a simple float at that point, you had to use about six different hacks. And so these grid systems were mainly built to solve all of the hacks around floating. Most of those hacks have disappeared. So that reason is gone. So this is Blueprint. It's the first one that I remember. And when I looked at the others, it seems to be the first one that came out. Made by Olaf. And this is how it works. CSS at that point, the only API you can build into CSS is classes. So it uses a class API. And then it allows you to add a class that will give you columns and gutters. In this case, using width and right margins to create the gutter. And then you can span six and you still get the gutter on the end, which I didn't show there. Because I guess I don't want to show you that. But then what happens is when you get to the end of the row, you have to take that gutter off. So if you've put gutters on all of your grid items, suddenly you're removing on the last one. And that's where you get that dot last that became sort of standard. Every other grid system came out of this method. So you can see we get several classes from this one. We got a class of column, then a class of what size of column, and then the class last to remove that last margin. And that's pretty much how grid systems have worked. Classes are the API and it's nice that we finally have a clear API for layouts. And it's sometimes nice that developers can ignore CSS, but it also really sucks that developers are starting to ignore CSS, which is why I'm here. And it really works best for a massive code base where you really have a lot of separation between the people building new widgets and the people designing the patterns. And you can sort of have this simple system of classes that you don't have people stepping on each other's toes as much. It works there. It doesn't work as well when you're a small agency trying to design interesting new websites for new clients consistently. If all your client projects start to look the same, that's not great. So it depends. And I'm going to keep moving. You're not male force or insta face unless you are, so you maybe don't need it. This is object oriented CSS. This came from Nicole Sullivan. It's a little bit simplified. It's not actually technically a grid system. It doesn't give you the 12 columns. It just gives you fractions. And that simplifies it a lot. This is actually the full code of OO CSS crids in her first commit. So it's much more compact and it just gives you fractions and that's simpler. There's no gutters and we'll come back to that. So hers is similar though. Unit size one of two gives you half. Then nine 60 grids and you can see it looks pretty similar except that what they did was they put margins on both sides of everything. And that means we don't have to worry about it at the end. We just have a little bit of space at the edges. So we've got gutters in between and a little bit extra. And that's a little simpler. You don't have last. You don't have anything removing the margins. So okay, that's clever. Meanwhile in 2008 Natalie Down who's sitting right here gave this great talk at Bar Camp Linden that launched my career. So I have to mention her every time. It's a good talk. If you get a chance, it's still relevant. Almost everything in here is still true. But the idea was to create consistent ways of building websites instead of creating tools that would make us do it exactly the same every time. So that's sort of the overall idea is let's have systems instead of strict frameworks and then we can make changes. Frameworks lock you in. They're fine until you want to do something unique. So then her method starts with answering lots of questions, figuring out exactly what kind of site you want. In this method, you're always building the inside with percentages and the outside usually with Ms. max width of 100% and that means you're responding to the browser window and also the font size and also any little changes you want to make to the container. The insides will flow. So it was sort of a responsive design before we had responsive web design trademark. Very clever container response to the viewport and the font sizes. Very few restrictions. You can build anything you want. There's no ugly classes. You're doing it yourself, figuring it out for each project. But the math is ugly because as soon as you start nesting, you have to figure out new contexts and what's going to line up and the percentages change and it is a shit show. And you end up, if you don't have something like SAS, which we didn't, you end up with just those percentages in your code and nobody knows what they mean or where they came from or how to get them again. Help. I stole another slide. So that's when I built Susie. I built Susie just to help me do Natalie's idea without doing this math over and over again in my calculator. I was so tired of it. So I picked up SAS and it's a simple algorithm that we'll look at. Then responsive web design came out and this idea of mobile first. And the idea behind these is that we'll build first four small screens in a single column and then we'll use media queries to increasingly add layout as we get bigger. And that's a great idea. So it looks something like this. You're always using min width media queries to add the next size up and only overriding what you need to override to add the next layout. So Susie gave you sort of any grid system on demand because you could just change a few settings and say I want the gutters on the right. I want them on the left. I want them split. I like you make it up. You set some configurations. But the downside is that grid systems are still overkill and you don't need them. Yeah, you use bootstrap. I know. I'm sorry. OK, so DIY grids. This is how you avoid using grid systems now. Fluid grids require math. But if you make that math simple, you can do this without a system. Building your own the way you want it for your project. This is the math target divided by context equals multiplier. This is how you get a percentage. So this is what it looks like in something like Susie where it's got gutters and it becomes really ugly math. But this is what it looks like if you take the gutters out. So just take the gutters out. You can put them back in somewhere else. Use padding for gutters. Use internal elements for gutters. It doesn't matter. If you can get gutters out of your grid system, suddenly you just need to get a percentage. And in SAS, you can do that with a percentage function. And then 3 of 12, it's still meaningful. It still reads. It's still three columns out of 12 columns. You still have a 12 column grid. And you've used one SAS function instead of any grid system. And that's it. There is your grid system. If you don't even want to use SAS, you can use CALC. The support on CALC is pretty good. It will actually get to it. But it's sort of like CSS systems mixed with OOCSS. You're using fractions. You're doing it on the fly. You can kind of do what you want. And it doesn't require any ugly classes. It works with any technique. You can use it with floats. You can use it with tables. You can use it with Flexbox. You're still dealing with explicit grids rather than implicit relationships, which I think is a downside. I think grids aren't that great. There is no magic in grids. They're not a design savior. You can probably just, you know, say that your sidebar is over here and then your main content takes up the rest of the space. Who cares? You don't need 12 columns for that. So anyway, we get a paradigm shift now in CSS, where we've got custom properties and things like this that are suddenly CSS is becoming extensible. We can build our own things in CSS. So I can create my own property name and I can give it any value. And this is what it looks like. It's an empty prefix. I need some water. This is how you use it. In a CSS value, you call your variable function and you can give it the property name that you want to use and then the fallback value if that property doesn't exist. So that's handy and that's fairly well supported, not everywhere, but coming. And there's a lot you can do with it. You can also mix that with calc and here's a grid system. It's the same math. Your span divided by your columns times 100%. Calc has way larger support. And your grid system looks something like this. I think that's the whole thing that works on its own. So right there you've got a grid system and it can react to the DOM because these variables, unlike SAS variables, these variables inherit. And so you can have a system where your gutters change size and they'll just automatically change size. You can actually see that here. Well, if I resized. So there you've got them one of three and then they suddenly become one of six as this closes. So then they're only taking up a third of the space. And that was just, we just changed how many columns were available at that media query and it all shifts and nothing else had to change in the CSS. Viewport units also give us some more control. Very well supported. If we want a full height layout, we can say we want height 100 VH. If you do that, make sure that you set overflow well because that's going to knock it off at 100% of the height. Viewport units are basically percentages of the full viewport. So if you're setting the height, make sure you know how text is going to overflow. That looks like this. And you can see I set an overflow there. If you want a sticky footer, you can do min height. And that's like this. And I don't have anything overflowing. But that footer would get pushed down. So if you use min height, it's sticky. And if you use height, it's always going to stay there. You can break the container, something like this, by using this simple calculation where you take 50% of the space and subtract 50% of the viewport and you can break out one side or the other of your content, always lining up with the edge of the viewport. There's more you can do with viewport units. You can check that link out later. And then we got CSS Grid. And this is where it gets really exciting because CSS Grid is actually built for actual layouts in two dimensions. And it does what any grid system does but much faster in the browser and with more power. It's actual real layout in the browser. We're no longer talking about faking it or hacking anything. And it suddenly had support in March. Three or four browsers all landed at the same time. And we're using it in production now. There is nothing like it at all. Any grid system that claims to polyfill, there is nothing that does this. So if you can start using Grid, start using Grid. People have been trying to read the spec or give talks that are the spec and it's huge and confusing. Don't bother. It can be fairly simple. You set display grid. You can define the sizes of your columns and your rows. Excuse me. You can define a grid gap. If you need a reference, percentages are relative to the parent size. VW is relative to the window size. And fraction is relative to remaining space. So the new fraction unit in Grid is used to divvy up what space remains. It works very much the same way as Flexbox. Something that is two fractions will just flex twice as much as something that's one fraction. When you use one fraction, it actually implies a min max of a minimum of auto and a maximum of one fraction. And if auto is big, this can end up taking up a lot of space and breaking your layout. So it can be useful to set a smaller minimum where you're using fractions, like min max zero on fraction if you want to allow it to totally flex. You get something like this. Grid lines, one indexed. They're also negative one indexed. You can access them that way. You get grid gaps between. And you can place things like this. Very similar to using a grid system. You just say what line do you want it to start at, what line do you want it to end at. You can also use the span syntax or the negative indexing. And you're just placing your elements wherever you want them. They can overlap. They can go out of order. They can go anywhere. This is new. This is not something we could do before. But really, you probably just want something like this maybe if you're boring, which I am. And you can actually create it with this ASCII art. There you go. Header, header, nav, main, footer, footer. I drew a little ASCII drawing of my website. And then I can just, I define the sizes of each of those columns and rows. And I can assign my header, nav, main, and footer to the right regions. And they fall into place. It doesn't matter how they're ordered in the markup. They're just going to go there. It's done. And that's the entire layout. Use grids. I mean, like, just use this. You just click it together. It can do all kinds of cool shit. There's a website grid by example that even gives you like fallback code for basic patterns. It'll show you all the things grid can do and then simple fallbacks. It goes in two dimensions. It's flexible in markup order. Nothing still matters. That's okay. We'll get there. You can do these data-driven layouts. We have this in production where we're passing in variables that tell something how to lay out. I wrote an article about this. This graph is completely generated just using CSS and CSS variables to pass in live data. And all of the colors and sizes are styled in CSS from the data. So just make sure you wear your helmet because there's dragons. But that's what fallback with ad support is for. You can put fallback code inside of that. They're like media queries but for features, feature queries. And then Susie 3 becomes a fallback plan. You don't need a grid system as the main plan. If you really have difficult math in your fallback, great. Pull in something small. But you probably don't need it. Just do it. Start with the grid. Fix the box model. Stay in the flow. Think dynamically. Relationships between things. How are they going to flow? Remove the external gutter math. And then get creative because we're done with 12 columns. Thank you. Thank you.
 So, don't use my grid system.  Any questions?  I, uh, what?  That's the end of the talk.  How did we get there?  Yeah, we went too far.  All right.  Let's start at the beginning.  The beginning is roughly there.  I don't do Django.  I have no idea what you all are talking about.  It's a lot of fun being here anyway.  There's some fun talks even if I don't know what you're saying.  And then a few that, you know, accessibility.  I do that.  I'm like, yeah, I belong here.  So, I'll establish some creds so you know why I am here.  I found it odd bird with my brothers.  This is, I think, our first planning meeting.  Ignore the magic the gathering cards.  You might recognize the middle one.  He's usually here.  I thought it would be fun to come do a talk with my brother.  And then he ditched out.  So, sorry.  So, that's Carl Meyer if you don't know.  So, this is our team now.  We've grown up a little bit since whatever that was, 94 or something.  We've got a team of seven.  We're a small agency doing consulting work.  And I do a lot of the user experience design and project management  and front end design implementation  and writing all sorts of tools for developers,  us and open source community including  which helps you manage abstract patterns and code  like colors, fonts.  They're not physical patterns like your buttons.  That's sort of more abstract patterns that exist in a design system.  So, looks something like this.  You don't care.  I don't care either.  Herman helps you automate pattern libraries.  Great.  Fun.  And then Susie which ended up being the big one.  And it's, I don't know why, it's just another grid system.  And I stopped using it right around the time it became really popular  but I still maintain it.  And that's a lot of fun.  So, to go back a ways, blue, blue.  The history of web layout and why we have grid systems  and why you don't need them anymore.  So that starts with UGG tables.  Remember these?  I used a pixelated image because it felt right.  Like, oh, that's so ugly.  And the markups all out of, oh yeah.  Why do we do this to ourselves?  I stole that from a talk this morning.  Silly dev.  Tables are for data.  We know that.  And you know, but at the time it was the only way we had to lay out a page.  That was before we even had the basics of CSS.  So, tables were what we had and we made do.  But you've got really limited styling.  There's a lot you can't do with a table.  So you're really constricted there.  The markup is really strict and it's ordered right for data.  It's not ordered right for content.  So you're always going left to right, left to right, left to right.  And that doesn't always make sense.  So it's an accessibility nightmare.  And we know that that's bad because we weren't to the accessibility talk.  Code is communication for this lots of places.  I think it's really true.  What we're trying to do is write something that is readable to both other people and to a machine.  And if we succeed at both, we've written good code.  So table layouts break all of that.  They destroy meaning for everybody.  They're not meaningful to the computer.  They're not meaningful to me.  When I read the markup, they're just not meaningful.  Great.  Chapter two, CSS is awesome.  So that's the end of the talk.  Any questions there?  You've all seen this, I'm sure.  And I just want to remind you that this is not a bug.  This is a feature.  And I mean that.  This is what happens when you are too explicit about too many things on the web.  This is also what happens when you don't specify your overflow.  So CSS here is allowing you to make lots of decisions, even bad decisions.  And this is you making some bad decisions and you're welcome to do that.  And it can be fun.  That's okay.  That's not a problem with the language.  A thing to remember with CSS is that it's easy to be fooled by the declarative syntax into thinking that it's a static language.  That you put something in and you get a result and that's it.  And that's not how the web works.  With CSS, you're really putting in rules for how something is going to change across different browsers,  across different platforms, across different device sizes, window sizes,  all sorts of different changes that can come at you.  And CSS is a set of rules and suggestions for how you might lay that out.  So you're really wanting to define dynamic relationships between objects in a way that doesn't couple them too tightly.  This is, you know, like programming.  And you're designed for what happens if the content changes, gets really long, gets really short,  what happens if the viewport changes, what happens if the context changes.  We take this widget and we put it somewhere else and it has more or less space.  And the client has control over what the final look is.  And I don't mean the client who hired you.  I mean the client browser has final control.  And sometimes the user of that browser changing their settings using a different browser,  they get control.  And that's a complete paradigm shift from when we were doing print design,  or many of us probably weren't doing print design.  I was.  But now we're dealing with this.  So I write one piece of code and then all these devices see it and this is like some fraction of who might be looking at my layout.  So it's not just the one orange guy with yellow hair that you're dealing with.  You're dealing with all these guys and then all of these people too.  And then these people, and you don't even know which ones have autism or some other color blindness, etc.  So you've got to deal with a wide range of users and we're not talking just about WCAG accessibility.  That and also being aware of people.  So empathy is important and I think we all know that.  That's the job.  Rant. Complete.  We heard it in the keynote this morning.  Great.  So chapter three, layout options.  The different ways we could do or no, wait, concepts.  Concepts.  Okay, a few things that will help get you started with CSS layout.  So one, fix the box model.  This is the first step in any CSS layout.  The box model is broken and you've got to fix it and it takes a line of code.  This is the default box model.  When you've got a box in CSS, it has a content box, a padding box, a border box, and then a margin.  And by default, when you set width and height on an element, you're setting the width and height of the content.  And then padding and borders and margin are all added on top of that.  And that doesn't make much sense when you're laying out a page.  Generally, you want it to be this way.  You want to set a width and a height that define the outside of the box.  Where the border, where the padding.  So it takes one line of code to do that and that's it.  It's a universal selector that changes the box model on everything to the border box.  And there's a reason we do it this way and not this other way that's going around.  There's a reason in CSS inheritance is important.  You might have heard of the cascade in style sheets.  That's inheritance is what that's about.  And that means things can trickle down the chain, the DOM.  And this is taking that and putting it to use by setting the box sizing once on the HTML element and then inheriting it everywhere else.  But that's similar to inheriting your borders, similar to inheriting backgrounds.  It doesn't make any sense.  You don't want to inherit box properties.  So don't do it.  We want to avoid tightly coupled elements.  So that means we want to build everything so that it can flex on its own in relation to other things around it.  And that means we're really focused on building relationships between things in a way.  So I say this will fill all the remaining space.  This object will take up this space and this object will take the remaining space.  And being too explicit about those sizes is a problem because then suddenly they're coupled.  If I have to explicitly state how each object takes up space, and we'll get to exactly how that works.  So part of doing that is going with a flow.  And the flow in CSS is something like this.  It goes left to right and top to bottom.  And when I resize this one element, the other objects flow around it.  And that's good.  That's useful.  We want that.  So one of my rules for CSS layout is whenever you can, stay in the flow.  This is what happens if you don't stay in the flow.  Now we resize this one and nothing else changes and suddenly our layout's broken.  And that's worse.  So we want to stay in the flow when we can.  Oh, right.  I think I have a real use case.  Let's call it that.  It's Legos.  Oh, that's now.  Yeah, there we go.  So I made it so that I can resize this one.  And you can see by staying in the flow, it's resizing both.  Great.  So if we add a Lego to the orange, we take a Lego away from the purple.  Right?  A real use case.  Good.  All right, when I click in there, I got to get back out.  So a few layout techniques, different ways that we could approach laying out a website.  So when I first came to CSS, I thought relative positioning would probably be the way to go.  That sounds the most reasonable, right?  Layout is positioning.  Let's try this.  It doesn't work.  It just pushes the box around and doesn't affect anything else.  So that's broken.  We're not going to use it.  Absolute positioning or fixed positioning?  No.  Positioning just doesn't work.  It sounds reasonable.  It's not reasonable for layouts.  Absolute positioning goes off of the parent element or the most recently positioned element in the ancestor of that,  which is the only way relative positioning is useful.  You use relative positioning to create an ancestor to absolute position off of, this is crazy.  I don't know why we have it that way.  But that's all they do.  Absolute positioning and fixed positioning are great for one thing only, overlays.  If you need to create something that is not part of the layout, something that's not part of the flow,  separate from everything else, a tool tip, a drop down menu, something that's just going to come and go,  that's when you can use those.  So then we finally get CSS floats and they're like the least bad hack we have for a long time.  Not terrible.  They're built to do this, which they do perfectly.  Like, oh man, you want to wrap some text around an image?  You float that shit.  It's great.  It kind of stays in the flow.  Look at that.  Look at that flowing.  And we can resize this, can we?  Ah, yeah.  And things almost kind of flow around it, but not quite.  And again, that makes sense for floating text around images.  You can see that that's basically what it's doing.  It's making text flow, but not the actual objects themselves unless they're also floated.  So that's weird, but it makes sense for text wrap.  And what you need to fix that is a clear fix.  And we've gone through like a million of these in the front end world before landing on this one,  that now people use fairly regularly, micro clear fix.  And all it does is create this little hidden element that I've just shown at the bottom of the screen that clears everything.  It's a hack.  It's not beautiful, but you can create a mix-in or you can create a utility class, however you like to do it,  and you can clear your floats.  And this is how we did layouts for quite a while.  Now there's this new thing with terrible support that does that.  This is a clear fix actually in the spec, and you can't use it.  So just thought I'd let you know.  The other way you can clear fix, this is a much simpler hack, but with some side effects.  You can just put overflow hidden on an element, and it will clear its children, its floated children.  So that's very clever, but then it's dangerous if you ever want to break outside of the container  because you've just hidden everything that goes outside.  So this is what you get.  If you use the overflow hack also on something next to it, you'll create a box that can respond  and fill the remaining space.  So the overflow hack is also useful there.  So we can have this be a fixed width, and this one will flow to fill the remaining space.  We also use the overflow hack on the container, and now it wraps.  So that's clearing floats.  Floats are great for flexible markup.  You can do as much nesting as you want.  You can have this ugly divs that JavaScript, stop giving me divs in JavaScript.  I don't want them.  But you can nest all this shit, and you can still lay these things out.  It doesn't matter.  Those divs, because of the way boxes collapse around floats, those boxes will just disappear,  and you can lay out elements that are not siblings.  And that's rare in CSS.  Often things have to be siblings, so this is kind of nice when we get free of that.  With floats, you always want to define the width.  They sort of automatically go to the widest that the content wants to go, and it's not reliable.  So any time you set a float, you basically always want to set a width, which is not great.  So you end up, sort of as I said earlier, with tightly coupled elements, because every size affects what space is available for every other element.  There used to be this sub-pixel rounding issue that everybody got freaked out about, and there were some grid systems built specifically to handle it.  It's not really an issue anymore.  This is what it did.  Every browser solved this math equation differently.  So if you've got 25% of 50 pixels, what is that?  And every browser had a different algorithm for figuring that out, and several of them would wrap to the next line when, obviously, 25% times 4 should really get you there.  So that's how it was.  Now you can see, so float isolation is the trick that people came up with, and that's on the bottom here.  Now you can see those red lines appearing are when we get an error in the sub-pixel rounding.  And right now the top part is just floated.  You can see the browsers that fix this problem.  So if you hear somebody telling you you can't do something because sub-pixel rounding, something, something floats, doesn't matter anymore.  It works.  If you really need isolation, it's kind of a weird hack, and you can do some interesting things with it, but only on rare occasions, and it's not for this anymore.  Background images, for some reason, still have sub-pixel rounding issues, and there's no way to fix it, and I don't know why.  So you can see the white lines are actually elements showing the correct widths, and then the red lines are they lining up right now?  You can see that the red lines of the background and the white lines of the elements jump every once in a while because the background image still has sub-pixel rounding issues.  And that's why a lot of grid systems that give you a gradient background, the gradient background's a little sketchy.  We do that.  Don't use my grid system.  Some people for a while then started doing inline block layouts, mainly because you can do some vertical centering, but it's really invasive, and the hacks are really complex to make it work.  You've got to basically set your font size to zero and then bring your font size back up for every element.  It's weird.  I don't recommend it.  There's lots of better ways to do vertical centering now.  Leave that one out.  Display table.  This one's interesting.  You can now use CSS to mimic a table, even though you haven't put a table in your markup.  So that means you can do a table layout that's semantically friendly, and that's great.  It's weird, but it's great.  So table layouts can do a few things.  Like this is the same markup, top and bottom, and then I just added display table.  And suddenly it puts them next to each other, and they all resize to fill the space.  So that's interesting.  Again, this has some of the same problems that tables did in terms of limited styling.  It can be difficult to work with, but it does some clever use of space, solves some issues there.  So worth knowing, worth keeping in your toolbox, you set display table or display table cell or display table row,  and you can mimic those elements.  Then we got Flexbox.  And Flexbox is magic.  It's the first thing we have that's not a hack.  Like, this is actually built for the browser to lay things out.  That's what it's for.  And it's got really good support if you're scared of using Flexbox, don't be scared.  Oh, I was looking last night, I wanted to get mayiuse.com, which would be like, can I use, but give you permission?  Absolutely, you're welcome to use this.  So if I can, I think somebody's squatting on it, maybe I'll go look for mayiuse.io or something.  So you can do all sorts of things with Flexbox, I'm not going to get into all of it right now,  but you can do equal height columns, you can do, you can align things at the bottom or at the top or the left.  You can, all sorts of, you can rearrange your layout so it's right to left in a single declaration.  There's all sorts of things you can do here.  And you are finally setting up relationships.  So this is some stuff on the container, you set display to Flex, align items and justify contents,  we'll define how spaces distributed around elements vertically or horizontally.  And then with the order property, actually it doesn't make sense for that to go on a container, that would go on the item itself.  You can rearrange the order of your elements so you can have them in a reasonable order in the DOM and then move them around visually as you need to.  And it's really, it's great.  You get this flex grow and flex shrink and flex basis.  And now you can really see where we're developing systems of relationships rather than static output.  We're saying here's an ideal width, that's the basis.  And then here's how much we're allowing it to shrink relative to other elements when there's less space.  Here's how much we're allowing it to grow.  So those are simple ratios. You can say flex grow one and if everything in the row is flex grow one,  they'll grow equally to take the remaining space.  And if you set one to flex one and one to flex two, the one set to flex two will take up twice as much of the remaining space.  So it's not going to be twice as big, it's going to flex twice as much.  Be aware flex basis defaults to a width setting.  If you set width, your flex basis will use the width setting and your width setting defaults to auto.  So if you don't set either one, your flex basis is auto, which is again similar to floats.  So it's sort of the whatever size it thinks this content would most like to take up,  which if you're using images that you're trying to shrink down, it can start pushing everything aside.  So it's useful to set that explicitly and say what widths you're aiming for.  And so you can very quickly with Flexbox create like a full height layout with equal columns.  Remember when this used to be a holy grail of some kind?  It's fairly simple with a little bit of Flexbox just telling things that they're allowed to use the remaining space  and which parts should be static and which parts should flex.  So I've set the two sidebars static and the inside is flexible, maybe a little too flexible,  but you have a lot of control there.  It's still one dimensional.  It's still like floats.  It goes left to right and then wraps.  So you're still not dealing with anything vertically on the page.  Well, you can turn it sideways kind of.  You can set it to work in a column and wrap in columns.  But either way, you're setting it to go in one dimension and then wrap.  So that's a way to manipulate two dimensions simultaneously.  So that's a limiting factor.  Nesting also matters here.  We need display contents is coming and display contents.  What that will do is basically remove an element from being painted.  So if you've got a div that's just sort of an extra div, you can just say display contents and its children will come up a level in the DOM.  That element will just disappear.  That's coming.  It's not supported yet.  That will help a lot because right now everything that you're flexing has to be siblings.  It's really great for this kind of thing.  Where we used to use floats some places, but when we're just dealing with little internal layouts, widgets that we're building, Flexbox works great.  It has some performance issues when you're dealing with the whole page.  It loads slowly trying to figure out all of the different sizes.  It's not great.  And being one dimensional, most page layouts are not.  So it's mediocre for the big layout, but it's a great replacement for either tables or floats at the small level.  All right.  And here's where we get into grid systems.  Although going back a little bit because we didn't have Flexbox when most of these grid systems came out.  And this is sort of a historic detour into why we have grid systems and how they work.  This is your average grid system.  It's like 12 columns.  They're all the same size and there's some gutters between them.  And that's roughly the idea.  And the idea is this provides some consistency for our design, right?  We've limited ourselves to 12 different positions and then from each position of 11 or so spans that we can do from there.  The downside, it enforces consistency.  So when you've got a grid system that's being used by all of the projects across the Internet, Bootstrap,  they all start to look the same.  And that's boring.  On the other hand, the real reason I think they started to spread back in 2007, 2008, they were sort of the first big thing.  Besides Eric Meyer's reset, they were the first big thing that was open source in the CSS world.  I don't remember open source in the CSS world before grid systems.  It was like Blueprint came out and suddenly everybody was using it.  And part of the reason is because in order to do a simple float at that point, you had to use about six different hacks.  And so these grid systems were mainly built to solve all of the hacks around floating.  Most of those hacks have disappeared.  So that reason is gone.  So this is Blueprint.  It's the first one that I remember.  And when I looked at the others, it seems to be the first one that came out.  Made by Olaf.  And this is how it works.  CSS at that point, the only API you can build into CSS is classes.  So it uses a class API.  And then it allows you to add a class that will give you columns and gutters.  In this case, using width and right margins to create the gutter.  And then you can span six and you still get the gutter on the end, which I didn't show there.  Because I guess I don't want to show you that.  But then what happens is when you get to the end of the row, you have to take that gutter off.  So if you've put gutters on all of your grid items, suddenly you're removing on the last one.  And that's where you get that dot last that became sort of standard.  Every other grid system came out of this method.  So you can see we get several classes from this one.  We got a class of column, then a class of what size of column, and then the class last to remove that last margin.  And that's pretty much how grid systems have worked.  Classes are the API and it's nice that we finally have a clear API for layouts.  And it's sometimes nice that developers can ignore CSS, but it also really sucks that developers are starting to ignore CSS,  which is why I'm here.  And it really works best for a massive code base where you really have a lot of separation between the people building new widgets  and the people designing the patterns.  And you can sort of have this simple system of classes that you don't have people stepping on each other's toes as much.  It works there.  It doesn't work as well when you're a small agency trying to design interesting new websites for new clients consistently.  If all your client projects start to look the same, that's not great.  So it depends.  And I'm going to keep moving.  You're not male force or insta face unless you are, so you maybe don't need it.  This is object oriented CSS.  This came from Nicole Sullivan.  It's a little bit simplified.  It's not actually technically a grid system.  It doesn't give you the 12 columns.  It just gives you fractions.  And that simplifies it a lot.  This is actually the full code of OO CSS crids in her first commit.  So it's much more compact and it just gives you fractions and that's simpler.  There's no gutters and we'll come back to that.  So hers is similar though.  Unit size one of two gives you half.  Then nine 60 grids and you can see it looks pretty similar except that what they did was they put margins on both sides of everything.  And that means we don't have to worry about it at the end.  We just have a little bit of space at the edges.  So we've got gutters in between and a little bit extra.  And that's a little simpler.  You don't have last.  You don't have anything removing the margins.  So okay, that's clever.  Meanwhile in 2008 Natalie Down who's sitting right here gave this great talk at Bar Camp Linden that launched my career.  So I have to mention her every time.  It's a good talk.  If you get a chance, it's still relevant.  Almost everything in here is still true.  But the idea was to create consistent ways of building websites instead of creating tools that would make us do it exactly the same every time.  So that's sort of the overall idea is let's have systems instead of strict frameworks and then we can make changes.  Frameworks lock you in.  They're fine until you want to do something unique.  So then her method starts with answering lots of questions, figuring out exactly what kind of site you want.  In this method, you're always building the inside with percentages and the outside usually with Ms.  max width of 100% and that means you're responding to the browser window and also the font size and also any little changes you want to make to the container.  The insides will flow.  So it was sort of a responsive design before we had responsive web design trademark.  Very clever container response to the viewport and the font sizes.  Very few restrictions.  You can build anything you want.  There's no ugly classes.  You're doing it yourself, figuring it out for each project.  But the math is ugly because as soon as you start nesting, you have to figure out new contexts and what's going to line up and the percentages change and it is a shit show.  And you end up, if you don't have something like SAS, which we didn't, you end up with just those percentages in your code and nobody knows what they mean or where they came from or how to get them again.  Help.  I stole another slide.  So that's when I built Susie.  I built Susie just to help me do Natalie's idea without doing this math over and over again in my calculator.  I was so tired of it.  So I picked up SAS and it's a simple algorithm that we'll look at.  Then responsive web design came out and this idea of mobile first.  And the idea behind these is that we'll build first four small screens in a single column and then we'll use media queries to increasingly add layout as we get bigger.  And that's a great idea.  So it looks something like this.  You're always using min width media queries to add the next size up and only overriding what you need to override to add the next layout.  So Susie gave you sort of any grid system on demand because you could just change a few settings and say I want the gutters on the right.  I want them on the left.  I want them split.  I like you make it up.  You set some configurations.  But the downside is that grid systems are still overkill and you don't need them.  Yeah, you use bootstrap.  I know.  I'm sorry.  OK, so DIY grids.  This is how you avoid using grid systems now.  Fluid grids require math.  But if you make that math simple, you can do this without a system.  Building your own the way you want it for your project.  This is the math target divided by context equals multiplier.  This is how you get a percentage.  So this is what it looks like in something like Susie where it's got gutters and it becomes really ugly math.  But this is what it looks like if you take the gutters out.  So just take the gutters out.  You can put them back in somewhere else.  Use padding for gutters.  Use internal elements for gutters.  It doesn't matter.  If you can get gutters out of your grid system, suddenly you just need to get a percentage.  And in SAS, you can do that with a percentage function.  And then 3 of 12, it's still meaningful.  It still reads.  It's still three columns out of 12 columns.  You still have a 12 column grid.  And you've used one SAS function instead of any grid system.  And that's it.  There is your grid system.  If you don't even want to use SAS, you can use CALC.  The support on CALC is pretty good.  It will actually get to it.  But it's sort of like CSS systems mixed with OOCSS.  You're using fractions.  You're doing it on the fly.  You can kind of do what you want.  And it doesn't require any ugly classes.  It works with any technique.  You can use it with floats.  You can use it with tables.  You can use it with Flexbox.  You're still dealing with explicit grids rather than implicit relationships,  which I think is a downside.  I think grids aren't that great.  There is no magic in grids.  They're not a design savior.  You can probably just, you know, say that your sidebar is over here  and then your main content takes up the rest of the space.  Who cares?  You don't need 12 columns for that.  So anyway, we get a paradigm shift now in CSS,  where we've got custom properties and things like this  that are suddenly CSS is becoming extensible.  We can build our own things in CSS.  So I can create my own property name and I can give it any value.  And this is what it looks like.  It's an empty prefix.  I need some water.  This is how you use it.  In a CSS value, you call your variable function  and you can give it the property name that you want to use  and then the fallback value if that property doesn't exist.  So that's handy and that's fairly well supported,  not everywhere, but coming.  And there's a lot you can do with it.  You can also mix that with calc and here's a grid system.  It's the same math.  Your span divided by your columns times 100%.  Calc has way larger support.  And your grid system looks something like this.  I think that's the whole thing that works on its own.  So right there you've got a grid system  and it can react to the DOM because these variables,  unlike SAS variables, these variables inherit.  And so you can have a system where your gutters change size  and they'll just automatically change size.  You can actually see that here.  Well, if I resized.  So there you've got them one of three  and then they suddenly become one of six as this closes.  So then they're only taking up a third of the space.  And that was just, we just changed how many columns were available  at that media query and it all shifts  and nothing else had to change in the CSS.  Viewport units also give us some more control.  Very well supported.  If we want a full height layout, we can say we want height 100 VH.  If you do that, make sure that you set overflow well  because that's going to knock it off at 100% of the height.  Viewport units are basically percentages of the full viewport.  So if you're setting the height, make sure you know how text is going to overflow.  That looks like this.  And you can see I set an overflow there.  If you want a sticky footer, you can do min height.  And that's like this.  And I don't have anything overflowing.  But that footer would get pushed down.  So if you use min height, it's sticky.  And if you use height, it's always going to stay there.  You can break the container, something like this,  by using this simple calculation where you take 50% of the space  and subtract 50% of the viewport  and you can break out one side or the other of your content,  always lining up with the edge of the viewport.  There's more you can do with viewport units.  You can check that link out later.  And then we got CSS Grid.  And this is where it gets really exciting  because CSS Grid is actually built for actual layouts in two dimensions.  And it does what any grid system does  but much faster in the browser and with more power.  It's actual real layout in the browser.  We're no longer talking about faking it or hacking anything.  And it suddenly had support in March.  Three or four browsers all landed at the same time.  And we're using it in production now.  There is nothing like it at all.  Any grid system that claims to polyfill,  there is nothing that does this.  So if you can start using Grid, start using Grid.  People have been trying to read the spec or give talks that are the spec  and it's huge and confusing.  Don't bother.  It can be fairly simple.  You set display grid.  You can define the sizes of your columns and your rows.  Excuse me.  You can define a grid gap.  If you need a reference, percentages are relative to the parent size.  VW is relative to the window size.  And fraction is relative to remaining space.  So the new fraction unit in Grid is used to divvy up what space remains.  It works very much the same way as Flexbox.  Something that is two fractions will just flex twice as much as something that's one fraction.  When you use one fraction, it actually implies a min max of a minimum of auto and a maximum of one fraction.  And if auto is big, this can end up taking up a lot of space and breaking your layout.  So it can be useful to set a smaller minimum where you're using fractions,  like min max zero on fraction if you want to allow it to totally flex.  You get something like this.  Grid lines, one indexed.  They're also negative one indexed.  You can access them that way.  You get grid gaps between.  And you can place things like this.  Very similar to using a grid system.  You just say what line do you want it to start at, what line do you want it to end at.  You can also use the span syntax or the negative indexing.  And you're just placing your elements wherever you want them.  They can overlap.  They can go out of order.  They can go anywhere.  This is new.  This is not something we could do before.  But really, you probably just want something like this maybe if you're boring, which I am.  And you can actually create it with this ASCII art.  There you go.  Header, header, nav, main, footer, footer.  I drew a little ASCII drawing of my website.  And then I can just, I define the sizes of each of those columns and rows.  And I can assign my header, nav, main, and footer to the right regions.  And they fall into place.  It doesn't matter how they're ordered in the markup.  They're just going to go there.  It's done.  And that's the entire layout.  Use grids.  I mean, like, just use this.  You just click it together.  It can do all kinds of cool shit.  There's a website grid by example that even gives you like fallback code for basic patterns.  It'll show you all the things grid can do and then simple fallbacks.  It goes in two dimensions.  It's flexible in markup order.  Nothing still matters.  That's okay.  We'll get there.  You can do these data-driven layouts.  We have this in production where we're passing in variables that tell something how to lay out.  I wrote an article about this.  This graph is completely generated just using CSS and CSS variables to pass in live data.  And all of the colors and sizes are styled in CSS from the data.  So just make sure you wear your helmet because there's dragons.  But that's what fallback with ad support is for.  You can put fallback code inside of that.  They're like media queries but for features, feature queries.  And then Susie 3 becomes a fallback plan.  You don't need a grid system as the main plan.  If you really have difficult math in your fallback, great.  Pull in something small.  But you probably don't need it.  Just do it.  Start with the grid.  Fix the box model.  Stay in the flow.  Think dynamically.  Relationships between things.  How are they going to flow?  Remove the external gutter math.  And then get creative because we're done with 12 columns.  Thank you.  Thank you.
Dont_Use_My_Grid_System_0_131.png Dont_Use_My_Grid_System_132_251.png Dont_Use_My_Grid_System_252_359.png Dont_Use_My_Grid_System_360_1451.png Dont_Use_My_Grid_System_1452_2051.png Dont_Use_My_Grid_System_2052_3347.png Dont_Use_My_Grid_System_3348_4367.png Dont_Use_My_Grid_System_4368_4547.png Dont_Use_My_Grid_System_4548_10067.png Dont_Use_My_Grid_System_10068_10355.png Dont_Use_My_Grid_System_10356_11315.png Dont_Use_My_Grid_System_11316_11363.png Dont_Use_My_Grid_System_11364_11903.png Dont_Use_My_Grid_System_11904_12635.png Dont_Use_My_Grid_System_12636_15539.png Dont_Use_My_Grid_System_15540_16703.png Dont_Use_My_Grid_System_16704_17795.png Dont_Use_My_Grid_System_17796_17963.png Dont_Use_My_Grid_System_17964_18035.png Dont_Use_My_Grid_System_18036_19811.png Dont_Use_My_Grid_System_19812_20603.png Dont_Use_My_Grid_System_20604_20975.png Dont_Use_My_Grid_System_20976_21251.png Dont_Use_My_Grid_System_21252_21467.png Dont_Use_My_Grid_System_21468_22415.png Dont_Use_My_Grid_System_22416_23183.png Dont_Use_My_Grid_System_23184_25019.png Dont_Use_My_Grid_System_25020_28991.png Dont_Use_My_Grid_System_28992_35723.png Dont_Use_My_Grid_System_35724_38675.png Dont_Use_My_Grid_System_38676_41423.png Dont_Use_My_Grid_System_41424_41963.png Dont_Use_My_Grid_System_41964_42227.png Dont_Use_My_Grid_System_42228_44087.png Dont_Use_My_Grid_System_44088_44651.png Dont_Use_My_Grid_System_44652_44855.png Dont_Use_My_Grid_System_44856_45227.png Dont_Use_My_Grid_System_45228_45791.png Dont_Use_My_Grid_System_45792_48791.png Dont_Use_My_Grid_System_48792_51347.png Dont_Use_My_Grid_System_51348_55919.png Dont_Use_My_Grid_System_55920_56303.png Dont_Use_My_Grid_System_56304_57539.png Dont_Use_My_Grid_System_57540_57887.png Dont_Use_My_Grid_System_57888_58835.png Dont_Use_My_Grid_System_58836_59135.png Dont_Use_My_Grid_System_59136_62423.png Dont_Use_My_Grid_System_62424_63239.png Dont_Use_My_Grid_System_63240_65303.png Dont_Use_My_Grid_System_65304_65363.png Dont_Use_My_Grid_System_65364_65423.png Dont_Use_My_Grid_System_65424_66551.png Dont_Use_My_Grid_System_66552_66719.png Dont_Use_My_Grid_System_66720_66742.png