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