Transcription
[Digital music]
[Applause]
Miriam Suzanne: Hi. here I am. I’m going to talk about not using my grid system. My name is Miriam.
Audience: [Laughter]
Miriam: Some say “whatever.” I’m not sure what my job title is. I run my own agency. It doesn’t matter.
I’m allowed to use these slides because I learned about the importance of stealing.
Audience: [Laughter]
Miriam: So, I’ve got this.
Audience: [Laughter]
Miriam: Somebody told me I should make sure people know who I am and that you trust me, and so I built Susy. But then they were like, “You should show how many downloads it gets.” I was like, “No. Tell people to stop using it. Don’t use it.” So, that’s the end of my talk. [Laughter]
Audience: [Laughter]
Miriam: Thank you. [Laughter]
[Applause]
Miriam: Hopefully, you trust me now. Susy is just another fucking grid system. It doesn’t matter. You can ignore that.
Yeah, I’m going to talk about layouts--
Audience: [Laughter]
Miriam: Grids. [Laughter] I’ve got more. They’re going to keep coming.
Audience: [Laughter]
Miriam: We’ll start with sort of a -- there’s way too much material in here, so I’m going to move quickly, but I’m going to sort of start with an overview of the history of Web layouts, so a little bit of a flashback to 1994 when tables were introduced to HTML. And, that was what we used for a layout for a while. This is me in ’94 starting my company with my brothers. I think we’re doing a card sort there, some sort of--I don’t know--Magic the Gathering, I think.
You might remember tables. I looked for the most pixelated photo I could find. It seemed about right. Lots of nesting; lots of trying to figure out what the order of things is because it’s all out of order.
We all know that that doesn’t work for layouts. Tables are for data. We’ve heard that before. And, the problem is that we’ve got this strict markup. It’s not linear. You can’t read through the document. We’ve got limited styling options. It’s hard to style tables in very interesting ways.
It’s an accessibility nightmare that comes from various parts of that, and you’ll learn more about accessibility next, I think. So, stick around for that. I don’t have to go into it, but you know it’s also an SEO problem and legal problem: search engine optimization. If you don’t do it for people, do it for the robot lawyers.
I always heard -- well, okay. Sarah Drasner said this once a talk that I was at, and I’ve been using it in my slides ever since. And, she keeps saying, “Miriam, I only said it one time,” and I’m like, “Yeah, good enough.”
Audience: [Laughter]
Miriam: I heard you say it. I can put it in my slides. “Code is communication.” We’re writing instructions to a machine. We’re also writing instructions that other people will have to read and maintain. And, by other people, I mean me next week. So, I have to communicate both with machines and with humans, and that’s part of creating this network.
Audience: [Laughter]
Miriam: Markup is all about giving our documents structure, giving it meaning, so that we can get these networks of understanding and do all the cool stuff there.
We have to write code that’s meaningful to humans and machines. Here’s a human and a machine in case you were wondering who we’re working for.
We’re not just designing for one man with yellow hair. We’re not designing just for this device, not even all of these men, not even these devices, not just them. It’s really everybody, and we don’t know a lot about their context. We don’t meet them. But, we have to plan for them anyway. We have to think about the edge cases.
This is, like, a fraction of our users here. That’s a lot of screens.
This all comes from this initial mission statement. I love that the medium we work in has a mission statement written by somebody who is still alive and running an organization that maintains it.
You know if we have a mission statement from the printing press, what would that be? I’d love to see it.
But, this “Web for all. Web on everything,” sort of changes the way that we think. There are lots of articles about that, this sort of client control of the viewing experience. Instead of just putting it on paper once and having it stay the same for everybody, we’re putting it on all sorts of screens all over the world, different languages, different sizes, so everything changes.
When we’re talking about layout for the Web, we’re not just coming up with one single layout. We’re thinking about, how is this going to adapt?
When the content changes, we’re dealing with a CMS. We’re dealing with live data, whatever. When the viewport changes, so different screen sizes, when the context changes--this is a big conversation right now with modular systems and components--when they’re in different locations, how do they adjust? How do we design dynamic relationships between the elements on the page rather than simply designing one single overall layout?
Then, in ’96, we got the first vision for CSS. It didn’t land in most browsers until 2000. That’s around the time that I was moving from school into actually doing the work. I got to play with tables in school and then use CSS.
CSS is awesome, and we’re done.
Audience member:: Whoo!
Miriam: Whoo!
[Applause]
Miriam: I keep ending this early.
You’ve probably seen this. I think it’s really misunderstood. This is a feature. If you had a design program that couldn’t do text overflowing a box, you would be fucking pissed. Like, if you want this, you can do it in CSS. This is a good thing, so that’s a side rant.
But, the thing to remember about CSS is not to be fooled. Just because it’s a declarative syntax, people sort of talk about that as though it means it’s static, as though it’s just one, you just set one thing and it’s there, but it’s not. It’s a very dynamic language. We’re trying to express relationships between objects on a page and how they’re going to arrange.
A few layout concepts sort of broadly before we get into how we’re actually building a layout. The first is the box model. This is very important, and it’s kind of broken. Internet Explorer, interestingly, got that right the first time and then had to fix it so it’s wrong.
This is what we have as the default, the content box. It does have use cases. There are reasons to use this. They’re just rare. When we set the width and the height, we’re talking about just the content internally, and then we have padding and margin added to that, and border.
That’s useful in cases where we really want to just say the size of the content, but that’s rarely what we’re able to do. Especially on containers, that’s particularly a good use case for it.
More useful for most cases is the border box, and this allows us to set the height and width, and then everything is subtracted from that. That’s sort of an additive model or a subtractive model, if you like to think about it that way. This is more useful in a lot of cases, and we can fix it everywhere with just a couple lines of code. I start all my projects with this, and then I have a box model that works.
I’ve seen a lot of people doing it this way; you set it once and then you set it to inherit. There’s a reason that box model doesn’t inherit by default, and there’s no reason that it should inherit. We don’t inherit margins. We don’t inherit borders. Layouts should not be inherited. Layouts don’t nest in that way, so I don’t recommend this solution.
The other thing that’s really important to understand, working with CSS, working with the Web, is the flow and how to go with the flow. This is a rule that we have at our company is, whenever possible, go with the flow. So, like, here are some objects. I think they’re all floated. And, if one of them resizes--
I don’t have access to that. I don’t know why.
But, if one of them resizes, the others should flow.
Huh. Interesting. All right.
What the flow does is it allows us to, when one thing changes, the other things move around to fit, and that’s what we want. We want these relationships where each item is not living completely on its own, but they’re able to move in relationship to each other. And, that helps us avoid tightly coupled elements where, if I move this one, the others don’t move, and now I have a problem. One piece of content changes and, suddenly, nothing else is able to adapt around it.
Do you love how the demos look exactly the same and I’m showing different concepts? That’s great.
Audience: [Laughter]
Miriam: When I first came to CSS, I was like, “Oh, cool. There’s positioning. That will be lovely for layouts, right?” No.
We’ve got position relative, which does this. It just sort of pushes a box from where it was without changing anything about the flow.
How many of you use that for moving boxes around? Every once in a while.
How many of you use it just for positioning context? Yeah, that’s a little more common.
It’s very similar to transform. Translate, now, does basically the same thing, but hardware accelerated, and we use it for establishing context and that’s about it. It’s not really what we use for doing layouts, overall.
We also have position absolute, which is a lot of fun, but removes everything from the flow and we end up with these tightly coupled elements where, if my sidebar changes size, I have to manually change everything else to get it all to match, so that’s not going to work for layouts either. Although, I think, early on people were trying it and it didn’t go well.
That’s removed from the flow entirely based on the positioned ancestor. That’s why we use the relative. It’s useful for overlays. If you wanted an annoying popup that comes three seconds after I started reading the content, you can use positioning.
Does this demo work? It doesn’t. Yeah, so this demo also shows that same content. Great.
Let’s move on to floats. [Laughter] Floats are great for this. They float content left to right. That’s about it.
Audience: [Laughter]
Miriam: Good. They’re kind of in the flow. You can see here it’s pushing content out of the way, but it’s not pushing boxes out of the way. It’s sort of in the flow of the text but not in the flow of the boxes, so it’s in this weird middle ground. That makes a lot of sense for text wrapping around images. That’s great. That’s what we want. It works for that very well, and that’s what it was designed for.
In order to work around that when we were using it for layouts, which is most of my career, we used variants of this ClearFix hack. There’d be slightly different ways to write it, but we had the ClearFix, and I added a few styles there to show what the ClearFix is doing. It just adds that element down below the existing element, and everything starts to wrap around that. Although, you can see it still isn’t pushing other boxes out of the way. It’s only pushing the container, so that’s doing half of what we want there.
We now have this new flow-root that you can’t use anywhere. It’s the CSS solution to a ClearFix, so start using that or don’t because it’s not supported.
Audience: [Laughter]
Miriam: Another clever one, I first heard this from Nicole Sullivan, is overflow hidden. If you put overflow hidden on it and then suddenly it creates a new layout context and starts to flow around. You get sort of a ClearFix out of that.
The problem there is if you need overflow you’re in trouble. That has to be used carefully, but it can do some other cool things. It can also be used to create fluid columns, and Nicole Sullivan uses that in normal CSS, which is clever. Adding overflow also pushes things out of the way and allows that next overflow hack there to take up the remaining space and be fluid no matter what the size of the sidebar is.
It’s not the worst hack. We used it for a while. It worked. It was fine. But, it was a hack. It’s made for images left to right.
I love that it gives us flexible markup in nesting, so I can do this. This is -- I mean I don’t want all these divs, but JavaScript developers keep giving them to me. I’m like, “I don’t need more divs. I’m done. I don’t need them,” but they keep giving them to me.
The nice thing about floats is, all those divs just collapse, disappear, and I can ignore them. I liked that about floats. That’s a problem that I’ve been having with some of the newer techniques. I’ll look at that in a bit.
The other thing about floats is, I have to be very explicit about my widths. Floats don’t sort of understand the page in the way that some other layout techniques do. Every time I create a float, I have to set a width on it, whether that’s fluid or static.
There was, for a while, sub-pixel rounding errors. I won’t spend a lot of time on this because it was a problem in 2008, and it’s not really a problem anymore. I’m mentioning it because I think people still worry about it and, in a lot of cases, you don’t have to.
This was a screenshot of the differences in different browsers. What is 25% of 50 pixels, and they all different opinions. That’s not really the case anymore. You can see here there was a sub-pixel float isolation technique that was being used. It’s a lot of extra code, and it doesn’t do anything better than just what the browsers do now, so we can ignore float isolation if that’s something you’ve been using.
Backgrounds still do have sub-pixel rounding issues, so you can see that the columns are equal, but the background images are not lined up with the columns. That’s because backgrounds still do have sub-pixel rounding issues, so you might run into it there still.
Another one that became popular was inline-block that allowed us to line things up on the baseline. I think it was giving people -- oh, vertical centering was the other thing people liked about it. It’s a lot of work and there are better ways to do it now. Don’t even bother.
Display table, then, was used briefly, or still is used, is still available. This is using CSS to mimic a table layout. This is actually marginally useful if you don’t have access to Flexbox. It’s very much like Flexbox with more restrictions. But, Flexbox is supported everywhere, so I don’t know that you would need it. But, it’s a clever workaround. It allows you to do--
This is just with the display block. Then, if I tell them to display table, they go into a row.
With display table, you can’t use margins, so there are all sorts of little hacks that come as a side effect of using display table. I don’t recommend it highly. But, nifty. Great. Something we can use if we need it.
Let’s skip to the shortcut. Integrated grid systems and guides: this is a detour, a little bit, because it’s not really about the techniques of doing layout in the browser, but the tools that we’d build around it. You know a grid system has got columns and gutters. Then we tell elements to span a certain number of columns.
One of the first ones that I saw was Blueprint in 2007. I don’t know if there were earlier ones. A lot of people were picking this up. It was sort of the first open source CSS tool that I saw widely used, besides maybe Eric Meyer’s Reset. But, this is just a fraction of the code.
You can see they’re using float left and a margin right to create the gutter and then setting explicit widths on everything. The problem always with this sort of grid system is, you get to the last column and you suddenly have one column that doesn’t need a gutter, so that’s why that last margin right zero exists to remove that final gutter.
Classes are the API, and that makes sense. In CSS, it’s really the only API we have. We build tools in CSS and we give you classes to work with. It looks something like this We say, “Okay. This article is going to be a column, and it’s going to span 6 of 12, and it’s the last one.”
Around 2010, 960 became very popular, and it takes just a slightly different approach to fix that problem. They’ve put half a gutter on each side of each element, and suddenly it’s okay to have a half gutter at the edges. Great, we’ve solved that problem. We got rid of last.
Yay! No edge case. It simplifies the API a little bit down to grid six. Good work.
A little bit before that, actually, Nicole Sullivan had a different idea, which was, what if we just get rid of gutters entirely. It simplifies all the math. This is her entire system for OOCSS grids. That’s it. It’s just based on fractions. It assumes that you’ll add gutters as padding internally. That was the point. I thought that was really elegant.
You can see, at the point where these grid systems were becoming popular, a big part of the reason that they were so widely adopted, it seems to me, is because floating at that point required so many hacks that we didn’t want to write them every time. I remember you had to set every float to inline. You’ve got this zoom hack here and then the underscore width hack. There are just all sorts of hacks, and they were frustrating to repeat over and over and over, so we got these grid systems, and they help us get rid of/hide those hacks. We don’t want to see them anymore.
Here’s an OOCSS grid. It’s just based on fractions. It doesn’t really literally have the columns because you can break everything into whatever fractions you want, but you could still line it up on the columns. It looks similar to the others: unit size3on4.
She uses last unit a little differently. Instead of removing a gutter on the last one, she uses the overflow hack on the last unit, and that allows it to be flexible. You could have whatever is last in your layout be flexible even if the other things are fixed. Great.
These grid systems gave us shared browser hacks. We didn’t have to learn all the hacks ourselves. Consistent patterns, that’s nice. That’s something that we keep talking about now with design systems, with component libraries. How do we build something consistently? These systems helped us with that.
On the positive side, for some teams, developers can ignore CSS. On the downside, developers are ignoring CSS. That has advantages and problems.
Then these frameworks lock you in. It doesn’t really make sense that every site I build, every application I build lives on a 12 column grid. That’s just not reasonable. So, it depends.
This is actually a CodePen that does really nice things, but not today.
Audience: [Laughter]
Miriam: Check out my slides later. [Laughter] It really depends where you are. Are you MailForce? Are you InstaFace? Are you something chimp. I don’t know.
Well, how many of you are? [Laughter] No? A few.
I’m not. I’m working on a team of, well, six of us day-to-day, another owner who disappears a lot, but we’re a very small team. We don’t have big walls that we’re throwing over. We’re all talking to each other. There’s no reason that I need to build something that developers can’t talk to me about. I don’t have to build these systems that are shipping around the world the way Salesforce does, so I have different constraints, and I can build.
I’m building very quickly, from one client to the next, highly customized projects and it doesn’t make sense for me to have the same system for all of them. If I were working on Salesforce over the course of 15 years, it would make sense for me to develop much more structured systems that will go over the long term of the project.
I first picked up a lot of the ideas around this from Natalie Downe’s talk in 2008. I wasn’t at Barcamp London, but I saw this online, and I liked a lot of her ideas. Actually, still, you can find this talk online. It still has a lot of good information in it even though it’s so old.
I really liked her approach, and I realized it’s because she worked for ClearLeft. ClearLeft is an agency. They’re doing similar work to us. Her technique matched what we needed.
There were sort of all these big fights about which is the correct approach, and this is when I realized, oh, there’s not a correct approach. There’s the approach that you need for your circumstances.
Her idea was that we’re going to have consistent systems for building grids, but then we’re going to have custom grids depending on the project. That involved a lot of math. We’re sort of trying to do what Dave Rupert now calls Tiny Bootstraps for Every Client.
Dave Rupert, if you Google him, is a spy. That’s not the Dave Rupert I’m talking about. You want the other Dave Rupert.
Her system involved lots of questions. Is it going to be static? Is it going to be fluid, elastic, or some combo? Hers often ended up being this combination of elastic and fluid. They would scale down with a viewport but then have an elastic container that would then scale up with font sizes. It was very clever and adaptive before we had media queries.
She would figure out, are we dealing with equal columns or asymmetrical columns, how many of them? Where do the gutters live? The start of every project would be sort of going through this list. Then I would know what the system was to build each of these grids.
Yeah, very flexible. It did a lot of cool things. I liked her way of working. I liked her way of thinking.
The restrictions are defined in the project, so I’m not getting locked into some system that’s going to become a problem for me as soon as I want to customize. The API is defined on the project, so I can make it fit what I’m trying to do. But, the math was just ugly.
I was using this before Sass. I’ve put it in Sass here just to show what the math is. But, because it involved gutters, it’s just not pretty math. Doing it before Sass, I was just cutting and pasting these absurd numbers, and nobody knew what they meant. I’d have to leave a comment on each one and be like, well, this number 23.7288 is what it means to do one out of four columns. That’s absurd.
That’s when I built Susy. Susy was talking Natalie Downe’s approach, which again I’m allowed to copy; I’m allowed to steal. I took her approach, and I just put it into Sass. This was around the time that Sass was starting to get some popularity, and I just said, the computer can do this math for me. Great. I’ll just add a little bit of meaning to my code, make it a little more readable, and a little more maintainable. We can see now what it means, what these numbers mean, instead of just the random numbers.
Do any of you remember this initial Sass syntax with the exclamation points for variables? No?
Yeah, it was a while ago. My brother did the first commit because I didn’t have a GitHub account at the time. Oh, well. I wrote it.
The idea was, we could sort of create any grid system on demand. There are just a couple settings. I set them different ways depending on which type of grid I need, and then Susy gives me whatever grids I’m asking for when I want them. It’s not opinionated about what type of grid I’m going to need. This was sort of taking her agency approach and making it more meaningful, more accessible, more readable. That’s what I wanted.
The downside? Grid systems are still overkill. I haven’t used Susy in five years, and I recommend that you stop. I’ll show you how.
I picked up some of these techniques along the way. This is why I stopped using Susy. The math for a grid system like Susy is fairly straightforward when you write it out in the abstract. We want the target width and the context width. We divide the target by the context, and we get a multiplier that we can turn into a percentage. That’s how we’re calculating what a span is on the grid.
There’s our target. We want it to span six. The full context is 12. We do the division, and we get the result.
In Sass, you can write it just like this: the percentage of the target divided by the context. This is a grid system. You can ditch Susy, and you can use this. You can write percentage 3 of 6, percentage 6 of 12. And, as long as you’re not dealing with gutters, this will handle it. You can do the same thing directly in CSS using the calc function, which is supported everywhere.
It only gets complex once you add gutters back in. Gutters are what make the math fugly. If we can take out the gutters, we have pretty math.
As soon as browsers started supporting the box model, the border box model, we were able to move gutters inside more easily and started moving away from having gutters as margins. Moving them inside allows us to do simple math. Get rid of the gutters and your grid system is this simple. There’s no need for any framework to do it for you.
This is sort of the Natalie Downe CSS systems, plus the on-demand nature of Susy, plus the OOCSS lack of gutters and just fraction-based. Sort of take all those ideas and put them together, and you now have a simple grid system that relies on no external code at all. It works with any technique. It works with floats. It works with Flexbox. It works with display table. It works with grids, but there’s no reason to use it, so don’t bother.
You can add padding to elements as needed to give yourself gutters back. It just changes a little bit about how you think about backgrounds and borders between columns but, otherwise, it works pretty well.
The next thing that we started playing with once we had that, you can start adding custom properties, CSS variables. They look like this. Have any of you been using custom properties already? Yeah, a few.
What we do is we name the property. It’s an empty prefix, so that would be like -webkit- and, if you leave it empty, it’s your own. You’re just defining a custom property, and you can give it any value and, really, any value.
To call it, you use this syntax. The var function takes the first argument. It is the property that you want to call and the second is a fallback. There’s a lot you can do with that, giving a string of fallbacks if the value isn’t there.
Support is pretty good, but not complete. We have CSS variables everywhere but Internet Explorer and Opera Mini.
Using variables, we can create an even slightly more powerful grid system if you really need it. I haven’t really used this much because I haven’t come into situations where I actually need a grid system of this sort because Flexbox and CSS grids give us even more power. But, you can create something like that. Calc has, as I said, almost full support.
CSS variables inherit, which is totally different from anything a Sass variable can do. People always want me to add this functionality to Susy where they reset the size of things, the number of columns. They change that depending on a media query, and it just works everywhere. That’s never going to happen with a Sass tool. Sass doesn’t have access to the DOM.
It doesn’t understand media queries. It can’t do this sort of nesting and inheritance. But, CSS properties can, so I can change the number of columns, and everything will update. All the math will update.
This is an entire grid system, these three slides. This defines the scope of the system and then, on each element, we can set this up. This is just saying, “Okay, we’re going to do a calculation there to get the width. Then, if we have a width, apply it to the width property. And, if we don’t have it, fall back to the initial value.”
When we do this, if we set a span on columns, we’ll get the result of that math and the element will layout. If we don’t span or columns, it will fall back to its initial value. This is a full grid system, and you would just use it like this: --span 1, and then whatever type of spanning you want to do or what type of layout you want to do: floats or anything else. You can apply gutters to padding.
There’s a whole grid system written in plain CSS. It works wherever CSS works, which is most of the Web. It’s very little code. It understands the DOM, so it can react to context changes. And, it starts to establish these implicit relationships rather than--
No, that’s now what this slide is about.
You know, every time I give a talk, it doesn’t matter how many times you run through it, there’s always one slide that you’re like, “Who put that there?”
Audience: [Laughter]
Miriam: What we really want is implicit relationships rather than these sort of explicit grids, and that’s why I’ve moved away from these grids entirely even though there’s a nice CSS approach to doing it. It’s nicer if the browser can figure out how these things relate and do the layout for us.
Flexbox is the first thing that comes along that’s not really a hack. It’s very well supported at this point. It’s not a hack. This is actually what it’s built for, so we can use it. It has similarities to floats. It has similarities to display table, but it’s actually built to do the right thing and it makes sense.
It’s all about relationships. It’s about, how are we going to take up the remaining space after we lay out elements? It’s all about what space is remaining, how do elements relate, how are they going to flex in relation to each other? And, that’s perfect. That gives us that implicit relationship.
It’s element driven. What I mean by this is, on Flexbox, the content of the element and the settings you put on the element determine how it’s going to flex and layout. That’s different from a container driven approach like CSS grids. That’s one of the main ways to think about the difference between Flexbox and grids and when you’ll use which one. Both are very useful.
This is what it looks like. We can say we want it to flex. We want it to grow at a scale of two. That means everything with a two will grow at the same rate. Anything with a one will grow at half that rate.
You can set how fast is it going to grow, how fast is it going to shrink, and where is it going to try to start? You’re setting up an ideal width for your elements and then telling it how to adjust based on the space available and the other elements around it.
That allows you to mix. You can use ems and percentages, and you can mix all of the different units, the different ways of doing layout. You can have a static right column and then a fluid left column. You can start playing with those relationships in interesting ways.
We can also start doing distributed white space. We can justify the content space between, space around, centered, any sort of thing like that. We can align the content on a vertical axis, so we can get vertical centering.
It’s a single axis layout, so this means it still follows the flow and then wraps. This is unlike grid, so that’s another slight difference between them. This, we’re creating lines, and we can turn that. We can say, “Well, I actually want this to flow vertically and wrap,” so there are different ways we can adjust how it’s wrapping, but it’s just working on one axis. There’s no way to say, “I want this to line up with this.” That doesn’t exist. That second axis doesn’t exist. We can control the axis, but we only get one.
We can also align items. I mentioned that. We get equal high columns, vertical centering, all sorts of things that we’ve been asking for. It’s very nice. We can reorder things. Be careful with that for accessibility.
I don’t like that nesting matters, entirely, with Flexbox. Flexbox only works on sibling relationships. That means when the JavaScript developers give me so many nested divs that I don’t want, I have to add lots of Flexbox to get the logic to work the way I want it to, to handle every single part of the nest. That’s not ideal.
Display contents is coming, but it’s not there quite yet. I’m really excited for this. What display contents does is it says, “Ignore this div. Just make it go away,” and that’s going to be super handy for all these JavaScript frameworks giving us too many divs.
It’s a browser bug. Right now, browsers are also removing the div from the accessibility tree, and that’s a problem. That’s not the way it’s supposed to work. The accessibility tree is supposed to stay intact. Right now, it doesn’t, so that’s another danger here with display contents, just to be aware of. But, getting rid of divs - nobody cares.
Flexbox, we get relationships; we get control. It has poor performance on full pages, and that’s because it’s so element driven. Because it has to lay out every element and then figure out the relationships between them, it takes some time to load. It’s not highly performant for a full layout, but it gives us a lot of what we need. It’s getting us closer.
With a few minutes left, we can talk about CSS grids, briefly. OMG, OMG.
Audience: [Laughter]
Miriam: I don’t even know why I did the rest of the talk.
This is actual, real layout. This is designed for layout. It’s not anything like anything else that we’ve ever had. This is actually layout, actually in the browser, actually working the way that we need it to.
There’s the “Can I Use?” language isn’t loading, but I think I pulled it up in case. Maybe I didn’t. Let’s see if it loads.
Oh, right, I can’t click on anything. I don’t know why that is.
Support is fairly good, but not in IE yet. It’s got a few other dark spots, so it’s not totally supported, and it doesn’t go back very far depending on how many browsers you need to support back. You can look that up later.
There really is nothing like it at all. It’s a totally new way of working, and there’s a lot of power to it.
The spec can be very complex. And, if you read an article that tries to describe the entire spec to you, you might get confused and bored. Ignore it. There are other places you can learn. There are some very quick ways into it.
Grids are defined on the container so, like I said, instead of being element based, they’re contained defined. It looks something like this. We say, “Display grid.” We tell it how many columns we want. This is the syntax for equal size columns, but we can do lots of different things there.
You’ll see this new fraction unit. I’ll talk about that in a bit, but we can add columns and gutters, and say how we want rows to automatically fill in.
There are parts of this you can set column and row sizes to be auto. In some ways, that takes us back to an element driven approach. It respects the flow again. We have this flexibility of saying sometimes we want the container to define how the layout is going to look, and sometimes we want the elements to define it. That gives us a lot of power.
The fraction unit, these three units can be confusing. The percent unit defines a fraction of the total space, so the space available. If we say we want 50%, it’ll be a fraction of whatever space is available. That could be it’s just the size of the parent element.
VW gives us a fraction of the width of the viewport, so that’s different. It’s not the available space in the container. It’s the entire viewport. That’s useful for other situations, but then the fraction unit gives us something different. The fraction unit is the percentage of remaining available space. Once everything else has been laid out, the fraction is very similar to flex grow or flex shrink. It works in the same way with one fraction and two fractions. It’s how something will flex to take up remaining space.
All three of those are useful. They have different uses. They’re all, in some ways, percentages, but percentages relative to different things.
The other thing that caught me a lot early on, when you write one fraction it assumes you mean minmax(auto, 1fr), so it’s going to never be smaller than the size that the content wants to be on its own. If you really want something that will flex down below the size of its content, you need to say minmax(zero, 1fr) to let it know, “No, really, I want this fraction to shrink as well as growing.” This is sort of a flex grow versus flex shrink there, yeah. I use minmax(zero, 1fr) quite a bit if I want my columns to shrink.
Grids are defined like this. We’ve got indexed lines. It starts at one, counts across the columns, counts down. We also get negative indexes. From the bottom and from the right, we can count from negative one. Those negative numbers go from the -- there is an implicit grid and explicit grid. The negative numbers go from the explicit grid. There are some confusing things there but, simply, those numbers.
We’ve got columns. We’ve got gaps. Then we place things very much the way that we did in a grid system. We can say, “Grid column go from line one to line four. Grid row go from two and then span two,” and we can mix and match these different ways of playing things out. We can overlap objects.
We can also create named grid areas, which is just a lot of fun. They can also overlap, which I don’t show here, but we can draw this ASCII art of our layout. The only thing to remember is you can’t do an L-shape or a T-shape. Everything has to be just boxes. That is the entire layout from this slide right there in just a couple lines of code. Everything goes into place. It works great.
I was going to show an example.
Whoops! That’s for later.
I just redid my site using grid, and it gave me lots of flexibility.
That’s slow updating.
There are various -- I used it nested, and then you can see some of the grid layout there. That’s all using these named lines, named columns. You can look at that more later.
This is getting us to what Jen Simmons is calling Intrinsic Web Design as a next step after responsive Web design. It involves all these various pieces. There’s a link there to an article about her first talk on it. It’s worth looking into. It involves using all of these approaches and only occasionally needing media queries because there’s a lot that we can do with grid, with auto-layout.
We’ve started doing this, combining CSS variables with CSS grid. We pass in a start time and a duration, and we get this schedule. It automatically lays out because we’re passing in variables that we know how to manipulate in the CSS, and then we can lay them out on the grid. I have an article about it at CSS Tricks that shows it with graphing. We’re just passing in a single variable for each of these, and that variable is being used to define the color and to define the height.
There are lots you can do with starting to put these pieces together in new ways and get especially dynamic CSS. It works in two dimensions. We can line up columns and rows. There’s flexible ordering of the markup. Nesting still matters. We’re waiting on display contents, again, also sub-grid, which is not supported anywhere but will allow internal elements to be part of a parent grid. Those work in slightly different ways, but that’s too much to get into here.
It’s all kinds of cool shit. There’s so much we can do with this, and everybody has just started playing, so there’s not a set right way to do it yet. There’s a lot of help you can find out there.
Once we have these pieces, we can start to clip them together. Snap, snap, snap: we get a website, and we remember to wear our helmet because there are dragons.
If you run into dragons, go to gridbyexample.com. This is Rachel Andrew and Jen Simmons’ website. They give samples of many common layouts and how you would build them with grid; also, how you would do, like, an image gallery, et cetera. There’s a lot there.
They also give you fallbacks. You can use asset ports for those. Avoiding grid systems, start with CSS grid. It’s the one that’s built for this the most. That’s the place to start. It makes layouts so easy that you have time to write the fallback. It’s okay that it’s not supported everywhere. Start with grids. Learn grids. Write a fallback. It’s worth it. It’s going to make things too easy, and we’re all going to lose our jobs.
Fix the box model. Stay in the flow whenever you can. Think dynamically about the relationships between things. Remove the gutters. That helps us solve the math, unless you’re using CSS grid, and then it does gutters for you.
It has great power. You can do anything. The world is really ready for more than 12 columns.
If you want to take it too far, I did rebuild this because I was inspired last night. This is generated in CSS, completely. You can see just a lot of divs and spans. It reflows to the container. That’s live. I can link to it if you want to see how that’s done.
Yeah, I’ve also built Susy completely out of just CSS variables. If you want to play with something else, don’t use this. It’s terrible. There’s no reason you need this, but it does work.
The Internet is awesome.
Thank you.
Audience: [Laughter]
[Applause]
