Matthias Zöchling wrote on August 5, 2026 at 06:53

Nifty!

@supports at-rule(@supports) {
	/* ✅ The browser supports `@supports at-rule(…)` */
}

As seen in “Detect at-rule support in CSS with @supports at-rule(@keyword)” by @bram.us

Sebastian Hädrich wrote on July 25, 2026 at 02:29

Is there a way to indicate “[sic]” to a #screenreader without it reading the brackets verbatim?

For two reasons: Someone renamed Twitter, but more importantly, I deactivated my account 30 days ago, meaning the grace period is over and the account is gone. No big deal, I replaced it with Mastodon in 2022 and after an unnecessary course correction I stopped tweeting in 2024. But the account still existed.

For two reasons: To avoid link rot, and to prevent others from grabbing the account. So why now? What changed?

I stopped caring. But in general it’s not a good idea to have any kind of association with the platform. Even when you think it had reached rock bottom, it manages to take a turn for the worse. Good riddance.

Better times

Before turning off the lights, I picked a handful of tweets so I could create an image gallery. I obviously did this way too late, conversations with people that themselves had deleted their accounts have already been broken. And even though I have all the data required to restore these on my own site, I couldn’t be arsed to spend the time to create mockups just so I could take screenshots.

But I did sneak something in. For older tweets that predate a special 💒 day in my life, I made sure that my birth name was shown in the screenshot. After all, I did use the platform for more then a decade, and a lot has happened during that time.

I suppose the gallery is my personal acknowledgment that Twitter was the place to be back then.

Okay, fine. I’m not really into nostalgia. I just wanted an excuse to do something with masonry layout, and this is problably my one and only chance. Goes without saying, support for grid lanes ain’t there yet, so I did the next best thing, or several things, depending on the site’s page style.

• On an unstyled page, the images are inline elements, as one would expect.
• In the Basic page style, I used floats. 😬
• In the Advanced page style, I called flexbox to the rescue.
• For the time being, the Elegant page style is almost an exact copy of Advanced, but I’ll replace it with actual grid lanes when browser support finally gets there.

Comments

No comments have been added so far.

Train delays and extreme heat cannot take away from the fact that it was once again a great experience.

Talks & Speakers

• “Fighting Hardware Obsolescence With Greener Frontend Code” by Björn Ganslandt
• “Rslidy: Lightweight, Accessible, and Responsive HTML5 Slide Decks” by Keith Andrews
• “Web Performance: What Actually Matters - a deep dive into Core Web Vitals, performance debugging, and real-world optimizations” by Stefan Schintler

(Short) Summary

Björn kicked it off with a topic that truly hit home, fighting hardware obsolescence is something I deeply care about. Progressive enhancement and testing on older devices can keep hardware around for longer, thus slowing down the increase of e-waste.

Keith then talked about Rslidy, which allows you to run HTML slide decks in the browser. Its file size is already impressive, but guess what, it comes with zero dependencies. Goes without saying, Rslidy has been used to present Rslidy, clearly a case of dogfooding.

Finally, Stefan sealed the deal by talking about what actually matters when it comes to web performance, with his fresh take on Lighthouse scores.

Comments

This is the third blog post of my Tales from the hospital miniseries. I wrote about edge cases in web design that I encountered between surgeries.

1. Breakpoints
2. Breaking points
3. Breaking bad

Contrary to my earlier hospital encounters this year, my third visit was planned. As are most site designs not an accident, someone did put in the effort.

Which makes one thing even more worrisome: There being so little emphasis on the actual content these days must have happened according to someone’s plan.

I cannot find the source, but I saw a conference talk on the subject, and this was my takeaway: On desktop, only 30% of the initial viewport is filled with the content someone came for. On mobile, it’s 17%. Whether I remember these numbers correctly does not matter, because we can see for ourselves. Open any popular website in incognito mode, and try to spot the content. Here’s what I got when I went to FIFA.com.

On mobile, I see a glimpse of the site’s primary navigation, but almost the entire screen is covered by letting me know that they care about my privacy, an information so long it requires scrolling. On desktop, two popovers compete for my attention. I didn’t calculate how much content I can still see. On desktop I’d anyhow have to look past the fact that the content is dimmed. On mobile it’s easy, as the answer is zero percent.

Now, you could argue that some obstrusive banner is only presented on first visit and can be dismissed permanently. But usually it doesn’t stop there, because many sites also want you to look at advertisement, sign up for their newsletter, and download their app. And let’s not forget these popovers that open automatically if you haven’t interacted with the page for more than two seconds.

Past to present

While the early days of the web may be compared to the Wild West, eventually sites became more polished, but along the way something must have happened that made us pivot to the current state of web design. We are quick to blame legislative directives like the General Data Protection Regulation. Sure, it did cause all those pesky cookie consent banners, but the European Union does not require you to inform your visitors that they should prefer your app instead, nor to come up with any of these other questionable UX patterns.

There’s a chance I’m seeing the past through rose-tinted glasses. Maybe the situation was never really great, except for one point in time: The rise of the mobile web and in turn responsive design required us get rid of a lot of the crap that had been sitting next to our content, but after that brief period in the first half of the last decade, site design started to deteriorate again.

Working on the web, I get to enjoy a lot of personal blogs that show me whimsical design instead of said questionable patterns. But those are the exception. And while this miniseries was supposed to be about edge cases in web design, I’m afraid what I’m describing in this third blog post has become the norm.

So how do we get out of this mess?

Present to future

Apparently it has to get worse before it gets better. And it sure does.

Matthias Ott concludes that we no longer get people sent our way.

Generative UI doesn’t link to your article, necessarily. It absorbs your article, synthesizes it into a widget, and presents it as Google’s own answer. Information agents don’t send users to websites.

Great, without visitors there’s no need to fix all these broken sites, right?^[1]

My personal site shows no advertisement, I pay it out of my own pocket. So I don’t mind whether people come to my site or not. I happily provide other forms to consume my content, like RSS. Back in the day, when we were all still trying to figure out if XHTML is the way to go, I envisioned a future where the use of valid XML would give us an easy way for humans and machines to consume our content. But the latest turn of events, namely providing instructions for LLMs so AI can easily consume the content, is quite something. Wait, what?

Well, yes, we actually do “fix” broken sites, just not for people, but for AI. Amazing! After an eternity of being told that improving accessibility is hard, along comes AI, and now we have no problem spending the time and effort to make sites accessible for something that requires vast amounts of energy and water, as if there was no climate crisis to begin with.

When a society is unmoved by decades of advocacy from disabled communities but springs into action when a tech company needs the same accommodation, it reveals whose claims on shared resources are treated as legitimate and whose are treated as optional.

I don’t see a silver lining at the moment.^[2]

Comments

Manuel Matuzović wrote on June 2, 2026 at 06:51

I should probably do a 2026 update of my HTML boilerplate post. I just need to figure out what changed in the past 5 years.

Sara Joy wrote on April 13, 2026 at 09:36

Quick front end question:
How often have you seen elaborate mid-sentence CSS flex and gap or padding styling within React apps, when all that’s missing is what I’m calling a “React space”: {' '}?

A variation selector is a Unicode code point that, when placed immediately after another character, signals a specific presentation preference to the renderer. Variation selectors produce no visible output of their own — they are invisible modifiers.

Of particular importance are the last two, VS15 and VS16, because they act as the emoji/text presentation toggle. It’s worth noting that not all emojis come in both forms, but if we look at those that do, appending the variation selector can make a difference.

When VS15 is appended to a symbol, it forces it to be displayed as text (black and white glyph). Contrarily, when VS16 is appended, it forces the color version to be displayed (emoji).

This leaves us with the default case, i.e. an emoji that is all by itself, without variation selector. How will it be displayed? While there should be a simple answer, in practice it’s a bit more complicated, as the article I just quoted explains.

But what I actually wanted to talk about is what CSS adds to the mix with the font-variant-emoji property. Safari does not support the property (yet), in other browsers it only has an effect on emojis without a variation selector, which makes sense.

Long story short, I created a test page^[1] to see how emojis are presented, and to see what the impact of the different values of font-variant-emoji is. While the values text and emoji live up to their purpose, the values normal and unicode always resulted in the text form, independent of operating system, web browser, and emoji used.^[2]

Showcase

View “Unicode meets font-variant-emoji” on CodePen.

Comments

We all know that the smiling face with sunglasses 😎 exists in Unicode, but what about creating it manually? Putting 🕶️ on 🙂 should take us there.

After finishing the initial animation, I realized I could throw in another one, so I made the smiley squint while the glasses are off. In doing so, I paid an homage to the original animation that started it all.

I also realized that I could add sunglasses to many other emojis. Put them on a cat 😺, you get a cool cat. Nothing is off limits, but I beg you to leave the monkey 🐵 alone.

Showcase

View “Animating Emojis - Sunglasses” on CodePen.

Comments

This is the second blog post of my Tales from the hospital miniseries. I wrote about edge cases in web design that I encountered between surgeries.

1. Breakpoints
2. Breaking points
3. Breaking bad

For the first couple of weeks I refused to join the hospital Wi-Fi, instead I relied on my phone’s data plan. The problem is, there are thousands of patients and personnel all connecting to the same set of cellular towers, which obviously puts a burden on the system.

What I got in terms of connection speed I would rank somewhere slightly below 3G. Videos on YouTube would load sometimes, depending on the time of day. All other videos did not, I got network errors, most likely due to improperly handled timeouts.

Videos aside, for the majority of websites to load in the first place, I had to be very patient. (Not a problem, I’ve been a patient after all. Get it? Sorry.)

Here’s what I got trying to access a repository on GitHub. The HTML did load, but no stylesheets nor any JavaScript had been applied.

No stylesheets? Might as well use a text-based web browser.

Client-side rendering

How well a site fares also depends on the underlying technology. If you are lucky, the server already returns your requested content in the retrieved HTML.

On the other hand, if you have to wait for a large JavaScript file to get requested, downloaded, parsed, and executed, so that it then hopefully will fetch actual content, there’s a chance some step along the way won’t be successful, especially on a slow connection. As a result, you may be starring at a blank page indefinitely, usually without any information that something went wrong.

Put simply, I have a feeling that the “HTML” you got looks like this, courtesy of insert name of JavaScript framework:

<!DOCTYPE html>
<html lang="en">
	<head><!-- … --></head>
	<body>
		<script src="/app.js"></script>
	</body>
</html>

Whenever that’s the case, someone did not do the progressive enhancement homework.

A call for lightweight websites

Don’t leave your site visitors empty-handed, do this instead:

• Prioritize content.
• Put emphasis on performance.
• Fail gracefully.

I’ll keep this essay short, because I’m gonna hand over to Marijke Luttekes, who already wrote what needs to be said in her superb article »Why light-weight websites may one day save your life«.

I do not see as much talk about website performance and size as I would. Usually, the people talking about it are the artisans who care, or those who have been told by tools like Lighthouse that their stats are wrong.

On the upside, my own site performed well on said slow connection. Am I one of those artisans Marijke is talking about?

Comments

No, not on this site in the foreseeable future. I like my current way of doing incremental changes.

… is what I wrote last year about this site’s design, only to start working on another redesign a couple of months later.

Well, guess what, after working incrementally on it from February to May, I think I’m done. But now it’s November, and you still see the to-be-replaced design. What gives?

Despite all those incremental changes, there never was a banner message indicating an ongoing redesign, stating “if things look wonky, that’s why”, because those changes remained hidden. In the unlikely event that someone headed over the my Settings page, they could have encountered the new design in the page style dropdown, which is where is was (and still is) buried for all those months. In other words, I’ve been redesigning in the open, hidden behind a flag.

This may not work for everybody, as not everyone has multiple styles on their site, let alone a Settings page that allows you to choose a style, but there are other ways to pull this off in the open. Alas, they are not the scope of today’s article.

Personally, my stategy has served me well, because the new design uses a lot new CSS features that are not yet classified as widely available in Baseline terms, so it remains to be seen when I’m going to make the switch, i.e. when the new design will become the default. To make things worse, I still like my old design more. Obviously, it will eventually happen, because writing CSS in 2025 is different, especially when compared to the CSS I wrote four years ago, when my last major redesign took place. In other words, looks aside, I like the new CSS under the hood a lot.

Whenever I do a major redesign, I jot down a couple of noteworthy facts, which is exactly what I’ll do for the remainder of this editorial.

Starting from scratch

A clean slate can be very liberating, but in my case I had to be backwards-compatible at the same time, because changing the HTML meant I had to retrofit such changes into the existing design(s). Luckily, the semantic markup I had in place was very capable of housing the new design too, only minor tweaks were necessary. Most importantly, no additional wrapper divs had to be introduced. 😌

Included features

Okay, no more stalling, let me run through the interesting bits.

Native CSS nesting

I started using native nesting for everything: Not just regular selectors, but also pseudo elements and media queries. When I wrote »Is CSS alive«, my verdict on nesting has been Take it or leave it. To my own surprise I grew very fond of it. Just make sure that your selectors do not get unnecessary complex, don’t let your nesting levels run too deep, and avoid the gotchas that come with nesting.

Nested color scheme

Yeah, the new design features a dark color scheme on the top level, but the actual content adapts to user preference. Confused? I already blogged about this technique in depth in my »Nesting color schemes« essay.

Logical properties

I’m a big fan of logical properties, and by starting from scratch I was finally able to use them exclusively.

Media queries & breakpoints

I was leaning towards Intrinsic Web Design to let my content roam free, in hopes of needing little to no breakpoints. But I didn’t achieve that in this redesign. It turned out to be almost the opposite, for the first time I even have additional tweaks for screen sizes below 360 pixels, intended for smartwatches. In said smartwatch territory I even made sure that my site works on circular displays.

Layout …

Floats are back. Yes, you read that right, but obviously I’m using floats for their true purpose, not in the hacky way we did layout in the past. Floats are for minor things, the heavy lifting is done with Grid and Flexbox. And I even ended up with my first use of display: contents.

… and more

Speaking of using a property for the first time, in the new design I even made use of border-image^[1]. Just like floats that’s something from ye olden days. We used border images to do weird things in the past^[2], but there are lots of clever ways you can use them today.

That’s about it, but if you look closely you’ll find text-wrap’s pretty and balance options, the clamp() function, and more. Color is the only thing I haven’t fully embraced yet, I’m still predominantely using hex notation and the sRGB color space.

One last thing: Like in previous redesigns, the site navigation (and footer) is a defining feature, and this time I had some fun with the number of columns.

Still hidden

I’ve named my new page style “Elegant”. As stated, at the time of writing this post, it hasn’t become the default yet, I’m still showing the old “Advanced” style. You can head over to Settings and flip the switch yourself.

With all that being said, I have a strange feeling that the next redesign is right around the corner.

Comments

Usually I do a little coverage of the event, but it was overshadowed by current events [content warning: disturbing scenes]. Violence has no place in society. 💔

Comments

Comments are closed.