Bram hopes for a way to define aspect ratios natively in CSS. We can sort of manage it now, but all the solutions are pretty hacky.
Sunday, June 25th, 2017
Tuesday, June 6th, 2017
A great description of one of the most powerful features in CSS Grid.
This function opens the door to us being able to write much more powerful and succinct CSS by allowing us to set, as a value for a grid track, a function including both a minimum and maximum value.
Tuesday, May 30th, 2017
Charlotte has caught the CSS Grid bug. I absolutely love her step-by-step explanation—it’s really clear, and manages to be brief but thorough at the same time.
It’s time to be more experimental and push the boundaries with layouts.
Tuesday, May 23rd, 2017
A quick visual guide to CSS Grid properties and values.
Tuesday, May 2nd, 2017
Styling the Patterns Day site
Once I had a design direction for the Patterns Day site, I started combining my marked-up content with some CSS. Ironically for an event that’s all about maintainability and reusability, I wrote the styles for this one-page site with no mind for future use. I treated the page as a one-shot document. I even used ID selectors—gasp! (the IDs were in the HTML anyway as fragment identifiers).
The truth is I didn’t have much of a plan. I just started hacking away in a
style element in the
head of the document, playing around with colour, typography, and layout.
I started with the small-screen styles. That wasn’t a conscious decision so much as just the way I do things automatically now. When it came time to add some layout for wider viewports, I used a sprinkling of old-fashioned
display: inline-block so that things looked so-so. I knew I wanted to play around with Grid layout so the
inline-block styles were there as fallback for non-supporting browsers. Once things looked good enough, the fun really started.
I was building the site while I was in Seattle for An Event Apart. CSS Grid layout was definitely a hot topic there. Best of all, I was surrounded by experts: Jen, Rachel, and Eric. It was the perfect environment for me to dip my toes into the waters of grid.
Jen was very patient in talking me through the concepts, syntax, and tools for using CSS grids. Top tip: open Firefox’s inspector, select the element with the
display:grid declaration, and click the “waffle” icon—instant grid overlay!
For the header of the Patterns Day site, I started by using named areas. That’s the ASCII-art approach. I got my head around it and it worked okay, but it didn’t give me quite the precision I wanted. I switched over to using explicit
It’s definitely a new way of thinking about layout: first you define the grid, then you place the items on it (rather than previous CSS layout systems where each element interacted with the elements before and after). It was fun to move things around and not have to worry about the source order of the elements …as long as they were direct children of the element with
Without any support for sub-grids, I ended up having to nest two separate grids within one another. The logo is a grid parent, which is inside the header, also a grid parent. I managed to get things to line up okay, but I think this might be a good use case for sub-grids.
The logo grid threw up some interesting challenges. I wanted each letter of the words “Patterns Day” to be styleable, but CSS doesn’t give us any way to target individual letters other than
:first-letter. I wrapped each letter in a
b element, made sure that they were all wrapped in an element with an
aria-hidden attribute (so that the letters wouldn’t be spelled out), and then wrapped that in an element with an
aria-label of “Patterns Day.” Now I could target those
For a while, I also had a
br element (between “Patterns” and “Day”). That created some interesting side effects. If a
br element becomes a grid item, it starts to behave very oddly: you can apply certain styles but not others. Jen and Eric then started to test other interesting elements, like
hr. There was much funkiness and gnashing of specs.
It was a total nerdfest, and I loved every minute of it. This is definitely the most excitement I’ve felt around CSS for a while. It feels like a renaissance of zen gardens and layout reservoirs (kids, ask your parents).
After a couple of days playing around with grid, I had the Patterns Day site looking decent enough to launch. I dabbled with some other fun CSS stuff in there too, like gratuitous clip paths and filters when hovering over the speaker images, and applying
shape-outside with an image mask.
Go ahead and view source on the Patterns Day page if you want—I ended up keeping all the CSS in the
head of the document. That turned out to be pretty good for performance …for first-time visits anyway. But after launching the site, I couldn’t resist applying some more performance tweaks.
Saturday, April 15th, 2017
This is a really clear explanation of how CSS works.
Tuesday, April 11th, 2017
A handy GUI for experimenting with CSS Grid Layout without having to recall the syntax.
Monday, April 10th, 2017
Getting griddy with it
I had the great pleasure of attending An Event Apart Seattle last week. It was, as always, excellent.
It’s always interesting to see themes emerge during an event, especially when those thematic overlaps haven’t been planned in advance. Jen noticed this one:
The theme of this year’s AEA (ideas emerging across talks) — do not just do a thing on your project because others do on theirs. #aeasea— Jen Simmons (@jensimmons) April 3, 2017
I remember that being a theme at An Event Apart San Francisco too, when it seemed like every speaker had words to say about ill-judged use of Bootstrap. That theme was certainly in my presentation when I talked about “the fallacy of assumed competency”:
- large company X uses technology Y,
- company X must know what they are doing because they are large,
- therefore technology Y must be good.
Perhaps “the fallacy of assumed suitability” would be a better term. Heydon calls it “the ‘made at Facebook’ fallacy.” But I also made sure to contrast it with the opposite extreme: “Not Invented Here syndrome”.
As well as over-arching themes, it was also interesting to see which technologies were hot topics at An Event Apart. There was one clear winner here—CSS Grid Layout.
Microsoft—a sponsor of the event—used An Event Apart as the place to announce that Grid is officially moving into development for Edge. Jen talked about Grid (of course). Rachel talked about Grid (of course). And while Eric and Una didn’t talk about it on stage, they’ve both been writing about the fun they’ve been having having with Grid. Una wrote about 3 CSS Grid Features That Make My Heart Flutter. Eric is documenting the overall of his site with Grid. So when we were all gathered together, that’s what we were nerding out about.
There are some great resources out there for levelling up in Grid-fu:
- Jen’s experimental layout lab shows what’s possible.
- Her exercises in Codepen are a great way to test your knowledge of Grid.
- So is CSS Grid Garden.
- Rachel’s extensive Grid by Example is the perfect way to find the Grid solution to your layout scenario.
With Jen’s help, I’ve been playing with CSS Grid on a little site that I’m planning to launch tomorrow (he said, foreshadowingly). I took me a while to get my head around it, but once it clicked I started to have a lot of fun. “Fun” seems to be the overall feeling around this technology. There’s something infectious about the excitement and enthusiasm that’s returning to the world of layout on the web. And now that the browser support is great pretty much across the board, we can start putting that fun into production.
Sunday, April 9th, 2017
Here’s a handy interface if you want to get your head around named areas in CSS Grid, also known as doing layout with ASCII art.
I’ve been digging into CSS Grid a lot during the past week, so this post from Eric is very timely. On the surface it looks like a fairly simple use case but as you read through the explanation, it starts to become clear that the underlying thinking could be used in a lot of situations.
And, yes, like Eric, I too have been bitten by the Grid bug:
I’m working on my first redesign in a dozen years. If that doesn’t give you some sense of the power of Grid, well, I just don’t know what will.
Chris rounds up the discussion that’s been happening around container queries, for and against.
Personally, I’d like to see about 100 different use cases fleshed out. If it turns out some of them can be done sans container queries, awesome, but it still seems highly likely to me that having container queries available to us would be mighty handy.
Tuesday, April 4th, 2017
Monday, April 3rd, 2017
Paul’s being contrary again.
Seriously though, this is a good well-reasoned post about why container queries might not be the the all-healing solution for our responsive design problems. Thing is, I don’t think container queries are trying to be an all-encompassing solution, but rather a very useful solution for one particular class of problem.
So I don’t really see container queries competing with, say, grid layout (any more than grid layout is competing with flexbox), but rather one more tool that would be really useful to have in our arsenal.
Thursday, March 2nd, 2017
A really inspiring post by Jen outlining all the benefits of the new CSS layout features …and the problems with thinking framework-first.
I know a lot of people will think the “best” way to use CSS Grid will be to download the new version of Bootstrap (version 5! now with Grid!), or to use any one of a number of CSS Grid layout frameworks that people are inevitably going to make later this year (despite Rachel Andrew and I begging everyone not to). But I don’t. The more I use CSS Grid, the more convinced I am that there is no benefit to be had by adding a layer of abstraction over it. CSS Grid is the layout framework. Baked right into the browser.
Unsurprisingly, I completely and utterly agree with Ethan’s assessment here:
I’ve written some code that’s saying, “Once the screen is this size and the element appears in a different, smaller container, use a narrower layout on this element.”
But, well, that’s weird. Why can’t we apply styles based on the space available to the module we’re designing, rather than looking at the shape of the viewport?
I also share his frustration with the “math is hard; let’s go shopping” response from browser vendors:
There’s an incredible clamor for container queries, with folks from every corner of the responsive community asking for something that solves this problem. So personally, I’d love to see at least one browser vendor partner with the RICG, and get properly fired up about this.
We had to drag browser makers kicking and screaming to responsive images (to this day, Hixie maintains it’s not a problem that needs solving) and I suspect even more activism is going to be needed to get them to tackle container queries.
Wednesday, March 1st, 2017
A nice rundown of some of the fun you can have with viewport units.
Sunday, January 22nd, 2017
Grid is only a replacement for float-based layout, where float-based layout it being used to try and create a two-dimensional grid. If you want to wrap text around an image, I’d suggest floating it.
Grid is only a replacement for flexbox if you have been trying to make flexbox into a two-dimensional grid. If you want to take a bunch of items and space them out evenly in a single row, use flexbox.
Sunday, January 15th, 2017
Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!
Monday, January 9th, 2017
A wonderfully thoughtful piece from Robin, ranging from the printing technologies of the 15th century right up to the latest web technologies. It’s got all my favourite things in there: typography, digital preservation, and service workers. Marvellous!
Tuesday, January 3rd, 2017
When I was first styling Resilient Web Design, I made heavy use of
vh units. The vertical spacing between elements—headings, paragraphs, images—was all proportional to the overall viewport height. It looked great!
Then I tested it on real devices.
Here’s the problem: when a page loads up in a mobile browser—like, say, Chrome on an Android device—the URL bar is at the top of the screen. The height of that piece of the browser interface isn’t taken into account for the viewport height. That makes sense: the viewport height is the amount of screen real estate available for the content. The content doesn’t extend into the URL bar, therefore the height of the URL bar shouldn’t be part of the viewport height.
But then if you start scrolling down, the URL bar scrolls away off the top of the screen. So now it’s behaving as though it is part of the content rather than part of the browser interface. At this point, the value of the viewport height changes: now it’s the previous value plus the height of the URL bar that was previously there but which has now disappeared.
I totally understand why the URL bar is squirrelled away once the user starts scrolling—it frees up some valuable vertical space. But because that necessarily means recalculating the viewport height, it effectively makes the
vh unit in CSS very, very limited in scope.
In my initial implementation of Resilient Web Design, the one where I was styling almost everything with
vh, the site was unusable. Every time you started scrolling, things would jump around. I had to go back to the drawing board and remove almost all instances of
vh from the styles.
I’ve left it in for one use case and I think it’s the most common use of
vh: making an element take up exactly the height of the viewport. The front page of the web book uses
min-height: 100vh for the title.
But as soon as you scroll down from there, that element changes height. The content below it suddenly moves.
Let’s say the overall height of the browser window is 600 pixels, of which 50 pixels are taken up by the URL bar. When the page loads,
100vh is 550 pixels. But as soon as you scroll down and the URL bar floats away, the value of
100vh becomes 600 pixels.
(This also causes problems if you’re using vertical media queries. If you choose the wrong vertical breakpoint, then the media query won’t kick in when the page loads but will kick in once the user starts scrolling …or vice-versa.)
There’s a mixed message here. On the one hand, the browser is declaring that the URL bar is part of its interface; that the space is off-limits for content. But then, once scrolling starts, that is invalidated. Now the URL bar is behaving as though it is part of the content scrolling off the top of the viewport.
The result of this messiness is that the
vh unit is practically useless for real-world situations with real-world devices. It works great for desktop browsers if you’re grabbing the browser window and resizing, but that’s not exactly a common scenario for anyone other than web developers.
It’s such a shame. A piece of CSS that’s great in theory, and is really well supported, just falls apart where it matters most.
Update: There’s a two-year old bug report on this for Chrome, and it looks like it might actually get fixed in February.