It’s time for a gridtastic afternoon at An Event Apart Seattle (Special Edition). Kicking it off is Rachel with her talk Graduating to Grid. Here are my notes…
When Rachel spoke at An Event Apart last year, grid layout was still on the horizon. Then in March 2017, Chrome, Safari, and Firefox all shipped within weeks of one another. Then at An Event Apart Seattle last year, Edge announced that they were shipping too. So within a very short time, CSS grid got really good browser support.
What’s it like being in the middle of a launch of a big new CSS feature? Very quickly, we had 90% browser support. Suddenly it wasn’t just Jen and Rachel talking about grid—everyone was talking about grid. It involved a lot of email. Alas, Rachel couldn’t answer all those questions (she has a job, after all) but she did start collecting those questions. She found that people were excited, confused, and scared. So much to learn!
Rachel put out a survey and asked “How do you feel when a new CSS feature is announced?” Responses included “Oh, no!” and “Tired.” Some of us in the audience can, no doubt, identify with that.
People started emailing Rachel asking for her blessing. Were they doing the right thing? But Rachel can’t tell you what to do. She’s not in your situation. But she can help you develop the skills to make those decisions yourself. She can offer you confidence. She wants everyone to be the amazing CSS layout person on their team. That’s what this talk is for.
First of all, you need to understand CSS. There’s no shortcut here. But that doesn’t mean you need to learn every single property and value by heart. That’s not what CSS is about. That’s like learning phrases in a foreign language—knowing the words for “coffee” or “beer” doesn’t help you grok the language. It’s the same for CSS. There are some core ideas that help CSS layout make sense. You probably have an understanding of them already, but maybe you don’t have the right words for them.
At the heart of this is the first word in the language we’re talking about: cascading. You need to understand the (much-maligned) cascade. And you can’t talk about the cascade without encountering specificity. The MDN page on the cascade and specificity is a good explanation.
Then there’s dimensions. In any language with a horizontal writing mode, the inline dimension runs left to right or right to left, and the block dimension runs down the page from top to bottom. In vertical writing mode, it’s different.
In grid, we talk about the inline axis as rows, and the block axis as columns.
Sizing matters. It has become obvious that no one understands how big anything is. We’re living in a world where you don’t control the size of things.
In older float-based systems, everything is given a percentage. As long as our percentages don’t exceed 100%, everything’s okay. And we’ve got wrappers to keep things within rows. We end up with something that looks like a grid. It involves us doing a lot of calculating. You can do this with flexbox too, but it’s much the same—figuring out percentages. These past layout methods create the appearance of a grid by lining things up.
With the new layout, we don’t have to do the calculations. We need to understand CSS intrinsic sizing and extrinsic sizing (say that ten times fast).
With a regular div, you’ve got a block-level element. The box will stretch as far as it will go, to the viewport width by default. You can specify an intrinsic size by saying, say, width: 500px. That makes 500 pixels wide in the inline direction.
However the content of the box has a size. The maximum size of a string of text is how much space it would take up if it never wrapped. The minimum size is the space it would take up if everything wrapped. Now in CSS we can say width: min-content or width: max-content.
Let’s say our div was in a container that had a width of 20em. The max-content of the contents of the div (which is more than 20 ems) is wider than the width of the div and so the content overflows.
In flexbox, let’s say we’ve got a flex container with four items and we’ve declared that each one should take up max-content. Each item takes up as much space as it needs. Each one uses max-content as its starting point, and then width is removed to make all four items fit in the container. flex: 1 1 auto will distribute space according to the content. flex: 1 1 0 will distribute the space equally (you’re effectively saying that the max-content is zero).
It’s similar with grid layout but with slight differences. Flexbox is starting from max-content and taking space away. Grid is starting from min-content and adding space.
Those content keywords aren’t well supported outside grid layout. They’re safe to use for track sizing.
grid-template-columns: repeat(4, min-content);
That will make everything squished down.
grid-template-columns: repeat(4, max-content);
That one will probably cause an overflow.
grid-template-columns: repeat(4, fit-content(15ch));
That one will make 15 characters an upper limit!
You can make a grid layout using fr units and grid-gap. No need for figuring out percentages. You can use percentages if you like though. You can use percentages for gaps, for example.
Remember, you don’t have to stick with a twelve column grid. Slack started with that because it was what they were used to. Then they realised they didn’t have to.
Imagine a media object pattern, where you don’t want the image to ever be bigger than 300 pixels.
grid-template-columns: fit-content(300px) 1fr
As Rachel creates more layouts with grid, she finds she’s using less and less CSS, which is great. The browser is doing the work. That matches the reality of the situation where you don’t know the size of your content in advance—long titles, and so on.
This is not exciting. But it will let you do exciting things. Learning about sizing is the CSS equivalent of eating your vegetables or getting enough sleep.
“Why is all of this so complicated?”, is something Rachel hears a lot. It’s like all software. People want all the features, and they also want it to be easy to use.
More capability and flexibility means more to learn. But it’s worth remembering that you don’t have to learn everything at once. Once you switch your mindset to the grid way of thinking (where you define things on the layout) it gets easier. It’s all just lines.
If you name your grid lines, e.g. “content-start” and “content-end”, you automatically get a named area called “content.”
It works the other way around too. If you create an area called “content”, you automatically get lines named “content-start” and “content-end”.
You don’t have to use any of that. You have real choice for the first time.
A lot of the assumptions we’ve had in the past about what isn’t possible don’t hold up any more. You can now ask, “what’s the best way to do this?” instead of asking “which patterns does our framework give us?”
Well, that’s fine, you might be thinking, for shiny new things. But what if you’re building things that have an old codebase? Rachel asked “How old is the oldest CSS in your project?” in her survey. People have code that’s over ten years old. But old CSS in your codebase doesn’t mean you can’t use new CSS. You can design components or a section of a page using a new technique. This is where understanding CSS comes in really useful—the cascade, especially.
Rachel shows an example of a page made with Bootstrap. She drops a grid component into that layout. It works fine. Nothing explodes. They coexist side by side.
You can create systems with new layout. You’ve got a lot of choice. You can start to make decisions about which layout method works best for different situation. Other layout methods still exist. Don’t try to recreate floats within grid—just use floats. It’s like when we moved from tables for layout, some people went too far and stopped using tables for tabular data. If you need content to flow around an element, float that element. Likewise, if you’re doing layout in just one dimension, you don’t have to use grid; use flexbox.
Off-the-shelf frameworks are designed to solve generic problems. We end up solving problems we don’t have. Do you want your project to inherit the CSS problems of the rest of the world? Solving your specific problems only will result in lighter, easier to understand code.
You don’t need to lean on somebody else’s framework to get reusable code for your project and your team.
What about working with less capable browsers? (these may not always be old browsers). Let’s go back to 2006 and Yahoo’s graded browser support matrix. It was updated quarterly. It was useful. A lot of discussion around browser support was happening with a lack of understanding on one side (bosses, clients) meeting a lack of confidence on the other (developers). Yahoo’s browser support matrix gave us ammunition. If it was okay for Yahoo to say that it was okay for certain browsers to not receive certain features, then that argument was easier to make.
A lot of the discussion now is about older Internet Explorer—IE11 comes up a lot. If IE10 and 11 are your oldest supported versions, you can use the ms- prefixed grid layout.
Some people are using devices that aren’t updating to new browsers. UC browser for Android is used a lot. It’s very popular in India (35% usage). Many browsers without grid support are mobile browsers, popular in areas where data is expensive.
People want a magical grid polyfill that will make grid work in non-supporting browsers. Please stop asking for that! Why, oh, why would you send more JavaScript to less-capable devices!
You can use feature queries to ask if a browser supports a feature before using it. The great thing about doing this is that you are future-proofing: as browsers get support for features, your code works automatically.
You can create complex layouts for browsers that support them with a few lines of CSS. Being able to do new cool stuff is great. Saving developer time is great. But making the web available to everyone …that’s exciting!
To wrap up, Rachel recounts some of the other responses to her survey. People said they were “Excited!”
See also:
