For my recent series about column-filled grids I wrote an overview of parts of the grid algorithm. I ended up not using it in that series, but thought I’d publish it anyway.

During editing I got caught up in the spirit of things and explained why, as so often, it’s better to hard-code a relatively small number of constraints and let browsers handle the rest.

So here it goes; a simplified summary of the Grid algorithm for slightly-advanced CSS developers with lengthy detours and no real point.

Implicit tracks

As you know, a grid consists of columns and rows. Together, they are called tracks, and in some respects they work the same.

Tracks can be explicit, which means a property defines them. This snippet creates two explicit column tracks.

grid-template-columns: 1fr 1fr;

This grid has two columns and six items. We didn’t define any rows. How many rows does it have?

Well, duh. Three.

A duh is nearly always a sign of implicit tracks. The grid creates three rows because the item placement of the six items requires them. They’re here because they’re needed. You didn’t define them, but they’re implicit in the entire grid structure.

grid-row and grid-column

I hope the existence of grid-row and grid-column does not come as a surprise to you. They allow you to explicitly place an item in a specific row and/or column. My technique rests on explicitly assigning rows to items.

Temami pointed out something I didn’t know, or hadn’t fully realised. What does the following code do?

.grid {
	grid-template-columns: 1fr 1fr; 
}

.grid > :nth-child(4n) {
	grid-column: 4;
}

Well, it places the 4th, 8th, etc. item in the fourth column. Duh. Makes sense, doesn’t it? You obviously want a four-column layout.

Duh again signals implicit tracks. The grid-column: 4 creates a fourth column, and the existence of a fourth column implies the existence of a third column. So the grid has a third column.

Fun challenge for semantic nerds: is the fourth column explicitly or implicitly defined? Discuss.

grid-auto-columns and -rows

But why are the third and fourth column so narrow? That’s because they don’t have a defined size. The explicitly defined first and second columns do: 1fr. But the implicit third and fourth column have the default width of auto. In Grid, that’s a complicated value, but a first approximation is min-content: as little as we can get away with given the content.

So the third and fourth column get their minimally necessary width, and the first and second divide the rest of the width among them.

.grid {
	grid-template-columns: 1fr 1fr; 
	grid-auto-columns: 1fr;
}

grid-auto-columns and -rows set a width and height for automatically-created columns and rows. Adding grid-auto-columns: 1fr solves the issue: now all columns have width 1fr and the end result is much better.

For rows, auto means "the minimum height necessary", and that’s usually the perfect height for grid rows. That’s why we generally don’t bother setting grid-auto-row.

grid-auto-flow

Why does the ninth item in the example below create a third row? Why not a fifth column? What makes it prefer rows over columns?

grid-auto-flow does. It can be row (the default) or column and means something like "if you’re forced to create a new implicit track, make it a row/column." Since in our example it’s row we get a third row, and not a fifth column.

You’ve probably seen a grid like this a few times when you made a syntax error in your column definition. If you don’t define any columns, each item creates its own row because that’s what grid-auto-flow: row says it should do.

.grid {
	grid-auto-columns: 1fr;
	grid-auto-flow: column;
}

The other, more rarely used value is column. Now the grid prefers to create columns for extra grid items. This simple example creates a new column for every grid item.

Column flow

Let’s expand this column flow example. We use the same code as before to place the 4th, 8th etc. item in the fourth column.

.grid {
	grid-auto-columns: 1fr;
	grid-auto-flow: column;
}

.grid > :nth-child(4n) {
	grid-column: 4;
}

A lot starts happening at once, and some of it is familiar. The fourth and eighth items are placed in column four. Like before, this creates four implicit columns, and the ninth item adds a fifth column because grid-auto-flow: column tells the grid to create extra columns when necessary; not rows.

However, the grid-column does something else as well. When placing the eighth item in the fourth column, it can’t go in the first row because the fourth item is already in row 1 / column 4. So we obviously need a second row and it’s implicitly created.

But what’s with the weird item order? Well, first we count top-to-bottom in the leftmost column, and we already saw why the example has two rows. So the placement of items 1, 2, and 3 is understandable. 4 goes in column four, even though this is actually the seventh cell in logical order. We commanded this explicitly, after all. So 5 goes in the fourth cell, 6 in the fifth, 7 in the sixth, 8 is again forced into the fourth column but happens to take up the eighth cell. 9, finally, has to create a new track, and grid-auto-flow: column makes that track a column. We gave explicit instructions, and they’re obeyed to the letter, even when they don’t really make sense.

Grid item placement algorithm

Let’s go to the formal algorithm.

First, the grid calculates the minimum necessary number of columns and rows. This information comes from explicit sources such as grid-template-*, but also from declarations such as the grid-column: 4 we saw above.

The grid also determines from grid-auto-flow what kind of tracks to create for 'overflow' items: rows or columns. Let’s say that it’s rows; that use case is more popular and more familiar to everyone.

1. Items with both a defined grid-column and a grid-row are placed in their correct column and row, creating implicit tracks if necessary.
2. Next, items with a defined grid-row are placed in the leftmost empty position in their correct row, creating implicit tracks if necessary.
3. Then, all remaining items, including those with a defined grid-column, are placed, in order order, with source code order breaking any ties. However, any item with display: none is skipped.
   1. A 'cursor' is created that points to the leftmost empty cell in the first row.
   2. The first unplaced item is placed there. However, if that item has a grid-column, the pointer moves to the next empty cell in that column and places the item there. This step may move the cursor to the next row.
   3. Then the cursor moves to the next cell in the row, or the leftmost empty cell in the next row, creating new implicit rows if necessary.
   4. During this entire process the cursor only moves forward, never back. Thus, there may be empty spots in the grid.

If grid-auto-flow is column, all instances of 'row' and 'column' in the algorithm above are swapped, and 'leftmost' is replaced by 'topmost'.

Strict grid instructions

I’d like to focus on step 2.

Items with a defined grid-row are placed in the leftmost empty position in their correct row, creating implicit tracks if necessary.

Earlier, I created a technique for a filling a grid column by column (as if grid-auto-flow is column), but that also sets the maximum number of columns as if it uses a grid-template-columns with auto-fill. It works as follows:

.columnGrid {
	display: grid;
	grid-auto-columns: 1fr;
	
	& > * {
		--gridWidth: calc(100cqw - var(--padding) * 2);
		--maxColumns: round(down,calc(var(--gridWidth) / var(--size)));
		--rows: round(up,calc(sibling-count() / var(--maxColumns)));
		--row: calc(mod(calc(sibling-index() - 1),var(--rows)) + 1);
		grid-row: var(--row);
	}
}

It first determines the maximum number of columns, and from that the amount of rows that it needs. Then it assigns the correct grid-row to every grid item.

In other words, it only uses step 2 of the grid algorithm.

And that’s a problem. It feels to me like using position: absolute all over your site. Yes, it works, but only in perfect circumstances, and as soon as anything goes wrong a lot goes wrong. The technique is brittle.

I saw that and tried to create a better technique, but it needs children-count(), which doesn’t exist yet.

Looser instructions

It would be better if we could use a lighter touch and set only a few items to their correct row, like we did above.

.columnGrid {
	display: grid;
	grid-auto-columns: 1fr;
}
	
.grid > :nth-child(4n) {
	grid-row: 4;
}

Fewer instructions, fewer things that can go wrong.

Remember, the grid now prefers to create imnplicit columns. It’s implicitly ordered to have four rows, though, so it’s only the fifth item that starts a new column.

The hide test

But this version is not perfect. When we hide one item, the grid doesn’t flow nicely into the hole. That’s understandable: we told it to put the fourth item in the fourth row, and it does so.

Here’s the relevant portion of the algorithm again, but now with grid-auto-flow: column engaged:

1. A 'cursor' is created that points to the topmost empty cell in the first column.
2. The first unplaced item is placed there. However, if that item has a grid-row, the pointer moves to the next empty cell in that row and places the item there. This step may move the cursor to a lower column.
3. Then the cursor moves to the next cell in the column, or the topmost empty cell in the next column, creating new implicit columns if necessary.
4. During this entire process the cursor only moves forward, never back. Thus, there may be empty spots in the grid.

So the 'cursor' starts in the top left cell, the first item is placed there, and the cursor moves to the next cell down. The second item is skipped because it has display: none. The third item is placed in the second cell. Then the fourth item is placed in row 4, and the third cell is skipped. Since it was calculated there’s a maximum of four rows, the cursor goes to the next column and places the remaining items there.

This is better than the original technique, which goes wrong even more spectacularly because every item is forced into a row, whether that makes sense or not.

Still, it’s not perfect. The original technique placed all items in a specific row. The looser technique only places a few items in a row. That is better, but in both cases we don’t check whether the item placement makes sense (and, to be honest, I’m not sure that’s possible in CSS alone).

Maximum flexibility

So far we tried to tell items what to do instead of programming a few constraints and then go out of the way and let browsers handle the exact placement. We should just tell browsers how many rows or columns we need, but don’t handle individual items. The next example does that.

.columnGrid {
	display: grid;
	grid-template-rows: repeat(4,1fr); 
	grid-auto-flow: column; 
	grid-auto-columns: 1fr
}

This works best. Four rows are created, and the items fill up these rows neatly. Item 4 is in the third cell, as it should be when item 2 is hidden. Unfortunately, as I explained earlier, I can’t calculate how many rows my technique needs because of the lack of children-count(). But if you can hard-code the number of rows this is the best technique.

Conclusion

As is so often the case in web development, the best way to create a layout is to give as few instructions as possible and then get out of the way and let browsers sweat the details. Grid, like many other CSS modules, was written with a lot of sensible defaults in place. As long as you don’t overrule those defaults too much, your site will behave well even in adverse circumstances.

Public service announcement: ticket sales for the performance.now() web performance conference, 19th and 20th of November, Amsterdam, have started.

Join Tim Kadlec, Tammy Everts, Harry Roberts, and me for two days of advanced web performance geekery, where all the global experts will explain what they’ve been up to for the past year.

In order to break with our past, and our very topic, this year we’ll announce speakers nice and slowly. Tim, Tammy, and Harry are always there; no surprise. But which web performance luminaries will join them in November? Watch this space. Or any space in general.

Get your tickets now.

Early-bird tickets are meanwhile sold out, but you can still get tickets for the lowest regular price. This year, we raise prices twice. To quote the site:

This public service announcement now ends.

When selecting speakers for our conferences we always hunt for a video of a prospective speaker, unless we’ve seen them for ourselves in the flesh. If we cannot find a video, we do not invite the speaker, since we cannot guarantee to our audience that they are excellent presenters. Not all conferences do so, but we do.

For some new speakers this is a bit of a hurdle. Not an insurmountable one — some local meet-ups and most conferences record their sessions — but it’s still an extra step. Local meet-up organisers take note: recording the sessions would be a huge service for your speakers — if you have the budget.

That was not what I wanted to talk about today, though. In the past months we conferred with quite a few developer relations departments about CSS Day and performance.now(), and they all proposed a speaker that they didn’t have a video of. So we said No.

For developer relations departments, whose job it is to get their people to speak at conferences, this is a far more serious oversight than for individuals.

So my advice to developer relations departments is to organise a local meet-up, get all their unknown speakers to speak, record all sessions, and put them online. I mean, they must have the budget to do that once, right? It would be a great gift to conference organisers around the world, even to those that do not require videos.

And while you’re at it, hey, also invite that one local speaker that you think should get more conference invitations.

In part one I created a technique to fill a grid column by column instead of row by row, while still setting a maximum number of columns. It works, but is brittle. Here we’ll discuss why it is brittle, and why lack of children-count() makes a theoretically superior technique for doing the same impossible.

The technique

The sidebar on my blog pages contains a list of tags. I want to first fill the left column alphabetically, then continue with the next — like an index in a book.

I use the following CSS:

.columnGrid {
	--size: 150px;
	--padding: 0.5em;
	display: grid;
	container-type: inline-size;
	grid-template-columns: repeat(auto-fit,minmax(var(--size),1fr));
	padding: var(--padding);
	
	@supports (order: sibling-count()) and (order: calc(1cqw/1px)) {
		grid-template-columns: 1fr;
		grid-auto-columns: 1fr;
	}
	
	& > * {
		--gridWidth: calc(100cqw - var(--padding) * 2);
		--maxColumns: round(down,calc(var(--gridWidth) / var(--size)));
		--rows: round(up,calc(sibling-count() / var(--maxColumns)));
		--row: calc(mod(calc(sibling-index() - 1),var(--rows)) + 1);
	
		grid-row: var(--row);
	}
}

It works, but it has issues. Let’s talk about them.

Issues

Consider an item with display: none. In a regular grid it’s simply ignored. In my technique, however, it messes up the calculations.

Despite being hidden, the item is in the DOM, and counts for sibling-count() and -index(). Thus, the number of rows can be off. In the second example six items are visible, so it should have three rows. Instead, it has four because sibling-count() still counts seven siblings.

Worse, my technique assumes that the hidden item takes the row 2 / column 1 cell. But it doesn’t, and item 6, which is supposed to go in row 2 / column 2, goes into column 1 instead. That breaks the alphabetical order rather dramatically.

Something similar happens with a colspan. There is no way of detecting that 'CSS' now takes up two columns instead of one, and my technique breaks and the alphabetical order is off again.

CSS Grid by itself does a decent job of handling both situations. But I gave a bunch of absolute commands: this item should go there. I took away Grid’s ability to adjust, to compensate for problems, to balance things out.

I made myself responsible for handling these tricky situations — and I can’t. It’s not possible to say "don’t sibling-count an item that has display: none" or to correct sibling-index/count() for colspans and rowspans.

Working with the grid

CSS Grid does in fact have the tools to create a much more robust technique that handles the edge cases much better. I realised that after a day and a half of work, and decided to switch to a simpler, better technique.

By default, CSS Grid looks at the number of available columns and then creates enough rows to hold all the items. We as web developers only have to set the number of columns, and we’re in business.

This behaviour is caused by the declaration grid-auto-flow: row. It sort-of means "if you need more space, we’d prefer that you add rows." We tend to leave it alone because this is how we expect grids to work.

But there’s also grid-auto-flow: column. Now CSS Grid looks at the available number of rows and then creates enough columns to hold all the items.

.columnGrid.withTheGrain {
	grid-template-rows: repeat(3,auto);
	grid-auto-flow: column;
	grid-auto-columns: 1fr;
}

This, I realised, is the solution. CSS Grid has all kinds of clever defaults to paper over our issues. We just have to allow it to do its job.

We shouldn’t give CSS Grid a bunch of detailed orders, but hand-wavingly tell it to lay out these items column-wise as well as it can.

In the quick proof-of-concept I made, the one shown here, I hard-coded the three rows and it worked fine.

I still wanted to set a number of columns, though, and use the variables to calculate the number of rows. No problem, right? I already wrote that calculation, right? I just have to plug it into the new grid code, right?

.columnGrid.withTheGrain {
	--gridWidth: calc(100cqw - var(--padding) * 2);
	--maxColumns: round(down,calc(var(--gridWidth) / var(--size)));
	--rows: round(up,calc(sibling-count() / var(--maxColumns)));
	/* We don't need --row */

	grid-template-rows: repeat(var(--rows),auto);
	grid-auto-flow: column;
	grid-auto-columns: 1fr;
}

Wrong.

CSS variable scope

CSS variables are scoped to the context in which they are evaluated. And we just changed that context. That has consequences.

If you’re not sure what that means, concentrate on sibling-count(). Whose siblings are we counting? Whose siblings should we be counting?

Well, we should be counting the siblings of the grid items. That gives us the total number of items we need for the calculation. The original technique did so.

.columnGrid {
	display: grid;
	
	& > * {
		--gridWidth: calc(100cqw - var(--padding) * 2);
		--maxColumns: round(down,calc(var(--gridWidth) / var(--size)));
		--rows: round(up,calc(sibling-count() / var(--maxColumns)));
		--row: calc(mod(calc(sibling-index() - 1),var(--rows)) + 1);

		grid-row: var(--row);
	}
}

The individual grid items used the variable --row. Thus, --row is evaluated in the context of a grid item, as are all the variables it depends on. In particular, sibling-count() counts the grid item’s siblings, and sibling-index() yields the grid item’s index.

But the new technique changes that:

.columnGrid.withTheGrain {
	--gridWidth: calc(100cqw - var(--padding) * 2);
	--maxColumns: round(down,calc(var(--gridWidth) / var(--size)));
	--rows: round(up,calc(sibling-count() / var(--maxColumns)));
	/* We don't need --row */

	grid-template-rows: repeat(var(--rows),auto);
	grid-auto-flow: column;
	grid-auto-columns: 1fr;
}

Now the grid container uses the variable --rows, and it, as well as the other variables it depends on, are evaluated in the context of the grid container. In particular, sibling-count() now counts the grid container’s siblings.

And that’s wrong. I don’t care how many siblings the container has, but that useless number is force-fed into our formula and yields gibberish. Garbage in, garbage out.

.columnGrid.withTheGrain {
	--gridWidth: calc(100cqw - var(--padding) * 2);
	--maxColumns: round(down,calc(var(--gridWidth) / var(--size)));
	--rows: round(up,calc(children-count() / var(--maxColumns)));
	/* We don't need --row */

	grid-template-rows: repeat(var(--rows),auto);
	grid-auto-flow: column;
	grid-auto-columns: 1fr;
}

In the new context we don’t need sibling-count(). Instead, we need children-count(). That would give us the number of grid items, and our formula would work once more.

But there’ a tiny problem with children-count(): despite developer pressure it doesn’t exist. Well, an issue exists, and since I take issue with its lack of existence I’m going to add a comment.

There is a second problem: finding the width of the grid container. In the original version I could made it a queryable container so I could use a simple 100cqw in the context of the grid item. But due to the change of evaluation context I now have to measure the width of the element from the context of that same element, and container queries don’t do that. Temami Afif solved that problem, but if I were to use his technique I would have to fully understand it — that’s my rule for this blog. I’m not sure if I want to go on yet another long digression, so I’m secretly relieved I don’t have to.

That’s why we can’t use the superior version without children-count(), and we’re left with the brittle version that works in simple cases but will fail in more complicated ones. It’s a pity, but it cannot be helped.

My use case is really simple: I just want a simple grid with no hidden or colspanned items, no complicated. That will work. If you want the same, hey, use the original version. If you want the better version, wait for children-count().

Want to see Adam Argyle and Kevin Powell and Lea Verou and Eric Meyer and all the rest? Not only for a session but also for a hallway discussion? Then come.

But you should be quick. Right now regular tickets cost €675 + VAT, but that price will rise to €750 + VAT in a week. 13th of May is the last day of normal tickets; the late-bird prices will kick in on Thursday 14th of May. (Why this price hike? It’s essentially a lateness tax. I wrote about it a few weeks back.)

So if you want to come — and you do — better grab a regular ticket now and save some money.

I have a grid that I want to fill with items, not row by row, as usual, but column by column. At the same time, I want to set a maximum number of columns, and add rows as needed, as a regular row-by-row grid does. To do so I created the technique described here.

Then I noted it was pretty brittle, and figured out why. I found I could not make it more robust because children-count() is not yet supported. So we’re stuck with the sub-optimal version — for now.

This is a two-parter. This first part describes the brittle solution that works right now, and the second the robust solution that doesn’t yet work.

Thanks to Temami Afif, Jane Ori, Roman Komarov, and Amit Sheen for their help with several aspects of this mini-series.

The problem

The sidebar on my blog pages contains a list of tags. I use a simple grid because the list can have either one or two columns, depending on the width of the sidebar. Simple grid is simple: it places the items in rows; the first two items in the first row, the second two in the second row etc. That’s how grids work.

I don’t like that. The tags are in alphabetical order, and intuitively I want to first fill the left column alphabetically, then continue with the next — like an index in a book.

At the same time, I want to set a number of columns in a manner similar to auto-fit, and derive the necessary number of rows from that.

The technique

Here’s how you do it. The CSS variables determine the number of columns auto-fit-style and then derive the necessary number of rows. It’s this number of rows that we pass on to the grid, hoping to get the right number of columns back. (We may not.)

.columnGrid {
	--size: 150px;
	--padding: 0.5em;
	display: grid;
	container-type: inline-size;
	grid-template-columns: repeat(auto-fit,minmax(var(--size),1fr));
	padding: var(--padding);
	
	@supports (order: sibling-count()) and (order: calc(1cqw/1px)) {
		grid-template-columns: 1fr;
		grid-auto-columns: 1fr;
	}
	
	& > * {
		--gridWidth: calc(100cqw - var(--padding) * 2);
		--maxColumns: round(down,calc(var(--gridWidth) / var(--size)));
		--rows: round(up,calc(sibling-count() / var(--maxColumns)));
		--row: calc(mod(calc(sibling-index() - 1),var(--rows)) + 1);
	
		grid-row: var(--row);
	}
}

You could hard code --maxColumns: 3 or whatever value you like. If you do, you don’t need container-style or --gridWidth.

Here are a regular grid and a column-filled grid in action:

It looks great but there are rather a lot of caveats.

• It doesn’t yet work in Firefox because Firefox doesn’t support length-on-length division (solvable) and sibling-index/count() (unsolvable).
• You can set a maximum number of columns, but the grid may use fewer. This is logical once you think about it, and unsolvable. Also, it’s no big deal.
• The technique only works well if all grid items take up exactly one 1x1 cell, and none of them are hidden. It is this brittle because it doesn’t allow Grid to function normally.
• Using a superior technique with grid-auto-flow: column is impossible because you can’t find the grid container’s width (solvable), and children-count() is not supported (unsolvable). More on that in part 2.

On the positive side, this is not something you can do with flexbox.

The calculation

So how does the calculation work?

--gridWidth: calc(100cqw - var(--padding) * 2);
--maxColumns: round(down,calc(var(--gridWidth) / var(--size)));
--rows: round(up,calc(sibling-count() / var(--maxColumns)));
--row: calc(mod(calc(sibling-index() - 1),var(--rows)) + 1);

• gridWidth establishes the width of the grid container minus the padding. For this to work the grid container needs to be a queryable container.
• maxColumns divides the container width by the desired column size (in this example 150px) and rounds down. This is the maximum amount of columns the end result is going to use. (Yes, maximum. It could be fewer.)
  Unfortunately Firefox can’t handle length-on-length division yet, and it yields 0 as the number of columns.
• rows divides the total number of grid items (long live sibling-count()!) by the number of columns and rounds up. That’s how many rows we need in order to place all of the items.
  Firefox does not support sibling-count()/index(). That’s why, even if it would survive the previous line, it fails here.
• row is the row number for an individual grid item. This calculation relies on modulo: the remainder of dividing the item’s sibling-index() by the total number of rows.

Modulo?

Suppose we have three rows and items 1 to 9. 1/3, 4/3, and 7/3 have a remainder of 1, and items 1, 4, and 7 go in row 1. Similarly, 2/3, 5/3, and 8/3 have a remainder of 2 and items 2, 5, and 8 go in row 2.

Finally, 3/3, 6/3, and 9/3 have a remainder of 0 but items 3, 6 and 9 go in row 3. Since we need 1, 2, and 3, not 1, 2, and 0, add 1 to the modulo but subtract 1 from the index. Now it works.

maxColumns

And what’s the thing with the maximum number of columns? In grids, you can set either the number of columns or the number of rows exactly, but not both. CSS Grid needs some wiggle room somewhere.

In regular grids we set the number of columns, and leave it to the grid to decide on the number of rows. Some numbers of rows don’t occur. The regular grid above can’t have five rows.

Now let’s go to a column-filled grid. Although we start the calcuation with the number of columns, it’s actually the number of rows that we set. That means we can’t fully control the number of columns. Consider:

Here, we have nine items and --maxColumns: 3. No one will be surprised to hear that nine items in three columns need three rows. That’s what our CSS variables set, and CSS Grid does the obvious thing and generates three columns.

When we go to --maxColumns: 4, things aren’t as neat. Two rows would be too few, since 4 columns * 2 rows = 8 item cells for 9 items. So we still need three rows, and that’s what our CSS variables set.

But now that we still use three rows for nine items, three columns is enough. We don’t need the fourth column, so CSS Grid doesn’t create one. --maxColumns: 4 yields three columns.

The @supports

At the time of writing Firefox doesn’t support this technique. We have to make sure Firefox users still see a regular grid. It won’t be column-filled, but that can’t be helped. So let’s give them (and in fact everyone) just that:

grid-template-columns: repeat(auto-fit,minmax(var(--size),1fr));

The auto-fitted columns take up all the available space. Thus, if the actual number of columns becomes greater than the number auto-fit calculates, there’s hardly any space left for those columns, as you can see in the example.

That’s where the @supports comes in. If the browser supports the technique, reset the number of columns to one — CSS Grid will add them as needed. Also, set the width of the one defined column as well as any automatically-created ones to 1fr.

@supports (order: sibling-count()) and (order: calc(1cqw/1px)) {
	grid-template-columns: 1fr;
	grid-auto-columns: 1fr;
}

Remember, Firefox lacks two features: sibling-count() and the ability to divide lengths. We check for both, and the syntax of @supports requires us to use a property: value pair. In this specific case the property doesn’t matter, but it still needs one. I picked order more or less at random, but you can use any property that accepts an integer: z-index, even grid-row.

Working against the grid

When I arrived at this point for the first time I admired the cleverness of the technique and myself, loved the way I forced CSS Grid to do my bidding.

Then I started having doubts. I bent CSS Grid out of shape, and holes were forming. If I’d work with, rather than against, CSS Grid the technique would become more robust. Unfortunately, as we’ll see in part two, that is impossible.

Ticket sales will open in a few weeks, and there are a few very cheap early-bird tickets available — I’m talking €100 or €200 instead of €700 or €800.

However, in order to grab them you should subscribe to the newsletter, because that’s the only way the start of early bird will be announced. Not on this site, not on social media, not even on the conference site.

So subscribe. And see you in November!

Just now Zeldman tweeted a question to which I replied. That reminded me of a story I want to share with you. Zeldman asked:

Have you ever felt that you have no talent whatever? How often do you feel that way?

What he describes is classic impostor syndrome. I’ve got it, you’ve got it, just about everybody’s got it. It’s the “just about” that I want to discuss today.

A few months back a conversation with friends turned to the subject of impostor syndrome. They didn’t know the term, but they recognized it and agreed they had it to a larger or smaller degree. Then a friend of mine who’s a doctor told us a story.

She told us that one time the conversation among her and her colleagues also turned to impostor syndrome. One doctor confessed he did not have it. He understood what the others were talking about, but he just didn’t feel that way. He was always sure of himself.

A few months after that conversation this doctor made a very serious medical mistake. Can’t remember if it was fatal or not, but it was major, and had consequences for the patient and the doctor himself.

Once she had told this story, my friends and I concluded that impostor syndrome actually serves an important function. It forces you to check and re-check your work, making sure you haven’t made any mistakes, consider different approaches, and generally be critical of yourself in a positive sense.

So cherish your impostor syndrome. Don’t trust people who don’t have it.

I found an example of how we web developers wield CSS as black magic and reinforce its image as a weird and impossible language. Also, I learned to explain block formatting contexts.

Today, let’s demystify block formatting contexts in two ways:

1. To establish a block formatting context, don’t use overflow or container-type or any other black magic. Instead, use the "semantically correct" display: flow-root.
2. To explain a block formatting context, tell people that it’s an element that’s ready to scroll.

Solving a bug

Paragraph doesn't work!

In my previous post I placed the CSS Day teaser image at the top of my post, where the floating bar that I call "floater" has been since at least 2003. Narrowing the page made the image fall to the bottom of the floater. We’ve all encountered this; it’s annoying.

I did what I do best. I exuded a noise on the Socials that the uninitiated take for plaintive mooing but is in fact a powerful summoning spell. Three friendly spirits, Temami Afif, Miriam Suzanne, and David Baron, appeared out of thin air to enlighten me.

Temami told me to use container-type: inline-size. This solved the bug. The paragraph now took the existence of the floater into account when calculating its width. No more falling to the bottom.

Fixed. But how? Why?

But why? What sort of black magic was this? Some sort of obscure side effect of container queries that I’m not acquainted with? (My experience with container queries so far is rather limited and basic.)

Then I had an insight and replaced the container-type with overflow: auto. Yup, that still worked.

Clearly, in addition to creating a container, container-type also engages the ... thingy ... the whatsitcalled that also works with overflow: auto ... the ... the block formatting context (or BFC).

I tested this by replacing the overflow with display: flow-root. It still worked fine. So making the paragraph a BFC solves the issue. Better still, I now sort-of understood what was going on, where I had been bewildered when staring at container-type.

CSS semantics

This led to demystification #1: if you want to make something a BFC, just do it. Use display:flow-root. Be "pedantic-semantic" about it. Don’t use any of the other declarations that establish a BFC as a side effect. The developers who inherit your code will thank you for it.

I understand why people use other declarations. While figuring out what was going on I intuitively reached for the overflow: auto I’ve been using for more than twenty years to keep floats in check.

But that was the wrong reaction.

I didn’t want the paragraph to scroll. I didn’t want it to become a queryable container, either. Thus overflow and container-type were semantically incorrect. They reek of black magic and reinforce the image of CSS as this weird language that is impossible to learn.

• Dev guy #1: You have to give the paragraph with the image scrollbars in order to solve the float bug. How weird is that??!?
• Dev guy #2: Yeah, CSS sux!!!
• They solemnly vow to go even fuller stack.

Getting ready to scroll

By this time I kind-of vibe-grokked why the paragraph should be a BFC, but didn’t yet understand the exact reasons. David Baron came to the rescue and handed me demystification #2.

A BFC is a block that’s ready to scroll. (Well, it’s more complicated, but this is a good first approximation for newbies.) Take a look at this example.

Are the two paragraphs with the light background colour, the ones that say they are not a block formatting context, ready to scroll? That is, what would happen if the paragraph itself would have a scrollbar?

• If the first paragraph would scroll, what would happen to the floating span? Would it be slowly pulled inside the paragraph, pixel by pixel? And if it did, what would happen to the second paragraph?
• And what about the second paragraph? If it would scroll, would its content wrap around the floating span, one line after the other as they scroll into reach?

You know the answer, I know the answer. That’s not how it works. That’s what I mean when I say these elements are not ready to scroll.

Let’s give the first paragraph an overflow: auto. You know how it’ll react, and so do I, but you may not have thought of it as getting ready to scroll. I sure didn’t. Yet that’s exactly what happens. The floating span is retracted into the paragraph so that it can scroll without influencing anything outside itself.

The effect becomes even clearer when we just use display: flow-root. Now the paragraph stretches up to accommodate the floating span. That makes it ready to scroll.

It won’t actually scroll, but that doesn’t matter. There are plenty of declarations that establish a BFC without scrolling, such as overflow: hidden. It should just be possible to scroll it.

Finally, what about the second paragraph? If we make it a BFC, it also gets ready to scroll.

In this case, getting ready to scroll means making sure it’s not able to be influenced by the float. The only real option of doing that is to move the entire block out of the way of the float. So that’s what happens, and it was this aspect of BFCs that solved the problem I had at the start of this article.

You’ll have to be much more specific and explicit if you aim for completeness, but a quick-and-dirty "getting ready to scroll" should be enough to explain the core concept of BFCs.

CSS Day will take place on 11th and 12th of June in Amsterdam. As always, our venue is the Zuiderkerk. If you’re thinking of buying a ticket, please note the following:

• From 1st of May on, that's in two weeks, only Stripe payments will be possible. Buying tickets on invoice will become impossible. That matters to some large companies.
• Two weeks later, on 14th of May, the ticket price will go up from €675 to €750. Orders of five tickets or more will still get a 10% discount, but over the higher price.

I like the speaker list, but I’m biased because I created it. But maybe even more important is our attendee list. Take a look and you will probably find a few people you follow — and they’ll be there not as speakers but as attendees. That means they will have time to geek out about CSS with you and you’ll become their friend, not their follower. That's the value of CSS Day.

See you there?

A month ago I I created a sales page to sell about two-thirds of my board game collection. (If you're in Amsterdam and want to buy one of them, hey, let's talk!) I show sold games in a separate table until they’re actually collected — and I decided to hide that table if it contained no data.

main:has(tbody:empty){
	display: none;
}

Isn't CSS cool nowadays?

Except in Safari (Mac and iOS). No content at all was visible. Unless you resized the page. Vertically.

It says something shameful about my testing habits that it took me a month to notice. Then again, it was browser bug #32820 or so in my professional career.

(Meanwhile I removed the offending rule, so you can only see the bug on the bug report page.)

The bugs these days

The problem is, I'm just not very impressed by today’s browser bugs. The ones we had 25 years ago, when Netscape and IE battled it out, now those were the real deal! And they remained bugs for years. Nobody fixed bugs within 24 hours.

But today’s web developers start crying as soon as pretty much anything goes even slightly wrong, and I simply don’t take the silly yelling youngsters who encounter My First Very Minor Browser Cncompatibility seriously. And no, I’m not old.

This goes beyond a minor incompatibility, though. A selector that should work doesn’t work. On my page. Somebody really should do something.

Was that somebody going to be me? Did I feel like solving the bug, as I did in the good old days? Or would I just remove the offending selector and let it be?

To my surprise, I wanted to prove I could still solve a browser bug. I mean, I have this huge brain lobe dedicated to browser incompatibilities, but it kind of atrophied in the past ten years. Could it still handle a juicy bug?

It could. Actually, the process went fairly smoothly and was enjoyable, and I even found a partial workaround.

Findings

My findings, summarised:

• y:has(x:empty) or :has(x:empty) y is checked for emptiness only once, between DOMContentLoaded and load.
• Emptiness is resolved incorrectly if element x is filled by a JavaScript onload AND the body overflows the html vertically, but not horizontally.
• If this is the case AND element y has CSS lengths in viewport units AND element x is currently filled, resizing the window updates the styles of element y — permanently.
• A special case applies if y has display: none, as it had in my original page. See the report.

From the fix it appears that the problem was simply that :has was not updated after the :empty state changed. Initially I assumed that that was the case, but the wealth of extra bits and pieces of bug I found made it appear it was much more complicated. (I’ve never been able to figure out which of these details are important and which ones merely obscure the truth, but I tend to err on the side of over-reporting.)

Workaround

Adding a non-:has selector such as the one below fixes the bug. It needs a CSS declaration, but that can just be a variable that you never use. It has to contain the :empty element and select your y element, like this:

x:empty ~ * {
	--bug: 'solved';
}

:has(x:empty) y {
	// works!
}

This may not always work. In particular, it doesn't work for my original use case since I can’t write a selector for main that also touches tbody:empty without using :has.

main tbody:empty {
	// doesn't work
	// selects tbody instead of main
}

main:has(tbody:empty){
	display: none;
}

In order to truly solve the problem you’d have to remove the :has(:target), I’m afraid — so that’s what I did on my page. All the better that the bug has been solved.

Time and money

The process took me about eight hours: six for the research, and two for the report writing interspersed with some research — for instance, the workaround came from an idea I had fairly late in the writing process. And that doesn’t count writing this blog post.

Although I don’t regret spending a working day on this bug, it’s not something I’m going to do a lot of. I mean, conference catering proposals don’t check themselves, and sponsors and speakers need gentle reminders every now and then. This week I did less conference work than I had planned.

And this sort of bug squashing doesn’t make you any money. That’s part of the problem — it always has been.

But still, it was fun. It’s good to be back.

Until a year ago my conferences were exempt from this trend, but starting with performance.now() 2025 ticket sales became a lot more difficult. perf 25 didn't sell out, not even close, and that was a first. It was the sponsors that pulled the conference through — thank you for that!

Now that we're at the half-way point for CSS Day 2026 I can say we're definitely behind CSS 2025, though the situation is not as disastrous as for perf 25. It's quite conceivable sales will become better — these last three weeks are already better than the previous seven, and there will be late sales, no matter what. Still, my (as-yet unexplained) immunity to industry trends is over.

There are several lessons to be drawn from this.

From 2022 to about a year ago my theory was that CSS Day and performance.now() are focused, specialised conferences, while most of the complaining conferences were general ones. It seemed logical to me: specialise, and you'll attract specialists who won't go to a general web conference, and your ticket sales will remain strong. Now I find that this theory is not necessarily correct.

Cash flow

This year I'm implementing a solution that I've been talking about for ages with other conference organisers: more expensive late tickets. As an example, currently CSS 26 tickets are €675, but on 14th of May, a month before the conference, that price will go up to €750. See it as a lateness tax. I'm planning something similar for perf 26, but probably even more aggressive with three tiers instead of two.

I'm not very worried about sales effects: the number of people for whom €750 is a serious financial issue but €675 is not is probably negligible compared to people who have the budget anyway but are just late. (Or these might be famous last words, we'll see.)

Still, in addition to the total sales there's also the issue of sales timing. Right now I do not dare to order a barista or captioning for CSS Day. Attendees tend to really like them, but strictly speaking they're luxuries. When ticket sales are as unpredictable as they are now I balk at spending the extra ~€9K they would cost, though. If sales pick up considerably (or I find sponsors) I'll do it, but there's a practical time limit as well.

From about a month before the conference it's no longer really possible to place an order, since my favourite captioners and baristas will have accepted other jobs. So it's not just about the size of the cash flow, but also about its timing. And that's what makes late ticket orders such a problem. It's quite possible that, in hindsight, I could have afforded a barista and captioning, but the ticket sales just came too late.

Sponsors

It's hard to find CSS Day sponsors. Fortunately that does not go for performance.now(): barista and captioning are already covered by sponsorship contracts — and it's possible that once more it's the sponsors, and not the ticket sales, that will pull the conference through.

The problem here should be obvious: more reliance on sponsors means they'll get a bigger say in the conference. My conferences don't do sponsored talks at all, and I hope that continues to be the case. The perf sponsors are a great bunch, and they're typically driven by the engineers in the company, not the marketing people. That helps. A lot. I don't see them trying to influence the schedule.

But ... well, I don't have to draw you a picture of what would happen if that changes.

US extinction event

One of the things I worry about is that whatever extinction event took out the US web conference circuit will also take place in Europe. But I'm not entirely sure what happened, so I'm not sure how to avoid it.

Fact is that there are WAY fewer web conferences in the US than there used to be. When I worked for the ILF I did some research for sponsorship purposes, and I found few survivors. In fact, this is how my first round of research on the Socials went:

• Me: Hi, I'm looking for US web conferences. Know of any good ones?
• The world: [crickets]
• Me: ...
• The world: ... do you need more crickets?
• Me: ... nah ...
• Someone: Err ... Smashing?

The joke is, of course, that Smashing Conferences is a European organiser. And they don't do a 2026 US conference.

I heard two explanations for the extinction that sort-of make sense to me. First, Covid. In general, Americans are much more worried about diseases than Europeans, and where Europeans flocked back to the conference circuit in 2022, Americans did not; or not to the same degree, I'm not sure.

Second, even before Covid the US conferences had become over-reliant on sponsors (read: VCs), and they basically only treated topics the sponsors wanted to see treated. Nowadays that means a lot of AI, some AI for diversity, supported by a solid helping of AI. In contrast, my two conferences (28 speakers) will probably see a single talk about AI.

(A third factor could be Trump, but that only explains why non-Americans don't want to go to the US. It shouldn't affect internal US conferences, and the extinction took place well before 2025.)

I can't speak for the truth of these theories. The last time I was in the US was at Smashing New York 2024, and that seemed like a perfectly normal web conference with happy attendees and only a single talk about AI — but it was organised by Europeans, not Americans, so it's probably not representative.

Or is it? Is it the destiny of the Europeans to ride to the aid of our beleaguered American colleagues, for rescue or revenge? Or am I being overly dramatic and in love with my own words after my blogging break? Questions, questions...

For a while now I've been thinking about organising something performance-related in North America. I even did a little bit of work. But it all depends on how ticket sales go in the next few months. If they're bad I just don't dare to order (and pay for) anything.

The conference circuit is in a slump these days. That won't change as long as people don't buy tickets. And a good conference circuit is typically something that you start to miss only when it's too late.

Who among you noticed I didn't blog for over four years? [No hands are raised. Nobody even pays attention.] Right.

The story is boring. I used to run Movable Type, an old Perl blogging system, from 2003, when I started blogging, to 2021, when my ISP shut down. My original plan for moving to another ISP failed miserably. With only days on the clock I had to jump to an essentially random ISP who didn't support Perl, but did offer Wordpress.

So now I was left with no blog, but with this big blue 'Install Wordpress' button (div?) that both enticed and frightened me. I never felt comfortable pressing it. I didn't want Wordpress to take over the non-blog part of this site — I still run that by hand-coding HTML and FTP-ing it to the server — and it can't generate static HTML pages out of the box.

Then Paul van Buuren told me a partial install was possible, and there was a plugin for creating static pages. That sounded a lot better. So I decided to do a partial install for blogging purposes only, with the static page plugin — later.

But later became never.

Then I switched ISPs again, to get rid of the passive-aggressive tone of my old one, and because Jan van Hellemond, who now helps me out with the conferences, recommended it for various reasons. I moved over the conference sites a few weeks ago, and this week QuirksMode followed.

I asked Jan for advice on a blogging system, and this week it turned out he'd created a simple one himself. It's so new it doesn't even have a name. Let's see if it works. If you can read this it does.

So here I am, typing away in my static HTML file that I've always used to preview my blogposts in. Once I'm done I'll publish it with the newfangled publication system (really only an upload and a shell command). It's still a confusing process because it's so new to me, but it feels better than a massive Wordpress install.

And I may have something useful to say about CSS, once I've done some tests.

And BBEdit still remembers the macros I need for my blogging, such as Shift+Option+A for an external link, and Option+- for an em-dash.

It's good to be back.

These parts treat Grimhild's plot to kill her brothers in revenge for their killing of Sigfrid, the return of Dietrich von Bern from exile, and the death of a few main characters of the saga, ending with two version of Dietrich's own death. (Incidentally, I think I'm ready to defend the theory that the first of those two stories was written in Aachen at the end of Charlemagne's reign. Writing a proper scholarly article takes a lot of time, though.)

My original purpose was not only to continue my research, but also to learn a bit of PHP and to solve the thorny issues of footnotes (which really are sidenotes) on the Web. My 2020 solution, which you can for instance see here, was OK enough for a first try, but far from perfect. In particular, you will see that the current sidenotes can overlap one another; they're all positioned absolutely.

I'm hoping Anchor Positioning can help solve this; there was something with 'place positioned element here, but below any other positioned element', right...?