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...?

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.

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.

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.

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?

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.