Don’t Use My Grid System

Nov 28, 2017

–

10:30 am

–

Alamo Drafthouse New Mission

Miriam Suzanne

Designer & Developer

Oddbird

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 grid-systems work for you when you need them.

Transcript

Una Kravets:

Our next speaker is Miriam. She came to the conference thinking, oh, I'll get to attend and watch the talks and learn some things and just chill. Sorry.

(Laughing)

Una:

It's not happening. So, while she gets up, I'll talk a little bit about Miriam. I met her back in the Sass community a couple of years ago. She was really involved there. She wrote a grid system. She's talking about, don't use my grid system. So that will be an interesting talk. She's also an author. She's written a book that's really interesting. Not a linear book. It kind of goes in a non sequential order. You can kind of pick out different pages and read it however you want, really cool. Really creative.

And, she really put herself out there to give us this talk, as a surprise. She found out maybe I don't know 45 minutes an hour ago, that she's doing this. So, real props to her…

All right.

Everyone, give a round of applause for Miriam.

(Applause)

Miriam Suzanne:

Oh, great, I just hit am I am I audible? No? All right. I'll just keep talking until. There I am.

(Applause)

Miriam:

Great. Thank you. Here I am. Yeah. So, is that large enough? So I bump up the size at all? Good? All right. So, I'm here to talk about so, I'm not going to talk about this because I had no time to prep. So, let's do that. It's just another grid system.

(Laughing)

Miriam:

That's it. That's all. Thank you.

(Applause)

Miriam:

So, instead of just talking about grid systems, I'm going to go back and talk about the history of the layouts, a little bit of a flashback if you remember cables. How many of you use those in production? Yeah. All right. I got started out in 94 with my brothers.

We started a company, it was right at the end of tables. We were just starting to use CSS. I picked what I could find from tables because that seemed appropriate. We all know tables are for data. There were some problems with that as a layout tool. Strict, non linear mark up. Limiting styling. There are things you can't do with tables. Modifications, accessibility nightmare when used for layout.

Also, legal problems so if you're not do it with the robot lawyers. And then, the problem that Sarah talks about a lot, code as communication and tables don't communicate. We can't look at it and understand what we're seeing because we end up having things out of order.

So, we're trying to figure out layouts that are meaningful to humans and machines. That's sort of the goal is can we make it so that the machine understand it and can people look at it organized and table layouts destroy that. This is all old, you know this. Get rid of tables.

So, chapter two, CSS is awesome and you oh, that's it.

(Laughing)

Miriam:

You've all seen this. CSS is awesome. This is a feature and you need to know that. If your design tool couldn't do this, you would be pissed. If you asked the a small box with large text, it's going to go over the box. That's something a design tool should be able to do and CSS is a design tool and CSS can do that. If you don't want that to happen, you have to be less explicit and that's part of how the web works.

Just because CSS is declared, it doesn't mean it's static. Things are going to change depending on various factors and if we don't prepare for that change, we get too explicit and exact font sizes and layout sizes, things are going to start to break. It doesn't mean simple or static.

We're building dynamic relationships. Trying to think through, how are things going to change when the content changes? How is height and width going to affect things? When the viewport changes, ratios and small screens to large screens, when the context changes, where are the cascade of which it moves around? We're trying to design implicit relationships that will move in relationship with each other rather than the specific look because we don't know what the client's browser is going to be. We need to design for the relationships rather than the specific outcomes.

Client has control over the web. And that's not just your boss. The client that hired you and you. That's the client's side, the browser. Because the web looks something like this and you can't design for each of those.

Which is a good reminder that you're not design for one, it's for the whole pair. There are a lot of people out there that are different.

Let's talk about general layout concepts because this is a layout conference and that's what we're getting into.

(Laughing)

Miriam:

People don't understand the box model. You've probably seen it before and it's broken by default. This is the default content box model. I, e, dot right. They fixed it and it's wrong now.

So the width and height you set. And it gets confusing if you're trying to do a layout. So, this has some limited used. There are times that that's useful. This is the size of my content, now please expand out according to that. It's useful on certain types of containers. This is more helpful, being able to define the height and width of an entire box and have content in that.

So, very first thing I do when I start a new project is I fix it. This is just a couple lines that just fixes the box model. You may have also seen this version of it, which uses inheritance. There's a reason box models don't inherit. There's a reason margins don't inherit. Layout elements shouldn't inherit. Children elements don't always need the same layout as their parents, if that makes sense. There's very limited use of where you might want to use the box model if you're trying to switch it for a section of the site. Generally, I wouldn't inherit the box model.

The other thing one of main rules is to go with the flow. Stick with the flow whenever we can. So, the flow is this. When we have several items, they stack right next to each other. If this one changes, the others move to give it space. And that's the flow. And it's useful because it helps us design implicit relationships rather than explicit layouts.

And, using the flow helps us avoid tightly coupled elements so I components can respond to unexpected changed around them without being too set in their ways. So, if you took all of those elements out of the flow and placed them statically, suddenly, when this one changes size, for some reason, the content got bigger, somebody put a bigger header in there, nothing else moves and we have to fix the rest of the page because there was one change here. It often means it's a more fragile layout and we're going to have to change more things when we change one thing.

You can see, this is demo. I can show a sidebar. I can make it inflow. And then you can see the difference there. This actually shows where it can be useful if you want to see two things at once, put them in the flow. If you want to overlay the other, take it out of the flow. When we take it out of the flow, we have things that aren't actually part of the layout with other elements. What happens if you need to make it bigger and if you set too many explicit relationships, making them bigger breaks the layout and you're in trouble.

You definitely should make the logo bigger.

So, positioning. When I first came to CSS, I thought obviously, we're doing layouts positioned. Position is how you would do a layout. It doesn't work. Position relative pushes things around. Does anyone use position relative for anything other than setting up context? So, at this point, most of us if we need to do this, we use transforms. But position relative's there, so you can transform, translate and get some other bonuses with that.

So, really, you're only using position relative for establishing context for position absolute, which we can use more often. This pulls things out of the flow and becomes useful mainly for overlays and other things, you can also position the flow or use the mix. Really, just for overlays. Once we start positioning absolutely, we have to force things around.

So, floats. This is what we used for years. They're great at pushing an image to the side and letting text wrap around it. They do that really well. It kind of flows, it's like not really part of the flow, but it's kind of part of the flow. There's a few things that are flowing around it, like text and then this other floating element flows around it, the container does it and the box does it. So, it's sort of a weird mix and it's perfect for doing this. We want the text to go around it. Great. Done.

But, if we want anything else around to go around it, we use a Clearfix, there's classes or whatever you like to use. There's a micro one there. And suddenly, this is all this does, I made it visible. It just adds an element that says, hey.

We now have display flow root, which is, like, Clearfix built into the browser and by we now have there's no chance you're using it in production. I don't know. It's great they have it for stopping. We have a way to actually deal with them.

The other little trick is overflow hidden. It does some interesting things when interacting with floats. It comes with risks where, you know, overflow is hidden and that can be risky. But using the overflow, this other element now flows around it and it the container also does, so overflow hidden is tricky when you get into floats. CSS uses it in the last column where it's fluid.

It's not the worst hack. We've used worse hacks. So, great. The the markup is pretty flexible. I like that. I can have weird like, I can all these things that JavaScript gives me and say, hey, top giving me these. I don't want them. I can have all of them there and the floats disappear because I don't have Clearfix on them and that's handy.

Downside, you have to have widths because floats, otherwise, kind of don't know where they're supposed to go and that sort of breaks the idea that we want implicit relationships other than explicit outcomes. > Around the sub pixel rounding problem, the problem with this, in 2008, this is a demo by Tom. You can see, if you have 50 pixels into four, what do you get? You get different ones. Some people came up with a clever way of doing sub pixel isolation to make those problems go away. The red lines, appear, the browser's handling it better than the sub pixel isolation technique. If you've been using that

Background still have sub pixel images. I don't know why browsers don't care about this issue in the background. But, there it is. That's not going to affect your layout or design.

After people started doing floats, inline blocking was used briefly. I wouldn't bother. It's invasive. There are lots of weird hacks you have to do, changing font sizes, getting rid of white spaces. It's more bother than it's worth.

Display table, I saw people using this. I think Jina was the first one who showed it to me. I tell them to act like a table and suddenly they lay out a row and it's like an early version, limited flex box. So you get some of the browsers with tables, you don't get the semantic issues and you can do flexible layouts and there are nice things there, sort of the low quality flex box.

There's no margins on the table so you have to switch for that. There's all sorts of weird quirks with it.

Kind of nifty, still a hack. Okay, we can use that.

That's when grid system suddenly became a thing. This idea that we have 12 columns and gutters between them. So, I'm going to gutter there. We can try doing this on the web, let's make systems that will do it. We'll expand the number of columns and gutters so there's a span of six and the first one I remember and as far as I recall, this was the first open source CSS that I saw used on a massive scale. Lots of people started to use the same libraries. I don't know if there were big ones before this. But this was sort of the first big open sourcing of CSS tools.

Some code here, class face, spans floated left. Margins on the left and you have to remove the margins on the last one. They're on the right of every column and at the end, you have to say, this is the last one, remove that gutter.

Classes are the API. They're the only one we have available to us in CSS. We have make sure our CSS classes are being taught, that was sort of the only option.

And then you use it last this. We've all seen that. You stack the classes and get the layout. 960 came out later. They said, let's put the margins on both sides of this and that gets rid of the last problem. Great. We simplified it a little bit. Now we say grid 6 and we get what we want. Clever, similar. Object oriented CSS was a little bit for that, Nicole Sullivan, who's here. I think this is the entire grid system in CSS so you can see it's much more compact. She got rid of the gutters, which simplifies the math way down and I think is the most clever solution and is what you can use now to avoid grid systems if you still want something like grids.

So, do you have margins and fractions? You can span what's there and use the gutters. It is actually a hack and then last unit in her system gives you that flexible overflow hidden last element.

So, it was nice see these come out. We have a lot of browser hacks. We're doing ten different hacks to get rid of, what? The double margin bug and the display inline. There was sort of this chunk of code you had to do. And so, for instance, it made sense as a way to get rid of all of that and say, simplify it down and get it on a system and we'll go from there. So, that was nice to give all the patterns. Hey, I'm on topic. Thank god.

(Laughing)

Miriam:

On the plus side, developers can ignore the CSS. On the downside, designers started ignoring CSS.

(Laughing)

Miriam:

A downside, maybe, that you'd got a third party logging you that you didn't come up with and it's not designed for you specifically and that can end up locking you in, as soon as you want to do something that the grid system doesn't have a plan for, you have to sometimes rip it out or just break it or find out ways to rip it out. Often when you get to the edge system, it can be difficult.

So, it depends. So, it really depends on what your problems are and how you're going to solve it. Are you Mailforce, are you InstaFace? You're going to have to solve different problems there. Are you a small agency doing client work? Are you running the pattern line for Hillary For President? I'm working on a small team. Everybody's talking to each other and we're working on new products for mid size companies and they don't have the same concerns. So, we have different constraints and different abilities so we don't have to deal with the same things.

I saw this talk by Natalie Downe and I thought it was inspiring. She was doing work at a small company doing the fast projects. We needed not one system that does the same, but a way of thinking about systems that we could adapt to each product and that was more helpful than the toolkits themselves. So, consistent ways of doing this and languages for it, but actually customize it.

Yeah, basically Dave Rupert's Tiny Bootstraps For Every Client. I looked him up and there was a spy. I don't think he's a spy.

So, why go for a different technique? We started answering questions about what kind of grid do you? Is it going to be static or some kind of combination? Symmetrical columns or asymmetrical columns? How many? Where are the gutters. Can we move the gutters? And are they responsive? Her system involved making everything inside fluid and then putting a container on it and that meant you were responsible for view and font sizes. It was pretty clever. Sort of adoptive before responsive trademark.

Yeah, fluid grids.

I like that they the project defined restrictions. It was a system. You designed a system for your product, but you redesigned the system for each project so you were coming up with something that would come up with that specific site.

Project designed API, you can make it depending on the product and line and size and how it's going to be used.

The math, though, is ugly. This is how you would do her system if you did have fast. At that point, because you didn't have Sass, we were just copying and pasting in these numbers that make absolutely no sense and it's ugly as hell and I was just sitting there with a calculator doing this over and over do get it to grid system. The only reason it's complex is because of the gutters.

So, I just wanted to make that prettier. Sass came out, I put a little framework around it and I got somebody doing that for me, great. That was the whole idea around it, taking that system and Natalie's system and putting it into a nicer package.

This was the first version of it, if you remember the old Sass that's ugly. My brother had to do it because I didn't know what it was. I'm sorry.

(Laughing)

Miriam:

You can sort of just develop any grid system. You can create 960 pretty quickly. You can create CSS. You were just creating for the project, you have what you need.

Grid systems are still overkill.

Yeah. Sorry. I didn't prep for this talk.

(Laughing)

Miriam:

Am I talking? Great.

(Laughing)

Miriam:

So, I think grid systems are overkill, especially at this point. Now remember, this is the section where I teach you how to avoid them. Great. Grid systems, if they're fluid, that's the only kind that have the difficult math. And this the math problem you're doing. Target, that's the width that we want them to have, divided by context. That's the width that we have be default and we get the multiplier. We multiplier that and the width that we want and it's just that math problem over and over again. That's not highly complex algebra, but it's repetitive. So, the target is our span. The context is how big could it span.

And in Sass, we can simplify that axes to this, percentage is target divided by context. If you don't have gutters in the way, that's the whole thing. If you say it's span 6 of 12, you could have said without any library, tell Sass that you want percentage 6 of 12 and you'll get what you want. There's a grid system. That's the whole thing you need. You don't have to take the CSS approach where you don't have gutters in between because they mess up the map.

If you are happy using calc, you can use target and context and you'll get three columns of 12 in the grid system. You don't need my tools for this. Just don't fuck up this thing because gutters are at this point, we can finally work with gutters. When I say, finally, it was 2007, we can put gutters inside because we are able to fix the box model. The reason we started passing the margins because of the box model program. Now that it's fixed, we can get rid of the gutters and take out the math and just do this. There's a DIY library.

It's Natalie's idea combined with Nicole's idea.

It worked with any technique. You can put that width on a larger or on an element or can use it with floats or flex box or display table. You could use it with grids, but it wouldn't be worthwhile. And, you can add pattern where you need it.

Starting to play with custom properties, which I started playing with earlier custom properties look like this. They're basically an empty browser prefix. And then you can give it any name and you can give it any value and you have your own custom properties and you can access it using the bar function, bar property 1. And you can fall back in case that property is set.

Support's pretty good for this. Unless you're dealing with older ones, like Internet Explorer. There's very good support. You can use something like this. Here's a grid system where you use your own language. The variable span divided by the variable columns divided by 100%. You can put it in there. It's supported even more.

And we get inheritance, which is something that no Sass grid system can do because property's inherent. So, I can say, there are more columns available at a larger size and then that will triple them to everything. Everything will span when those new columns are available and that variable will change value at different sides or context, which is very handy.

This is the entire grid system, if you want something like this. You can sort of create a mix in with it where you tell the width to use that value if it's valid and so if nothing is set, the width won't be set. It will use initial but if you set a span in columns and the math works, you'll get a new width from it and you can use it like this, just span one and again, you can use that with any system or technique for layout or floats or text box. You can do the same with gutters.

So, that is plan, old CSS. It's very little code, very light weight. It understands the volume. We've got we still have sort of explicit grids, which I still think is overkill because, really, I don't want 12 unequal columns, I want relationships that are going to change depending on various context. We would rather have implicit relationships and we're still dealing with explicit one.

Flex box is the first to play with implicit relationships. Support there is very good. You can use it a lot of places. It's finally not a hack. This is the first time we've talked about anything that's not a hack. It's a lot of fun to play with, if you haven't already. It's like floats mixed with display tables, like a cross between the two. It's relationships about setting, how big is this compared to this other thing? How do they change sizes in relation to each other? Defining implicit relationships as the entire one. I can say, I want this one to grow twice as fast as the others and I want them to shrink at the same radius as others. So, it would be, you know, you could set it to three and one's at two and sort of grow in relation to those ratios and you can set that to, oh, an ideal size and then I'd like to grow and shrink from there. I like that. You can say, here's a suggestion and then here's how to move. Here's the relationships.

We can start doing things like justify content or space between or some space equal. We can distribute white space, we can do vertical centering, equal high columns. What I mean by that is sort of like floats, it just they stack up in one direction and then you cut to the next line and then they stack up in one direction. You're not doing anything on the vertical access. You can change which axis you're dealing with, you can do it in either direction. There's no alignment across the rows there. You're only dealing with how they flex.

You can do row reverse, which lets you change which axis you're on. You can use vertical centering. And you can change the order. You can say, actually, I want this to be first and something else that's in source order. Nesting matters too much. This is the big downside to floats. They are actually away because flex box only working with immediate siblings.

It gives you lots of relationships and control.

Flex box has poor performance on full pages. It has to figure out the layouts solely based on the content floating inside of it so things move around while things are loading. It's a little bit slow loading that up. It works better on internal levels.

And then, finally, we get to CSS grids. Yeah, O M G. I don't know why they this isn't really this is game changing. This is actually real layouts in the web, in the browser. I've heard people saying, oh, it's just like tables. There's you can't there's not another way. There's no nothing can do grid like grid does grid. So, this is really interesting. It's sort of all at once in most of the browsers. It was, like, sometime in March. I was like, all the browsers have grid, that's fun. It's not universally supported. There's nothing like it.

So Spec is pretty complex. Some of the talks you'll hear, there's a lot of power in there, there's a lot of options but it doesn't have to be complex to get started. There's a lot you can do with a couple, simple ideas. You can use display grid to set up a grid. You define the grid on the container element. So, grid columns and repeat 12, 1 fraction. You can set how it creates rows. You can set gutters between things because you're not doing math. Someone else is.

A quick thing to know about the fraction unit. That's new for grids. The fraction is the total space. Viewport defined a fraction of the viewport so percentages would be the space available, so that's within whatever container. Viewport width would be the percentage of the full viewport and fraction defines a percentage of remaining space so it's in this layout, we have this much extra white space, what should we do with it in? Fraction reflects row and allows you to say how much of that remaining space should we use or how do we relatively flex that space?

By default, one fraction means minmax. It's very common, they'll need to set minmax zero, 1 fraction to give a min width to it for it to start from so it's not thinking it has to stay a minimum of a huge amount.

It works like this, you've got grid lines. The first one is 1. Then you've got grid line 2, 3, 4, five. You have negative 1 index, so you can say negative 4, 3, 2, 1 and attach something to the end. You've got column and row gaps, those are the three columns of rows.

Those are your gutters. And then you can start placing items in the grid using this syntax which looks a lot like spans. So, first if you're telling it where to start, grid column 1 will start at the first line and then it will go to the fourth line or grid row, we've got two. It will start at the second line and we can span two and it'll end up wherever we end up with, addition whatever math things.

So, that's all it is. You can do the same thing with negative indexing. This is your beautiful layout, which I made for you. Which isn't that great?

(Laughing)

Miriam:

You can do it.

For getting started, you have name grade areas because you likely unless listened, you've got a gutter and a footer. You can use something like that very quickly with grid, this is the whole layout. You just do this ASCII art of the layout. I want there to be a header up top and footer and footer and you can tell each element which area it goes into. So, with just that code, we get the layout that we want. > So, I started playing with, with this on a project recently, using custom properties with grid to pass in raw data and use it to do a layout. So, this is it. The scheduling app. We have a grid row for every minute of day or, a grid column the every minute of the day and then we pass in this this one starts at 1:30 and it lays out because we've put that into the grid column start and grid column.

I have CSS tricks using raw data. I did this with a definition list. You could do it fairly simply with tables. The colors are controlled by the data. It's a really cool. On properties, you pass raw data into your CSS and you can do a lot.

We finally two dimensions. This works on both axes. We can align things in columns and rows, with the whole way of thinking about the layout. We've got flexible markup order, we can backfill space how things fill in the empty spaces or put in whatever we need, put our footer first because that will be accessible.

On the downside, we're waiting on properties that will fix that. One is display content, which will allow a container to disappear and just promote its children or sub grid will allow grandchildren elements to access their grandparent grid, which is not possible right now. So that's a little bit of a limitation, at this point. But, the fixes are coming.

There's all kinds of cool shit you can do in here. You can have it autofill, backfill, you can name the lines and then have sort of implicit areas that overlap. You can define autogrids and generate a grid for you based on constraints, based on even the content that's in them. It's very cool. If you want to see more of this, go to gridbyexample.com. They have done amazing work here. They've given you layout templates you can copy and paste and use the code for old browsers. You can get your entire layout from their website.

We get a website. We have dragons and oh, I guess this is the use supports for fallbacks. It works. It checks the validity for whether the browser understands that statement. If it understands the display grid, it will do what's in there. You'll want a fallback out there, because it also supports the grid. And then the grid code inside.

And for me, grid made things so easy that it's like you don't the fact that I have to do a fallback for it, I'm like, so what. I spent five minutes designing the layout. It's not like I'm spending several hours on both. The grid really makes things easy and we're all getting fired.

(Laughing)

Miriam:

So, I just start with CSS grid now. Doesn't matter, start with grid. It goes quickly. You can get the layout very fast and very powerful and then you can start figuring out how it's going to fallback. Yeah, I said, we're going to get fired.

Fix the box model, that's still useful. Stay in the flow. Think dynamically, how are these relationships working? Take away the gutters, that helps with the math. Remove the grid math.

And, I had to put this in there for being tired of 12 column grids. I know we need 24.

(Laughing)

Miriam:

If we want to take it too far, I figured out how to use custom properties to rebuild in plain CSS. This is not something you should ever use. Like, if you were already not using Susy, don't use this. It's fun to know it can do this. You can basically create functions. There is one limitation which is every function works once per element. You don't need this. You can build that. If you need grids and you want to use a system like this, you might as well do the three line. You don't need the old one here.

There it is. It works. So, great. I'm sorry. Web. Thank you.

(Applause)

Una:

Thank you. Thank you so much for that talk. That was great. Give her a round of applause.

(Applause)

Una:

Thank you. So, my first question is, about the process for layouts, now with grid, what does that process look like?

Miriam:

Testing for fallbacks the process is basically like I look at the design and figure out if there are uses for it farther. Are there layout areas on two axes that are going to need something like this? I do the CSS grid work and then I move on to giving the fallback. There's not a good way to tell it to turn off your support of grids. So, you kind of have to go through and common out all of your display grid copies. You don't have to get rid of all your grid code.

You have to remember, you just change the display property and change which property you were using.

Una:

Do you use any of the applications?

Miriam:

Yeah, sometimes.

(Laughing)

Miriam:

The fallbacks, you're basically doing the same thing, setting up rules.

Una:

I like that you mentioned the new template area because that's basically your design. I like to use emoji. You can align it. But, I like doing that.

What was the weirdest thing about CSS that you discovered?

Miriam:

Yeah. The weirdness. It was probably figuring out layouts. They were absurd at that point. CSS, you're like, why am I using this flow thing? Why is that what I have to use for doing a layout?

Una:

Yeah. And then I also want to ask you what your favorite CSS hack is of all of them?

Miriam:

Well, of all the hacks, the Clearfix is probably the most useful. That's really practical and that's the one that I still use. I think most of the other hacks

Una:

All right. Thank you, Miriam.

(Applause)

Video

Sketch Notes

Transcript