Things change rapidly in the WordPress world. The content in this post is more than a year old and may no longer represent best practices.
Over the past two years, we have moved from a situation where we essentially lacked a layout system for the web, to one where a complex and flexible system is emerging. A system with Grid and Flexbox as the headline features, and backed by a range of concepts and CSS properties and values which help us make sense of what it is to do layout on the web.
In this talk, we will take a look at CSS layout in a holistic way. Rather than thinking Grid or Flexbox first, we will look at the patterns we need to build, and then discover which bits of CSS we might need to use to realise them. Along the way we’ll encounter Grid, Flexbox, the BFC, Writing Modes, and some interesting things about scrolling. All part of the layout system that we now have in CSS.
About the Speaker
Rachel Andrew is a front and back-end web developer, author and speaker. Author or co-author of 22 books including The New CSS Layout and a regular contributor to a number of publications both on and offline. Rachel is co-founder of the CMS Perch and Notist, Editor in Chief of Smashing Magazine, a Google Developer Expert and a Member of the CSS Working Group. She writes about business and technology on her own site at rachelandrew.co.uk.
View Does it work? Using the new CSS Layout on Notist.
“Grid or flexbox?” is a terrible question.
Multi-column is a fragmentation spec—it’s like page breaks in print docs. That’s why we have things like
break-inside: avoid. But browser support is not very good just yet.
Multi-column was the first inherently flexible layout system.
The length of time it took to get from that to flexbox and Grid demonstrates how difficult it is to innovate on the web. Web developers forget to ask for something better than what they have. (Except for aspect ratio. People asked for that.)
When we use
display, we’re changing the way that element operates—the Block Formatting Context.
The CSS Working Group has refactored
display so that it gets two values: block flow, block flex, etc. The first value describes the parent item, the second item describes the children.
display: flow-root or
display: block flow-root creates a new formatting context, so that eliminates any need to clear floats. (That by itself is amazingly useful.)
display: inline-block is more mysterious than we think. In addition to allowing you to add padding and margin to inline elements, you can float stuff.
The two-value syntax for
display works in Firefox 70 and isn’t available in Chrome yet. (But check Can I Use depending on when you read this.)
Things Flexbox Does Well
flex: 1 equals
flex: 1 1 0. The boxes have no intrinsic size and grow and shrink the same way.
If you stop trying to use Flexbox as Grid, you can discover its full power. If you find yourself putting widths on all your flex items, you should probably use Grid.
The way that
auto behaves in Flexbox is important—it lays items out at their max-content-width and resizes them proportionally.
A continuous string of text in a flex container becomes an anonymous flex item (no element) and gets aligned. And so do inline items. So items in
<span> tags get flexed.
The magic of auto margins in Flexbox: auto margins absorb all the space in the dimensions you’ve specified them on. Flexbox is amazing for little bits of user interface, like headers.
Flexbox and Grid are “agnostic” with respect to writing mode (left-to-right, etc.) The block dimension is perpendicular to your writing. That’s why we use
end instead of top, bottom, right, and left.
This can make it a bit awkward to put margins, padding, and borders on these items, because those things refer to physical dimensions. So we have a whole new specification: logical properties and values. Introducing
block-size. (Okay, that’s pretty cool. Check support.) These apply to the padding, margins, borders, and even border radius.
Naming things, in addition to being one of the Two Hard Things in programming, is the superpower of Grid.
Oh, that’s how you use
fit-content. It makes components more reusable, because it will apply to grid items of different sizes. (Thumbnail image vs. icon.)
We name lines and areas, but not tracks. Can’t have everything.
Line names are in square brackets. Lines can have multiple names. You can’t use “span” as a line name, because it’s a reserved term. If you use
-end as part of the names, you get named areas.
Then we add Subgrid, which has just shipped in Firefox. Values of
display don’t inherit, because things would be a mess if we didn’t go back to normal flow. But with Subgrid, you not only have a grid within a grid, you inherit the grid tracks and the line names.
Praise be, we are getting faster implementation and better cross-browser support thanks to the work of the CSS Working Group. If you see weird stuff, it’s probably old stuff. (See this List of Mistakes in the Design of CSS.) These days, people care about interoperability.
Things we’re finally standardizing: scrollbars! (You can make your scrollbars different sizes and colors.)
Better defaults, like scroll anchoring. (That will fix the horrible effect of ads loading on news sites, at least if the devs of the sites that show them respect it.) That will just happen in browsers: web devs don’t have to do anything.
It’s important to ask WHY things work. If you know why it works, you probably won’t need to keep looking it up.Rachel Andrew
Check to see whether there’s a new way of doing stuff. And when you find a new way of doing something, share it.
Q & A
What’s going on with Safari?
“We have no idea. We try to guess what Apple is up to. The people on the Working Group from Apple aren’t allowed to talk about it.” (That’s absolutely daft.)
Any browser on an iPhone is essentially Safari (because WebKit).
Is there anything you wanted in CSS that didn’t ship?
What resources are there for CSS for print?
The reason that printing from the web is broken is that the fragmentation spec is broken. The Paged Media specification defines a page model that specifies how a document is formatted within a rectangular area, including page size, page breaks, page margins, page orientation, etc. and so on. Looking at the spec is a good place to start.
However, browsers don’t implement this, so that’s a bit awkward. There are special user-agents like Prince that publishers use to create books laid out with CSS. (They’re not cheap, either.)
- Rachel’s 2018 article on print stylesheets in Smashing Magazine.
- Rachel’s 2015 article on designing for print with CSS in Smashing Magazine.
Is there any performance cost to using the new CSS layouts?
All of this stuff is really performant, much more than floated layouts. You’d have to have an insanely complex layout to get any performance problems, and if you find one, it’s probably a bug, so report it.
Is there still a role for pre-processors?
Less and less. Rachel uses a post-processor to create fallbacks for browsers that don’t support newer features.
How does the CSS Working Group decide what to add to the spec?
The more advanced CSS gets, the less JS you need to use. Is that on purpose?
Rachel says yes, it’s ABSOLUTELY intentional. Browsers can optimize for CSS better than for JS. If it’s a visual layout thing, it should probably be CSS rather than JS.
Gabe asks about Bootstrap and Foundation. “I’ve not touched Bootstrap and Foundation for a long time.” If your team needs the style guide inherent in Bootstrap, that’s something else. Use the bit you need, as Sonja says of Foundation.
Dylan asks where Rachel hopes CSS is heading. She thinks they’re on a good track and have sorted out a lot of stuff that was confusing. Everyone wants aspect ratio and container queries. Some things are hard, because browsers are old. We have to specify them well.