Matthias Zöchling wrote on June 13, 2026 at 13:02

Speed is how you avoid reckoning. It guarantees you miss things, and you can’t learn from what you don’t notice.

A blog post full of wisdom, by @jim-nielsen.com
🔗 “Speed is Not Conducive to Wisdom”

Matthias Zöchling wrote on June 5, 2026 at 08:13

🚀 New article on gap decorations (coming soon) in CSS. I have a small obsession with clean layout lines, and this is the first time it feels easy to draw them without polluting the markup. Goes through the new properties, a playground, and some experiments… 👾

🔗 “CSS is filling the gaps with rules”

Great article by @utilitybend@front-end.social on styling grid/flex gaps. Makes me wonder if this should become a thing in tables as well.

Sure, we could override display: table-row to get there. (Though at some point we lost the table role in certain browsers when we did that, I hope that’s no longer the case.)

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.

So let me get right to it.

Questions and answers

Why did you start blogging in the first place?

I’ve been tinkering with websites since forever, and already in those early days I created pages that looked like blog posts about my personal life. Alas, these sites I’ve had in the late ’90s no longer exist, and even though I eventually got paid to make websites, in the first decade of the ongoing millenium I myself had no public-facing site to speak of.

It was more than 5000 days ago when I figured CSSence would be a good user name for someone who is very fond of Cascading Style Sheets, and I’ve pondered the idea of creating an online magazine, where I would write one article per month. I did start in January 2011, but I only managed to write seven long-form articles, meaning things already came to a halt after July.

I pretty much found myself in a similar situation as Max Böck, in the sense that I would find excuses to not write more. Thus, the site remained in a dormant state until 2015, when something ignited the spark again.

What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before?

I started on WordPress, but early on it was clear that I wanted to be in full control of the styling, without the limitations of a WordPress theme. I already had my own domain and webspace, only to have my initial deployment followed by years of “coming soon”.

My desire to be in control of the styling came at the expense of something rather important: I had no proper workflow to get the actual content out.

This changed with the aforementioned spark, I got back to blogging by writing on medium.com. Oh the irony, it took another place out of my control to get affairs on my own site in order. I started with my own lightweight solution, that I later replaced with the Metalsmith static site generator. Around that time I switched to publishing on my own site first. I even kept medium.com as a syndication target for a little while.

I got to the point where I was finally in control of everything. Not only did my site become my IndieWeb hub, I’ve also replaced MetalSmith with a static site generator I wrote myself.

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog?

Writing my own static site generator resulted in moving away from Markdown, nowadays all my pages are raw HTML files, which are part of the same GitHub repository as the hand-rolled generator.

So I write everything in the IDE, which currently happens to be VSCode, but I’m working on a simple HTML form (that is going to be part of the site), that enables me to create new blog posts faster, and even amend existing posts.

When do you feel most inspired to write?

An idea may errupt at any time, but sometimes it’s as simple as stumbling upon an issue that needs investigation. Down the rabbit hole I go.

Do you publish immediately after writing, or do you let it simmer a bit as a draft?

Immediately. I blog about HTML, CSS and sometimes even JS. In the fast-paced world of web development, staying in draft makes little sense. The only reason something doesn’t get out immediately is because real life gets in the way. And there is more real life than ever, as my family keeps growing. Currently the household consists of (in order of appearance): Wife, dog, husband, child #1, child #2, and most recently child #3.

What’s your favorite post on your blog?

It’s always the one that I’m working on, i.e. the one that I’ll publish next.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature?

Jeremy wrote that he likes making little incremental changes. So do I. In the early days, doing a complete overhaul was appealing, but today my site has over 300 pages. Luckily the markup I have in place is versatile, this allows me to simply add a new theme and make it available on my Settings page, which is a different approach to redesigning in the open. At some point it may make sense to make such an added theme the new default. But keeping the old themes around allows me to grow my own CSS Zen Garden.

Next?

On the one hand I’d like these questions answered by anyone who follows me on social media, but on the other hand I have a very specific request: If you aren’t a blogger already, why not start in 2025? Go ahead and create a blog, and then take part in the Blog Questions Challenge. By doing so you already have your first blog post.

Comments

No comments have been added so far.

In case you are wondering, a CSS Day cannot be squeezed into a single day. Contrary to my previous visits in 2016 and 2018, where Thursday had a special theme with dedicated talks, this time it was just a plethora of great topics scattered across both days.

Day 1

And this is the first half of the plethora.

Talks & Speakers

• “Web Design Engineering With The New CSS” by Matthias Ott
• “CSS Layout” by Rachel Andrew
• “Utility-First CSS” by Sarah Dayan
• “Character Modeling in CSS” by Julia Miocene
• “Problems Solved by OpenType Details subjectively improved by OpenType Layout Features and CSS” by Roel Nieskens
• “Standardization Stories” by Elika Etemad
• “The Garden and The Treadmill” by Stephen Hay

Day 2

As if the first day wasn’t amazing already, look at what Friday had to offer.

Talks & Speakers

• “Over-engineering Your CSS” by Kevin Powell
• “Accessibility and CSS” by Sara Soueidan
• “Anchor Positioning” by Tab Atkins-Bittner
• “Scroll-enhanced Experiences” by Carmen Ansio
• “Impactful Experimentation” by Roma Komarov
• “How to Teach CSS” by Josh Comeau
• “CSS Masonry Layout” by Nicole Sullivan

Comments

#CSSDay {
	counter-reset: marriage;
}