Martin Michálek · Web & Performance

WebExpo 2026 in Prague: Switch Angel, Daniel Cuthbert, Mike Kus & FrontKec

Mon, 18 May 2026 00:00:00 GMT

An invitation to WebExpo 2026: Switch Angel, Daniel Cuthbert, Mike Kus & FrontKec

WebExpo, the big web conference here in Prague, lands at the end of May this year (May 27–29), and I've of course already blocked out the city's Lucerna venue in my calendar.

I went through the program and picked four talks I'd go to in a parallel universe — the one where I don't bump into one of you right before the talk and get lost in conversation.

I also helped curate the frontend talks for FrontKon. Our picks there cover a broader range. Here's my shorter, personal selection.

Four talks I'd hate to miss {#talks}

Switch Angel: Patterns for restarting the world
The opening keynote. A well-known streamer, live coding music in Strudel, electronic pop in real time. Really looking forward to this one.
Daniel Cuthbert: From HAL to Replicants
Agents, payments, security — a world where AI doesn't just write your commit messages but also makes decisions for you. I don't think this will be sci-fi storytelling; it'll be hard reality.
Michal Kessel Shitrit: Don't trust the bot
How not to send your users straight to hell with AI-generated microcopy. UX writing with common sense — exactly what I'm dealing with at work right now.
Mike Kus: Design like no-one is watching
Design without fear of AI templates. A big name from the UX scene calling for creative instinct. Where do I sign?

Recording FrontKec on Wednesday: a chat about the first day's topics {#frontkec}

After day one, just before 6 p.m., I'll slip into the small cinema inside Lucerna with Robin Pokorný and we'll record a live episode of FrontKec.

We'll recap the day and talk through the talks. As usual, with you in the audience. Informal, just like the other episodes — only this time with fresh conference material in our heads.

Come say hello.

A little discount from the garden…? {#discount}

The code MICHALEK26 saves you 1,000 CZK on a ticket (both the conference ticket and the bundle).

Premium workshops aren't included in the discount, just so you know.

See you in Lucerna?

Will AI Kill SaaS? Let's Think Again

Fri, 06 Mar 2026 00:00:00 GMT

AI is supposedly going to kill SaaS. Let's think about that one more time

We live in a world where one dark AI prediction is immediately replaced by the next. It's worth remembering that we humans are absolutely excellent at exactly one thing: overestimating how much we know about domains we don't actually understand.

This particular brand of irrationality hits hardest among those of us who love the attention that doom-laden predictions reliably generate.

So let's get concrete and talk about the SaaSpocalypse — the coming apocalypse of SaaS companies. Software stocks are sliding because SaaS apps (Software as a Service) supposedly won't be needed anymore. Everyone can just write their own with AI.

We irrational humans and our AI catastrophes {#irrational-humans}

Yes, AI is changing the rules of the game. But not every rule change means the game is over.

Look at the pattern:

"Juniors won't be needed. Who'll look after them?!"
Everyone says it, and demand for junior developers really is falling. Except it isn't falling because of AI alone — it's the broader economy too. And partly because it's deferred demand. The productivity boost AI gives to existing employees won't grow forever.
"Jobs are vanishing. We're all out of work!"
Like when Jack Dorsey, former owner of Twitter, cut thousands of people at Block. Catastrophe — we're all losing our jobs! Except the whole thing was a bit different: the company simply needed to slim down. That's textbook AI washing — blaming (or crediting) AI for a decision that had other reasons entirely.
"SaaS faces its biggest test in twenty years. And it probably won't survive!"
…write others. It must be true. Some editor slapped a headline on it like "The age of digital cannibalism has arrived: AI has started eating software from the inside." Personally, I'd prefer AI to eat the editors who come up with headlines like that. But to the point — the SaaSpocalypse is exactly what I want to address here.

How many of these "this whole industry dies in five years" catastrophes have we lived through in the last decade alone? An electric car in every driveway within five years. Blockchain changes everything. Factory workers paid in crypto. Energy breakthroughs.

Let's meet in the Metaverse, where we'll watch the end of an entire continent brought on by whatever this year's policy panic happens to be.

The world is changing and will keep changing — but perhaps a little differently than the evangelists proclaim.

Back to SaaS.

SaaSpocalypse {#saaspocalypse}

We run a SaaS product, so this topic genuinely interests me. AI has an enormous influence on everything in this field. We use AI; we strategically track everything that's happening. It's a big deal.

But at the same time, I see that people aren't behaving rationally. Investors least of all. Let's illustrate it with a chart that's trending hard right now — the one showing software stocks falling off a cliff.

<figure> <img src="/prirucka/images/saaspokalypse.jpg" alt="SaaSpocalypse. The fall of software company stock prices"> <figcaption markdown="1"> Here we see the result of a vote among experts on SaaS, AI, and the future. </figcaption> </figure>

The reasoning goes like this: software development is undergoing a tectonic shift. Vibe coding has opened up software development to the masses.

Every other CEO is now a programmer.

Designers are turning into "builders."

Our cat would be building its own SaaS by now. If we had a cat…

Plenty of AI consultants are shouting that Cursor — interface-wise, a fairly thin layer on top of the developer editor VS Code — is "the best software ever created."

I understand the enthusiasm. But the enthusiasm, the dark predictions, and ultimately the stock price moves all point to the same thing: a lack of understanding of how software development actually works.

Let's illustrate it with a made-up example.

Somewhere around the twelfth LinkedIn post on the subject, I got annoyed. And invented Joe.

Joe and his invoicing software {#joe}

Once upon a time there was a guy named Joe. Joe is a marketer and a bit of an AI consultant. Joe is a fictional character, just to be clear.

Joe had been paying for an invoicing SaaS for years. But yesterday he "vibe-coded" a mortgage calculator, got swept up in the excitement, and today decided to stop paying for the SaaS and build his own little invoicing gadget instead. Because the internet told him developers won't be needed anymore.

Day one — euphoria {#day-one}

Joe opens Cursor, throws together some kind of spec, and after a few iterations he has a solution. He types in the data, gets an invoice — in PDF, no less, and prettier than the one his old service produced. He immediately runs off to post on X: "In two hours of work I built the same app I was paying $120 a year for. SaaS is dead!!!"

Welcome to the beautiful new world, Joe, where everyone can program anything!

Day two — what is git? {#day-two}

Different client. Different invoice. New fields are needed. So he just writes a prompt asking Cursor to tweak it. But something breaks in the process. Now even the original invoicing doesn't work anymore. Joe doesn't understand the messages in the terminal.

He'd love to roll back to the previous version. He's heard there's this thing called git. But there's no time to study it. In the end he hacks his way through somehow, but he's lost two hours he'd meant to spend writing about how vibe coding is changing the world.

Welcome to the world of version control, Joe.

Day three — weird messages in the terminal {#day-three}

Joe spends the whole morning learning git. People on X said even marketers need to know it now. So he can version his work, and when something breaks he steps back. Which means he can finally tackle those weird messages in the terminal.

After two hours he gets it working, though he doesn't really know how. He's lost all track of time and never did that analysis for his client — but he is now, in addition to a marketer, basically a programmer. After all, programmers are the people who deal with weird messages on a screen.

Welcome to the world of developer fundamentals, Joe.

Day four — wait, the invoice is in euros? {#day-four}

The next day he needs to send an invoice to a client in another country. Joe's stomach drops, because that means adding the option to invoice in a foreign currency. In Cursor that turns out to be trivial, but… hold on, how does the exchange rate and currency conversion actually work…? Joe goes off to study; an hour later he has it, results and all.

In the end the client returns the invoice anyway — apparently because of incorrect handling of cross-border VAT and the reverse-charge mechanism. Joe is caught off guard and starts digging through the documentation of the SaaS app he stopped paying for a few days ago, hunting for the details. Three hours later he pulls it off and is finally ready to invoice across borders.

Welcome to the world of managing know-how and product features that SaaS app authors handle for you, Joe.

Day five — "How dare you?" {#day-five}

Joe is getting a little frustrated now, because he hasn't gotten much done over the last several days. But he's already drafting an X post in the genre of "what I learned building my own invoicing solution."

Then an email from a client lands in his inbox — the one he sent his very first invoice to four days ago. The subject line reads "How dare you?" Joe's stomach drops, and it's about to get worse. The client attached a screenshot from his invoicing app. In place of the polished, AI-generated logo of Joe's consulting firm, there's just… uh… a porn image.

After Joe showed off his invoices on X, someone had a little fun with them.

Welcome to the world of online security, Joe!

<figure> <img src="/prirucka/images/vibe-coder-depression.jpg" alt="A vibe coder in euphoria and in deep depression"> <figcaption markdown="1"> Joe's journey. </figcaption> </figure>

And what happens on day six, dear readers?

Joe goes off to renew his SaaS subscription.

Whatever you think about how realistic the story is, it hopefully leaves you with at least a basic mental model of what most SaaS services actually provide.

SaaS is paid transfer of responsibility {#responsibility-transfer}

Because SaaS isn't just software.

SaaS is often a deeply complex technical infrastructure (one day I'll try to sketch out everything that goes into testing web performance in PageSpeed.ONE). SaaS is domain knowledge of the problem. SaaS is the know-how you accumulate as the author of an app. SaaS is product vision, communication with your audience, and discovering problems a vibe coder can't even imagine. SaaS is solving for stability, security, and speed.

SaaS is taking responsibility for your problem. Fakturoid takes on some responsibility for your invoicing and part of your financial management. We at PageSpeed.ONE take on, through our SaaS, part of the responsibility for the performance of your websites.

No matter how good it gets, AI won't take responsibility for anything.

Programming isn't just writing code. That's why AI won't replace all programmers.

SaaS isn't just a programmed app. That's why AI won't replace all SaaS.

Vibe Coding: 25 Years of Building Websites, the Last Two Completely Different

Tue, 10 Feb 2026 00:00:00 GMT

Vibe Coding: I've Built Websites for 25 Years — the Last Two Months Were Nothing Like It

Vibe coding is a hell of a revolution. It's deflating the cost of writing code for developers. And it's opening up the building of websites and other digital products to a much wider crowd than ever before.

Vibe coding is also a bit of a trap. A trap for people who think they can get by without developers — or without developer thinking. And for developers themselves? For some, a huge opportunity. For others, pain.

I thought my site Vzhůru dolů was basically dead. Vibe coding brought it back to life — not just technically, but editorially too. If I write only one article this year, it has to be this one.

I've tried to build this piece as a collage: motivation, small essays, and practical tips. As for the topic itself, I'm currently in the head-exploding phase. So take me with a grain of salt — but we have to start here.

Swept Off My Feet {#riding-the-wave}

I spent more than 20 years actively building web applications, and I've been circling web technologies for 27 years now. But I've never experienced anything like this in the field. And I'm not alone:

"I just sat down with Windsurf and in three days I have a new version that within a week will do more than my nine months of work. It's genuinely insane."

– <cite>Petr Pixy Staníček</cite>

Vibe coding democratises technology and development work. It makes it accessible to everyone:

"I sat down with Wix Vibe and in two hours I had a finished election campaign site, CMS included. That used to be several weeks of evening work in WordPress."

– <cite>Michal Berg</cite>

But developers and technically skilled people are not out of work. They have an advantage and a head start — as long as they don't sleep through it. The window of opportunity is open. Wide open.

Okay. Beyond the enthusiasm, let's also try to stay sober:

"When you know exactly what you want, and you also know the best way to do it, AI saves you a lot of work. When you don't, the result can be very bad."

– <cite>Marek Prokop</cite>

"Vibe… What?" {#vibe-what}

Let's start with a definition.

Vibe coding is a way of programming where you describe your intent in natural language and AI generates the code for you. Instead of writing individual lines, you talk to a model about what you want to do.

The name comes from Andrej Karpathy:

"…you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

– <cite>Andrej Karpathy</cite>

My main tool is Cursor — an editor built on top of VS Code with AI baked in. There are others: Windsurf, GitHub Copilot, Google's Antigravity is having a moment, and plenty more. What they share is that the AI understands the context of your project and can actually work inside it.

<figure> <img src="../dist/images/original/vibe-coding-cursor.jpg" alt="Cursor in Agent mode"> <figcaption markdown="1"> Cursor's Agent mode is glorious — especially when you keep thinking like an engineer. And the interface is familiar from VS Code. </figcaption> </figure>

Cursor has an Agent mode where the AI works autonomously. It runs the terminal itself, reads files, installs libraries, writes to multiple files at once. You approve the work or steer it in a different direction.

The difference from traditional development? You're not wrestling with syntax, not googling documentation, not writing boilerplate. You say what you want and the AI writes it. Then you review, fix, and direct.

It's like having a junior who writes fast and writes a lot — but needs your guidance.

Vibe Coding vs. Vibe Engineering {#vibe-coding-vs-vibe-engineering}

Not all developer work with AI is the same. Let's draw at least two working distinctions.

Vibe coding — I don't deal with the code at all. I sit down at Cursor or Macaly, describe what I want, and let it run. This is perfect for prototypes and demos (where you'll throw the code away anyway), simple sites and landing pages, or one-off tools. I also use "vibe coding" as a broader label for this whole space.
Vibe engineering — an engineering approach beyond vibe coding. Here it's no longer about "let it run," but about deliberate collaboration. You design the architecture, break the problem into sub-problems, and the AI implements according to your specs. But you craft those specs together. The developer and architect thinking stays with you. AI is a tool, not a replacement for your brain.

We could argue about definitions, but I'd rather not. They're just words. I mention them so that those of you who feel lost can at least tell apart the different flavours of "vibing" code.

A side note: I've always tried to translate terms into Czech, but here I give up. This field moves so fast that all of this might just be a waypoint on the road to even greater AI autonomy.

What does matter, I'll mark again with a quote from Marek Prokop:

"Watch out for this, and learn to program. It's needed even in the era of AI."

– <cite>Marek Prokop</cite>

This is the key difference between vibe coding and vibe engineering. You can manage vibe coding without deep knowledge — for a prototype or a simple landing page, that's enough. But the moment things get more complex, you need to be an engineer. To understand what the AI is doing. To be able to fix it when it gets things wrong.

Where Do I Start as a Beginner? {#where-to-start}

Jindra Fáborský sorted this nicely into levels based on project complexity:

Level 0 — one-off tools and little hacks
Level 1 — landing pages
Level 2 — whole websites
Level 3 — app prototypes
Level 4 — internal tools
Level 5 — production applications

The higher the level, the more you need an engineering approach. Levels 0–2 are fine with vibe coding. From level 4 up, you have to be a vibe engineer.

Great news for developers. For non-coders? Don't jump straight into rewriting the app that pays your bills. Please, don't do it.

Me and Vibing: Four Examples {#four-things-i-built}

Theory is nice, but let's get to what I actually did over the last two months.

Example one: a prototype of the FrontKon site {#example-frontkon}

On the team behind the FrontKon conference, we're discussing a new website. I have a fairly clear opinion and vision for it. To make it easier to show the team what I mean, I go and build a prototype.

One day of work, including nearly final content. I don't deal with the code — it'll be thrown away, it's a prototype. I used to build prototypes like this over weeks. By hand. And then they'd often get discarded, which for prototypes is a good thing.

First explosion of Michálek's head. But also the first realisation that vibe coding isn't enough. That I have to engage the developer part of my brain. That I need to read what Cursor says and poke at it a little.

Example two: a website for my son {#example-son}

My seventeen-year-old son wants to start his first business with a friend — cutting reels out of videos.

We sit down together at Cursor. I expect it to be more complicated. Arguments about the look and so on, you know how it is… a teenager. A two-sentence prompt. He doesn't like the result, fair enough.

I ask Cursor what style might appeal to Gen Z. It gives us four options. My son picks one, Cursor redoes it, and he's thrilled.

<figure> <img src="../dist/images/original/vibe-coding-clipcut.jpg" alt="The Clipcut website"> <figcaption markdown="1"> The Clipcut site, done in 15 minutes. Style picked from Cursor's Gen Z recommendations. </figcaption> </figure>

It's done in 15 minutes. I'm laughing hysterically the whole time. My son asks if I'm okay. I say yes — but I used to spend days or weeks on this. And clients had no chance to change it so easily.

The tinkerers who hand-built small websites are dead. Macaly, or something like it, can be handled by anyone who can describe what they want.

Example three: editing copy in PageSpeed.ONE {#example-pagespeed}

I love writing. I go to edit some copy in our help docs over at PageSpeed.ONE. Cursor understands the context exactly and can imitate a specific writing style. I just tell it roughly what I want to write and roughly where. It edits the Markdown, adds links, runs a check.

As my colleague Michal Matuška puts it: "We all have to be full-stack." Including content authors. Including the company CEO.

<figure> <img src="../dist/images/original/vibe-coding-vd-writing.jpg" alt="Editing copy and writing with AI"> <figcaption markdown="1"> Vibe writing for Vzhůru dolů — Cursor understands context, can imitate a writing style, add back-links, and iterate beautifully, much like during software development. </figcaption> </figure>

Example four: migrating Vzhůru dolů from PHP to Astro {#example-migration}

For two years I've wanted to ditch the old dev stack on Vzhůru dolů. It runs on outdated PHP and the Perch CMS, which nobody maintains anymore. There's an old database in there, and the whole thing is so fragile that I was even scared to look at it.

I want a modern dev stack, I want it all dumped into Markdown, kept in a single repository and put on GitHub.

In the "old world," though, this would have meant sacrificing several weekends, or investing at least 50 — more likely 100 — thousand CZK into someone to handle it. I want none of that.

This is already a relatively complex project. The first attempt with Cursor didn't work out. I took the old PHP repo and asked it for a rewrite into the new one. It drowned in the context of two different technologies.

It turns out I have to learn the new dev stack, I have to give Cursor good instructions, and I have to watch what it's actually doing. To be the architect, not just a spectator.

I could have been a spectator and had it faster. But it wouldn't be sustainable long-term — and that's not what I want.

In the end, it's done. Two to three days of work in total — still amazing, honestly. It's built on Astro, available on GitHub, and has been live since the end of January.

<figure> <img src="../dist/images/original/vibe-coding-vd.jpg" alt="Migrating VzhuruDolu.cz to Astro"> <figcaption markdown="1"> Migrating Vzhůru dolů to Astro. Done in 2–3 days of work. </figcaption> </figure>

Developers Out of Work? {#developers-out-of-work}

Developers should fear for their jobs because of AI, they said. Nonsense. Developers have a big future, precisely because of AI — that's what I say.

Yes, some do need to worry. Coders, hackers in the bad sense, sloppy copy-pasters… they may all lose their current jobs.

But then there are the real developers. Developers with engineering thinking, knowledge of the technology, experience. Architects. Vibe engineers.

They have an enormous advantage — an algorithmic way of thinking. The ability to break a problem into sub-problems. To design an architectural solution. To push back on the AI technically, to improve its work.

To not get bullshitted by Cursor.

Just sit next to someone who lacks this for a moment. Watch how they write a prompt. And suffer — quietly, preferably.

Two types of developers {#two-types-of-developers}

If I simplify a lot, developers split by motivation:

Some love building products — websites, apps, a service for people.
Others love writing code and fussing over it. They're in love with a specific technology.

The current AI wave strongly favours the first group and can put pressure on the second.

It will get harder and harder to be fulfilled solely by writing beautiful code, and we'll focus more on the outcome that the technology delivers.

With LLMs you can build a great product, be highly technical, and even have quality code — all without writing a single line of code yourself. And I think this will be hard for a lot of people in that second group to accept.

You have to be a developer, or gradually become one {#you-have-to-be-a-developer}

When I was building the prototype of the new FrontKon site, Cursor wanted to do server-side rendering with a custom generator running headless Chrome on top of an SPA. Technically it worked. In practice it was nonsense — far better solutions exist.

If someone without experience had received this proposal, they probably would have accepted it. And they'd have a problem.

If you want to "vibe" products, sooner or later you have to become someone who understands the craft of development.

"Software is eating the world" {#software-eating-world}

Yes, a large share of tiny applications will be built by CEOs, marketers, and clients themselves — the kind of apps engineers wouldn't want to build anyway.

But software is greedy; it's far from done eating the world. A huge wave of software is coming that previously couldn't exist because it was too expensive. This won't threaten developers.

Yes, a breakthrough we don't see could always arrive. But right now it isn't happening. Developers aren't losing their jobs — at least not en masse and all at once.

A Few Concrete Cursor Tips {#cursor-tips}

Let's get to how to squeeze the most out of vibe coding.

Modes in Cursor {#cursor-modes}

Cursor has four main modes:

Mode	Code changes	Autonomy	When to use
Agent	Yes (multi-file)	Maximum	New feature from scratch, refactoring
Plan	Design first	Medium	Complex integration, you want control
Debug	Yes (targeted)	High	Bug fixes, logs
Ask	No (text only)	None	Consultation, understanding code

</div>

Agent is the most powerful but also the most expensive on credits.

For everyday work, Plan or Ask is often enough. Personally, I always start a new feature with Plan. We iterate over the brief, and only then do I let the Agent loose.

Context shortcuts {#context-shortcuts}

Cursor has handy shortcuts for working with context that sharpen what you're talking to the model about:

@Codebase — searches the whole project, best for complex changes
@Files / @Folders — targeted context, saves tokens
@Docs — pull in documentation by URL
@Web — search the internet

The absolute killer is the ability to open a browser inside Cursor and point at the specific elements you want to change.

Vibe rules {#vibe-rules}

Three rules for working effectively — the ones that, out of all rules, help the most:

Decomposition. Don't ask for everything at once. Move in small features and iterations.
Cursor rules. Set up .cursor/rules in the project root. A persistent "vibe" setting — e.g. "Write in TypeScript, speak English, use this code style."
Sniper vs. shotgun. For small edits, use Ctrl+K (inline edit) instead of rewriting an entire file through the agent.

Models {#models}

I don't feel much need to experiment with models, because the default Composer suits me beautifully, but I do switch occasionally, roughly like this:

Default (Composer): Fast, for everyday work. Enough for me in 80% of cases.
Claude Sonnet: Smarter, switch it on when the default gets "stuck in a loop." A killer for text.
Gemini: For working with huge context (the whole repository at once). I switch to it only occasionally.

Flow Not Found… or Is It There After All? {#flow}

This surprised me the most. I was afraid I'd lose the joy of creating while vibing, but the deep work is still there — it just looks different now.

It's not about polishing code. It's not about tuning semicolons and brackets. It's about direction, architecture, context. About building the final product.

I hand off a task and wait. Then I review, fix, and steer further. Less typing, more thinking.

And you know what? Surprisingly, the deep work and the flow are not missing. I still reach the state where I forget about the world and I'm immersed in the problem. The problem is just different — it's not "how do I write this function," but "how do I design this whole thing so it makes sense."

But this won't suit people who don't experience the final product that comes out of them so much, and instead enjoy fussing over the code.

This Is Big, but We Still Need People {#people-still-matter}

AI is not a replacement for developers. It's a multiplier.

We still need people. People control the machines and will keep controlling them. I hope.

We need people for meetings, for kitchen conversations, for the whole offline context that's still enormous. For accountability and security. For decisions that require understanding the broader context of the company and the team.

Vibe coding democratises technology. Developers and technically skilled people have an advantage. But they have to use it.

My 2025 in review: from freelancer to business owner

Tue, 06 Jan 2026 00:00:00 GMT

My 2025: entrepreneurial, strategic, successful — but also anxious and searching for form

2025 was a pivot year for me, and pivots are always significant. If it had been only positive, there would be nothing to write about, nothing to learn from, and the whole year would have been terribly boring.

A little anxiety about the world out there {#anxiety}

Let me start with the "anxious" part of the title. Some of you surely feel this tension too, especially the older ones. On a personal level your life is beautiful — arguably more beautiful every year — yet you're increasingly seized by gloom, or even anxiety, about what's happening in the world, in geopolitics, in society at large.

It started with the invasion of Ukraine, it continues with a second Trump term, and the ground is shifting hard here in Central Europe too. The light at the end of the tunnel keeps getting fainter. My father has an old saying for moments like these — roughly, "the world is going to hell." I used to laugh at it. Now it fits. I won't dwell on this much further, but I try to be honest here, and this framing can't be missing.

Let's instead focus on what I actually lived through last year, personally and above all professionally.

From freelancer to business owner {#business-owner}

First and foremost, I've probably already transformed from a freelancer into a business owner.

Don't get me wrong — it's just one of my roles. I'm still a content author, a performance and web enthusiast, a boss and co-owner of a company, a product person, a community guy, and above all a dad.

In 2025 my self-perception around making money shifted. I spent well over twenty years freelancing, and the inertia of that mindset is enormous.

<figure> <img src="https://res.cloudinary.com/vzhurudolu-cz/image/upload/v1767688556/vzhurudolu-blog/evoluce_keryv9.jpg" alt="Evolution from freelancer to founder"> <figcaption markdown="1">Evolution.</figcaption> </figure>

Being a solo freelancer and being an entrepreneur with your own company and people in it are completely different leagues. The mental and skill-based transformation from the first to the second took me roughly five years.

Throughout that time I kept asking myself one question: What will you do if your business fails, or if it simply stops being fun?

My answer was always that I'd just go back to freelancing. That held until the second half of 2025, when I started answering instead that in such a case I'd go and build a new business. Not bad — I wouldn't have expected that of myself.

PageSpeed.ONE: consulting is flying, but we want to push harder on the product {#pagespeed}

The business, of course, is PageSpeed.ONE — a great team of people who help companies speed up their websites and, in turn, improve conversions or traffic.

Last year was excellent. Thanks in part to a new colleague, Tomáš, we moved into consulting on backend and infrastructure (Cloudflare gave us a bit of a run for our money) and specifically on WordPress. We also focused heavily on other platforms, mainly Shoptet and Shopify.

I personally leaned hard into sales, and the numbers show it. What surprised me was how much I ended up enjoying it.

We worked with an estimated 30–40 new clients, including names like Česká spořitelna (one of the largest Czech banks), and we also did more work for retailers like Heureka and Datart. Brilliant.

At the same time we were building our SaaS speed-monitoring service. We made nice progress on it, but we didn't have as much time for it as we'd have liked. We're not the first to discover, painfully, that time and attention are finite, and that the shift from agency mode to product mode is always very hard. This will be the main goal for 2026.

FrontKon and Frontendisti.cz: from community to company thinking {#frontendisti}

Another big mental shift happened with Frontendisti.cz, the Czech frontend community. We spent a lot of time figuring out how to secure the future of both the community and the FrontKon conference, which until now rested on the large volunteer investment of me, Tomáš, Břetík, and many others. I'll be honest: in the first quarter I had one foot out the door, at least from organising FrontKon. But what was needed here was a change of mindset.

I think we got a new drive — at least I did — especially for the coming editions of FrontKon, which in 2025 essentially became bigger than the entire Frontendisti community. It's an event that's already outgrowing its community. We have ideas in our heads that should make that increasingly clear in the years ahead. At least I hope so!

Under Frontendisti, Robin and I also moved our podcast over, under a new name, FrontKec. Thematically and strategically it belongs to the community, while I'm gradually winding down the Vzhůru dolů project — as you've surely already noticed.

That's a lot of transformation, a lot of growth, a lot of change and demanding management problems. It would be strange if no little crisis showed up, right? Oh, it showed up, you bet it did.

The little crisis {#crisis}

In hindsight I can see the crisis lasted almost half the year. A crisis of overload: too many big topics at once (not just work, but personal too), too little deep work, and the resulting bouts of insomnia — alarms that, when they start buzzing, mean you need to change something quickly.

I've been through it several times in my career, usually during my various freelancing transitions. It happened, for instance, when I started selling training, while I was writing one of my books, or when COVID arrived and gutted a big part of my livelihood.

I know there's always a way out — taking a meta view of your time, self-analysis with a book in hand, changing how you organise things, decisively ending some activities — but this time I reacted fairly slowly, so I suffered for needlessly long. I'm not sure why, but I'd say the overload this time was so big it blocked the alarms. Oh, and I'm also getting nicely old.

(Out of) shape {#shape}

When I look at what I wanted to change, move forward, or achieve in 2025, I can be very satisfied. Except for one thing: my physical fitness.

Stress does its thing, age does too, the metabolism isn't what it used to be, and my classic maintenance activities (a bit of running, walking to and from work) clearly stopped being enough.

I'll have to solve this too this year, so for the first time in my life I've joined the heap of clichés who want to lose weight and get in shape come January.

By the way, if you're interested in cultural tips for reading, listening, or watching, take a look at my personal or work recommendations from 2025.

"2025 was great!" {#great}

One of the year's projects was getting my older son into secondary school. If you don't have kids finishing primary school — or you're not in Prague — you can't imagine what it involves. There are many candidates for the academic high schools and very few spots.

In the end it turned out great. He got into his second-choice school, he's very happy there, and he went through a transformation of his own — he settled in really well and is generally independent when it comes to preparing for school.

On New Year's morning, Honza woke up and called out, "2025 was great!" My wife and I exchanged a glance. That's really wonderful, we imagined — how he can appreciate it all. How he can appreciate that, with his effort and ours, he got into a good school, and that he's doing quite well there.

"2025 was great," he calls again, and adds: "…because I finally started drinking and smoking weed!"

So to you too, dear readers, I wish for 2026 that you always chase your own dreams, and not other people's.

The art of saying no

Mon, 10 Mar 2025 00:00:00 GMT

The art of saying no

Feeling buried? I used to be, all the time. I still fight it. But one thing I have learned for sure:

The talent of many talented people gets wrecked by never mastering the art of saying no.

You are good? You get more work.

Still keeping up? You get even more.

And on it goes — until you collapse under the weight of your own commitments.

Or until you start refusing, in earnest.

Why capable people drown {#why-capable-people-drown}

Some people cannot turn down their boss. Some cannot turn down colleagues. Some cannot refuse friends, a partner, their kids. And some braid the whip themselves. They tell themselves things like "Nothing is impossible" or "Never give up" — and in the end the only thing they give up is quality, traded for quantity. They burn out, or simply stop enjoying the work they once loved. They forgot they cannot do everything. They forgot how liberating no can be.

You need to say no to yourself too. To your own ideas, your own projects, your own pet thoughts. That is the hard part, because ideas are like children. We love them. But killing ideas has a polite name: prioritisation.

No is not arrogance {#no-is-not-arrogance}

Refusing is not easy, I know. It can sound harsh; you can come across as arrogant. That is why so many people fear that a no will make others like them less. But being liked only because you never say no means other people are living at your expense. Whose life is it — theirs or yours?

To some, no may sound too blunt. It does not have to be. You just have to learn the constructive no:

"I won't be doing this, but I can point you to someone — or send you materials that should help."

In time you will learn the plain no as well; it only takes a little empathy: "Sorry, but I already have a lot on my plate right now."

Because saying no often means saying yes to yourself.

From maker to manager: my pivotal 2024

Mon, 06 Jan 2025 00:00:00 GMT

From maker to manager: my pivotal 2024

I remember my early days on the web. Around the turn of the millennium I happily coded websites — until some "manager" at the agency tapped me on the shoulder. "I just need one tiny thing," he'd say, and wreck my whole day. Evil, evil managers. The golden age of coding!

Twenty years later, I'm taking on the very role that used to annoy me — and I'm finally letting go of the shame of being a manager.

From coder and content maker to manager {#maker}

In 2024 I made the definitive decision that the next chapter of my career would be managerial and entrepreneurial.

It hurt. Somewhere deep down, the question still lingers: "Aren't you betraying yourself and the whole craft of web building?"

But there are moments in life when clinging to the craft means stagnation. And if there's one thing I truly can't stand at work, it's boredom.

Last year we founded a company around PageSpeed.ONE, and one of my side activities became the main thing I do for a living.

For years I'd sensed the need for both strategic and day-to-day leadership across all my projects — PageSpeed.ONE, the Frontendisti community, the podcast. I was doing it, but somewhat reluctantly.

Who else, if not you? {#who}

Makers and craftspeople know the feeling. "I won't deal with that — I'm doing my own work well, it'll somehow work out."

But then the very right question is supposed to arrive: "Who else, if not you?" And as Spider-Man says, "With great power comes great responsibility." If you can see a problem and you have the skills to fix it, you simply must. When you've got a hammer in your hand and you spot a nail that hasn't been driven in… well, you know the rest.

My circumstances and my own skills forced me into becoming a manager. Evil, evil life, plotting such a trick against me!

But in 2024 the turning point came. I found I actually enjoyed it.

Consistent wins started rolling in. I gradually delegated much of my original work at PageSpeed, did great teamwork with my partner Michal and the rest of the team. Fast iteration on problems, improving processes… and, given the size of the team, a solid drive toward the goal while keeping the vision and strategic direction intact.

In the Frontendisti community, thanks to a great team and our new colleague Kačka Macháčková, we pushed our FrontKon conference to a level we previously hadn't even dared to dream of.

A new environment {#environment}

While retuning my head, I also realised I had to surround myself with a new environment.

I started listening to business podcasts, reading books, and filtering my social feeds. The mind needs not only information, but also a good environment. These people and their brands shaped mine the most:

The excellent Scale Up podcast by Roman Stupka.
Cinkátko by Michala Gregorová.
Lenny's Newsletter by Lenny Rachitsky.

A new inner baby {#baby}

My entrepreneurial-managerial part of the brain is like my new little baby. I cradle it, feed it knowledge. I watch it grow — its first steps are behind it, it can already handle quite a lot. It's lovely to watch.

I wish you many such new inner babies in 2025 — no matter how old you are!

This text came about as the first output from my retrospective of 2024. I know for certain I won't write the rest, but you know what? Let me at least stash them here briefly.

What else did 2024 bring me? {#more}

I still write, don't you think otherwise. Last year I wrote dozens of texts, mostly for the PageSpeed.ONE help docs, a big piece on writing for Vzhůru dolů, an article about INP on Lupa.cz, and after a long break an English piece for the WebPerf Calendar. I also write a lot on LinkedIn, which I'm simultaneously trying to tame so it serves me less bullshit and more substance. I enjoy writing for social networks. Maybe one day it'll even be worth reading.
I gave 8 talks and was a guest in 3 interviews. I'd highlight especially my talk for SEO Restart on INP, the talk at our FrontKon 2024, and the conversation for the Socials podcast. I accepted almost every invitation, and there were many. This year I'd like to retreat into my shell a bit more — write more, build more. And manage and run the business, of course.
At PageSpeed.ONE we landed around 30 new consulting clients last year, including brands like SIKO and Heureka.cz. We officially started selling the paid monitoring PLUS version and shipped 5 new releases. We have ambitious plans, and the team is firing on all cylinders.
My family and I spent 14 days exploring Tanzania on our own, and came back with dozens of stories — some genuinely adventurous. I got a massive culture shock there, even though I'd spent the whole year "training" by driving to Brno.
I bought a gravel bike, which was the best investment in myself all year.
I read nearly all six volumes of Dune by Frank Herbert, and I'm thrilled. I also saw at least two deeply harrowing films (The Zone of Interest and The Citizen). My excessive optimism about life genuinely needs that kind of counterweight.

Not everything worked out, of course. The planned step-change for the podcast is being postponed to this year. Exercising at the level I do is no longer quite enough for a guy pushing fifty, so it seems that in this phase of life I'll have to step up my self-care a bit. And I still don't really know what to do with Vzhůru dolů now that I write here so much less.

All in all, though, I consider 2024 a very successful and pivotal year for me. I'm curious what this year will bring.

WebP images: the leaner alternative to JPEG, PNG, and GIF

Sun, 07 Jul 2024 00:00:00 GMT

WebP: smaller images without dropping anyone

WebP is a raster image format Google introduced back in 2010. More than a decade later it is the boring, dependable choice: supported by practically every browser worth targeting, with Internet Explorer being the only notable holdout — and almost nobody is shipping for IE anymore.

Here is why it earned its place:

meaningfully smaller files than both JPEG and PNG
alpha transparency, which used to be PNG's party trick
animation, the one thing GIF was good for

WebP does give up a couple of things JPEG offers. It does not do chroma subsampling the same way, and progressive rendering is not part of the picture either.

It is also sometimes described as slower to decode and harder on the CPU. images.guide keeps that worry honest:

Back in 2013, the compression speed of WebP was ~10× slower than JPEG but is now negligible (some images may be 2× slower). For static images that are processed as part of your build, this shouldn't be a large issue. Dynamically generated images will likely cause a perceivable CPU overhead and will be something you will need to evaluate.

In other words: only worth a second thought if you are generating images on the fly. For build-time assets, ship it and move on.

Browser support: the Chromium crowd, plus Firefox and Safari {#browser-support}

Since WebP comes from Google, every Chromium-based browser ships it out of the box — Chrome, Edge, Opera, Brave, and the rest. Firefox has supported it for years, and Safari joined the club too. For most global audiences that puts you comfortably above 90% coverage today.

Supported: Chrome and Chromium derivatives, Firefox, Safari 14 and up
Not supported, and never will be: every version of Internet Explorer

For the current numbers, check caniuse.com/webp.

So what about the small slice of users on browsers without support? No drama — you do not have to serve them a page with no images.

A JPEG fallback with `<picture>` {#fallback}

The clean answer is to generate two sets of images — WebP and JPEG — and let the browser pick the right one using the <picture> element:

<picture>
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="…">
</picture>

Chromium and friends download only the WebP; everyone else quietly gets the JPEG.

If you cannot use <picture>, there are alternatives — server-side content negotiation or .htaccess rules. But the <picture> approach is the most predictable and the most performance-friendly.

For images referenced from CSS, you can detect WebP support — and its individual features — with a library like Modernizr. The CSS then looks like this:

.box {
  background-image: url("image.jpg");
}

.webp .box {
  background-image: url("image.webp");
}

Google also publishes a tiny detection snippet on its WebP pages.

Is it worth maintaining two copies of every image? It depends — but on larger sites, in my experience, it pays off handsomely.

How much data does WebP actually save? {#savings}

On one client e-commerce project I wrote about, the team's results were concrete:

After switching to WebP they cut 30% off the homepage weight (1250 kB → 950 kB) and shaved a fifth off page load time (19.8 s → 16.8 s).

I see similar numbers across other tests and client work. Halving image payload is not unusual.

Google's own studies put the general savings at roughly:

26% smaller than lossless PNG
25–34% smaller than lossy JPEG

How to produce WebP {#how-to-produce}

There is no shortage of ways to generate WebP these days:

Design apps: Sketch, Pixelmator, and GIMP export directly. Photoshop and other Adobe tools do not, but there is a plugin.
CLI and libraries: cwebp for the libwebp codec.
Build pipelines: plugins like imagemin-webp for Gulp, Grunt, or whatever bundler you run.
Server-side: ImageMagick and similar libraries.
Online services: Kraken.io and others — excellent compression, usually paid, sometimes not cheap.

For more options, see web.dev or images.guide.

Save on developers, spend on consultants

Tue, 16 Apr 2024 00:00:00 GMT

Save on developers, spend on consultants

Dear site owners: the more you save on your platform and your developers, the more you will pay consultants to fix it all afterward.

That can be perfectly fine — it may still pay off. But you should put this variable into your math.

"We'll save X on the platform and Y on developers, but we're budgeting Z for consulting on UX, SEO, accessibility, or speed. And we'd rather hire those consultants at the start of the project, so they can keep an eye on it." Something like that.

The off-the-shelf platform trap {#off-the-shelf-trap}

Take a hosted e-commerce platform like Shopify. I think these can be genuinely great platforms — speed included, as long as you don't mess with them too much. But they're also very often badly used.

"We'll build it on the cheap platform. Look how much we save every month…" Okay, but then don't count on customizing it heavily to your needs. We often see original templates forced into a custom design that, as a result, hurts UX and… breaks performance.

WordPress, the classic {#wordpress-classic}

Or WordPress. A classic. I probably don't even need to write this anymore… But I do, dear readers, I do.

Yes, everything can be done well on WordPress too. But it's often done, well, you know how… You hire a developer who is cheap and doesn't get it. Even relatively large sites are often just an unmaintained pile of plugins glued together. A cheap developer is cheap. So they do it badly, don't communicate, don't follow up, and happen to be off in the Canary Islands…

At PageSpeed.ONE we see this constantly when consulting on speed. Audits and analysis can be significantly more demanding on cheap solutions than on bespoke ones.

Just put it in the calculation {#put-it-in-the-calculation}

It may still work out well — economically, for the project, or otherwise. Of course it can. But definitely put it into your calculation. Don't let it catch you off guard. I told you so.

Web Vitals: Google's core metrics for real-world speed

Tue, 02 Jun 2020 00:00:00 GMT

Web Vitals: Google's core metrics for real-world speed

Web Vitals is Google's label for metrics that describe real user experience on the web.

Measuring performance (and UX) used to be a specialist discipline. For everyone else the landscape was noisy. Google narrowed the focus to a small set of metrics — with tooling and a promise they would not change every month.

Today we mainly track LCP, INP (replacing FID), and CLS. Google folds them into page experience signals. If you need the business case first, PageSpeed.ONE explains why speed matters.

This guide is a quick tour of the metrics and how to read them.

The metrics {#metriky}

Web Vitals includes more than three numbers, but Google highlights Core Web Vitals (CWV) as the baseline every site owner should know.

Core Web Vitals {#core}

The headline trio — Core Web Vitals:

Largest Contentful Paint (LCP) — how fast main content appears; a loading metric between First Contentful Paint and Speed Index.
Interaction to Next Paint (INP) — responsiveness after user input; INP replaced FID as a Core Web Vital in March 2024.
Cumulative Layout Shift (CLS) — visual stability while the page renders.

Google buckets each metric into three states:

Good
Needs improvement
Poor

Thresholds from Google's documentation:

Metric	Good	Needs improvement	Poor
LCP	≤ 2.5 s	2.5 – 4 s	> 4 s
INP	≤ 200 ms	200 – 500 ms	> 500 ms
CLS	≤ 0.1	0.1 – 0.25	> 0.25

</div>

For a single score per URL, Google recommends the 75th percentile across mobile and desktop field data. The worst metric wins — that is how PageSpeed Insights reports pass/fail today.

<figure> <img src="/prirucka/images/web-vitals.jpg" alt="Diagram of Core Web Vitals metrics LCP, INP, and CLS"> <figcaption markdown="1"> Core Web Vitals at a glance. Source: web.dev. </figcaption> </figure>

Optimization guides on web.dev:

Optimize LCP — also LCP on PageSpeed.ONE
Optimize INP — also INP on PageSpeed.ONE
Optimize CLS — also CLS on PageSpeed.ONE

What about the other metrics? {#dalsi-metriky}

Specialists still care about TTFB, FCP, TBT, and the rest. LCP alone will not reveal a slow backend or a late hero image without measuring upstream.

How to measure Web Vitals {#mereni}

Google updated its tooling quickly when Vitals landed.

<figure> <img src="/prirucka/images/web-vitals-psi.jpg" width="1920" height="540" alt="Core Web Vitals section in PageSpeed Insights"> <figcaption markdown="1"> Web Vitals in PageSpeed Insights. Lab data may still list FCP even though it is not part of CWV. </figcaption> </figure>

Practical entry points:

PageSpeed Insights — field data in the CrUX section; try it on your URL now.
Search Console — Core Web Vitals report by URL group.
Chrome UX Report — raw field data; CrUX Dashboard in Looker Studio.
WebPageTest — highlights Vitals in results (example run).
Web Vitals extension — live values in Chrome.
web-vitals JS library — send metrics to analytics.

INP and FID require real-user (RUM) data. Synthetic tools such as Lighthouse or WebPageTest approximate interactivity with Total Blocking Time (TBT) instead.

Google says Core Web Vitals should change at most once a year — but they also admit the set is not final. This article will keep evolving.

CSS Units (em, rem, %, px, vh, vw): Which One to Use Where?

Mon, 03 Dec 2018 00:00:00 GMT

CSS Units (em, rem, %, px, vh, vw): Which One to Use Where?

Let's round up all the CSS units you can reasonably use in modern web design — and show, with examples, what each one is good for.

My go-to units are the ones relative to font size: rem and em.

But I don't treat them as Supermen among CSS units either. They simply aren't right for everything. For different jobs we'll still need Spider-Man, Batman, and the rest of their colleagues.

A quick overview of useful units {#overview}

These are the six worth committing to memory.

Unit	How it computes the size?
`rem`	relative to the font size on the `html` element
`em`	relative to the font size on the element
`px`	the reference pixel, the CSS pixel
`%`	percentage relative to the parent element
`vw`	a percentage of the browser window's width
`vh`	a percentage of the browser window's height

</div>

There are of course others — pt, ex, or vmax, to name a few. But their usefulness is either small or close to none, so to keep things simple I'll leave them out of this text entirely.

Which units to use in which situations? {#scenarios}

Throughout this text I care a lot about not breaking the natural inheritance of font size in browsers. Besides us, the page authors, the user may want to change it — and sometimes browsers change it too. So for different uses I recommend different units:

Base font size of the document: %
Dimensions derived from the document's font size: rem
Dimensions derived from the parent's font size: em
Media Queries: em
Line height: a unitless number
Borders, decoration: px
Typography based on window size: vw

It's quite possible you'll get by with px almost everywhere. I'll get to that at the end of the text.

Base font size of the document: % {#document-font-size}

The default font size in the vast majority of browsers is 16px. But there are less prominent browsers that set the font size differently — simply so that reading is more comfortable on a particular device.

For example, the browser on the Kindle 3 had a default font size of 26px, and Opera Mini 7 used 17px. We could bet that most of the most widespread browsers don't change the default font size, but my experience says it's better not to.

Nicolas Hoizey wrote a nice article on default font sizes in browsers, "People don't change the default 16px font size in their browser (You wish!)": nicolas-hoizey.com

If the default font size doesn't suit you, change it with relative units — ideally percentages:

html {
  font-size: 125%;
}

This sets the text a quarter larger than the default. In nearly all browsers that means 20px. On the Kindle 3 it would be 33px. It's important to realize that this is fine. If a browser sets a different font size, it does so for sensible reasons.

Why not px? Because people enlarge text in their browsers {#why-not-px}

If we used px here, we'd be forbidding our dear users from changing the default font size in their browsers.

To be clear, we're not talking about "zooming," which is available via a keyboard shortcut or easily set in the browser interface, but about increasing the font size for all websites. That feature still exists in browsers and operating systems. And yes, people use it. We probably will too one day. It's used by people with weaker eyesight, or simply with lower-quality displays.

Evan Minto, a developer at Archive.org, measured this and found that 3% of users had changed the font size in their browser. As he aptly noted, that's more than the share of visitors using Internet Explorer, Edge, or Opera Mini at the time.

Because we want to build solutions with the widest possible reach, we shouldn't ignore this. He writes about it in "Pixels vs. Ems: Users DO Change Font Size": medium.com

Dimensions derived from the document's font size: rem {#rem}

I set the font size of individual parts of the document, the outer and inner spacing, and other properties across the document and components, in rem.

1rem (1 root em) holds the default font size set by the author for the document — possibly further adjusted by the user or the browser, as we've already seen.

If we don't change it on the document, 1rem = 16px.

p { margin-bottom: 1rem; }
h1 { font-size: 2rem; }

With this code I set the paragraphs' bottom margin to the height of the text. First-level headings will be twice as large as the standard font size.

Using rem is also handy from a developer's point of view:

1rem holds the base font size, so you don't have to remember whether it's 12, 14, 16, or however many pixels.
A layout width set in rem will keep an optimal line length even when the user enlarges the text.
Thanks to rem you can also scale the whole document up within specific ranges between design breakpoints.

What if I get assets in px? {#assets-in-px}

You may be used to working in px when turning a design into code, because designers deliver assets in those units. But as I've written, setting anything derived from the main font size in px complicates life for many users.

How to get out of the design-versus-accessibility conflict? Automatic CSS processing can help.

You may know the PostCSS library, which enables automated processing of styles. The PostCSS plugin "postcss-pxtorem" handles converting px to rem for selected properties. It simply turns font-size:16px into font-size:1rem: github.com

So I consider rem the main unit for building interfaces. But em is very useful too.

Dimensions derived from the parent's font size: em {#em}

The em unit holds the font size of the element, not the document.

html {
  font-size: 100%; /* = 16px */
}

p {
  padding: 1em; /* = 16px */
}

.button {
  font-size: 75%;
  padding: 1em; /* = 12px */
}

You can see that 1em means different things in different places in the document. Sometimes that's a good thing: for example, when you're coding a component whose size should be determined precisely by the font size on the parent element.

Of course, developers find "ems" a bit harder to work with than "rems." Not everyone wants to become a walking calculator for converting between em and pixels.

Just note that em is not the typographic em quad {#em-is-not-em-quad}

The "em quad" is a typographic unit measured from the width of the capital "M." em is sometimes inaccurately called the em quad. But then it would be a different size for different typefaces.

And it isn't. The W3C defined em differently. Its size at the root of the document is the same in all browsers and with any typeface — 16px. Unless, that is, it's changed by the treacherous trio of user, browser, or page author.

Media Queries: em {#media-queries}

Why not use px? I'd recommend avoiding pixels because of the inability of Media Queries to respond to font-size enlargement.

@media screen and (min-width: 30em) { }

In "PX, EM, or REM? Examining Media Query Units in 2021," Iris Winter writes that because of an imperfect implementation in Safari it's still better not to use pixels, and to prefer em or possibly rem. Both units refer, in Media Queries, to the document's font size, so they're freely interchangeable: betterprogramming.pub

In coding practice, though, you can use automatic conversion from px, because CSS pixels are easier to work with here. A handy PostCSS plugin called "postcss-em-media-query" will help: github.com

Line height: a unitless number {#line-height}

A unitless value is specific to line height, but it makes perfect sense:

h1 {
  line-height: 1.5;
}

In the CodePen example (see below) the line height is simply one and a half times the font size of the first-level heading. And then it doesn't matter at all how anyone sets their font size.

Why is this better than setting it "hard" in rem, em, or px? If the font size changes in some context — by the author or the user — you then don't have to change the line-height setting too.

Layout: percentages, but other units too {#layout}

Percentages work well for layout. For example:

.layout-col {
  width: 50%;
}

A reminder: they're always calculated from the width of the nearest parent element.

But there are more usable units for layout:

Percentages or vw stretch with the window's width, vh with its height.
rem and em go by the font size.
In flexbox you can also use absolute units (flex:1).
In CSS grid there are the so-called fractional fr units (grid-template-columns:3fr 1fr).
Sometimes fixed dimensions in px come in handy too.

Borders, decoration: px {#decoration}

I recommend using px only where you need a precise expression in pixels. For example, for borders between navigation items:

.nav-item {
  border-left: 1px solid white;
}

Just to be safe, a reminder that this is no longer a hardware pixel, but the reference — or so-called "CSS pixel." I write about it on Vzhůru dolů: vzhurudolu.cz/prirucka/css-pixel

Typography based on window size: vw {#viewport-typography}

You may also need to grow and shrink the font size according to the window's width or height. In that case, remember the vw (viewport width) or vh (viewport height) units.

For example, this heading from the example will have a font size of 2rem plus, always, two percent of the window's width:

.heading {
  font-size: calc(2rem + 2vw);
}

Finally, I'm adding a link to a CodePen that uses what I consider an optimal unit setup on a simple example.

CodePen: codepen.io/machal

What if I still want to use mainly px? {#px}

In web design there's always a whole range of possible solutions. Some are optimal for users but demanding to implement; others are a compromise. Units are no different. I don't think a lot of kittens will die if you favor "CSS pixels." Using px is significantly more convenient to implement for a large share of design types.

Still, make sure the text in the design is large enough for most users to read. As a baseline, at least those 16px are generally recommended. You should also ask yourself whether you're bothered by anything on the following list:

Users who changed their font size in the system or browser (about 3% on Archive.org) won't see their setting reflected on your site. They're left with the option of zooming the whole page.
A change in font size won't be correctly reflected in Media Queries.
The design doesn't account for fluid typography that grows with the viewport.
The designer likewise didn't account for a flexible change in a component's size based on the parent's font size, nor for a global change in font size at certain design breakpoints.

BEM: A naming convention for CSS classes

Mon, 05 Jun 2017 00:00:00 GMT

BEM: A naming convention for CSS classes

BEM is a way to name CSS classes so that their different types never get confused with one another.

There are two ways to look at BEM:

A full-blown methodology for organizing CSS. See the complete documentation at bem.info. It was invented and is used at Russian search company Yandex.
A naming convention for classes. See getbem.com. This is the trimmed-down version that other authors extracted from the original methodology, and it is the one I will cover here.

I do not use BEM as a full methodology — I usually reach for my own ways of organizing CSS instead. That is a fairly common scenario, I think. You might also want to combine BEM with another system: SMACSS, ITCSS, or others.

For me the biggest value of BEM lies in the naming convention. At first glance this might look like a very short topic, but there is still plenty to say. You will see in a moment.

BEM as Block, Element, Modifier {#block-element-modifier}

First the quick overview, with links to more detailed explanations below.

Class type	Naming pattern
Block	`.block`
Element	`.block__element`
Modifier	`.block--modifier`
Element modifier	`.block__element--modifier`

</div>

Why use BEM and where does it fit? {#why-bem}

I consider BEM an extension of object-oriented CSS (OOCSS) for medium-sized and large projects. To adopt BEM you therefore need to be able to write styles componentwise, keep the specificity of your CSS selectors low, and so on.

Unambiguous meaning of classes in CSS and HTML {#unambiguous-meaning}

If your project has, say, more than twenty components and you write CSS in an object-oriented way, there is a high chance the meaning of your classes will start to blur:

<nav class="nav nav-secondary nav-visible">

Reading this code, you might wonder whether nav-secondary and nav-visible modify the original component or are standalone objects. Is nav-secondary independent? What about nav-visible? Should you look in nav.css or in nav-secondary.css?

With BEM everything is clear:

<nav class="nav nav--secondary nav--visible">

nav is a block — in other words, a standalone component. nav--secondary and nav--visible are its modifiers. We will most likely find them all in nav.css, or in a file with an extension matching whichever preprocessor you use.

A component marked up with BEM therefore carries more information than one marked up with plain OOCSS — both in CSS and in HTML. The code is easier to understand, you need less documentation and fewer comments, and it is easier to move around within a project or across projects.

It is simple and widely adopted {#simple-and-widespread}

The BEM principle is not complicated, and it is easy to explain to colleagues who do not work with CSS much. They certainly do look at HTML, though, and thanks to BEM they get more information about a component's structure there — even without documentation.

On top of that, BEM is nothing new and is well established among front-end developers. So if you stick to what is described here, new colleagues will have no trouble finding their way around the project.

Is it "ugly"? {#is-it-ugly}

That is a common objection, especially from programmers. Aesthetics are subjective, so it is hard to base the decision to use a methodology on them.

Yes, it can look ugly. But either BEM solves a problem for you or it does not. If it does, use it. I definitely recommend it. The exception is tiny projects, or generating CSS with JavaScript in apps that fully depend on JS.

And now let's dive deeper into BEM.

BEM in detail {#bem-in-detail}

Block {#block}

A block is essentially a UI component — an independent, reusable element of the user interface. Blocks can be nested inside one another freely.

It is denoted by a class whose words are separated by a hyphen: .block-name.

Element {#element}

A part inside a block that we need to style. An element cannot be used on its own in the interface; its existence only makes sense within a block.

You recognize it by a class prefixed with the block name and completed with the element name, separated by two underscores: .block-name__element-name.

Modifier {#modifier}

A variant of a component. It describes visual properties (.block--small), state (.block--disabled), or behavior (.block--animated-to-left). It should not carry a name tied to appearance (.block--green).

In code it is a class prefixed with the block name and completed with the modifier name, separated by two hyphens: .block-name--modifier-name.

You may have come across modifiers written with a single underscore (.block_modifier). That is the "classic" BEM syntax. It appears to have been Harry Roberts who reshaped it into the double-hyphen form — or at least popularized that variant.

The "classic" notation lets you split modifiers into two types — "boolean" and "key-value". Honestly, I cannot remember when I ever needed that. So for its simplicity and clarity I, too, prefer the "Roberts" variant.

Element modifier {#element-modifier}

A variant of an element is also possible. You may need it especially in more complex components. As an example, take the active item in a tabbed navigation: .tabs-nav__tab-item--active.

The same naming rules apply as for modifiers. In code it is a class prefixed with the block name and completed with the element name, separated by two hyphens: .block-name__element-name--modifier-name.

Names are separated by a hyphen {#hyphen-separated-names}

As you can see from the examples above, the words in block, element, and modifier names are separated by a single hyphen. For example .block-name--modifier-name.

BEM and CSS organization systems {#bem-and-css-systems}

As I wrote, BEM builds on OOCSS. It is also nice that it complements broader CSS organization systems such as SMACSS or ITCSS.

Let's sort out those methodologies:

OOCSS is a methodology for writing the component part of your styles. It is a necessary foundation for a sensible way of writing the component part of the code on every project.
BEM is a methodology for naming the component part of your styles. It is only unnecessary on tiny projects.
ITCSS or SMACSS are methodologies for organizing the whole of your CSS, including the non-component parts: the typographic baseline, helpers, and so on. How suitable these high-level organization methodologies are differs from project to project, and sometimes you have to come up with your own.

BEM does not conflict with any of these methodologies. It usually just adds a way of naming classes on top of them.

A navigation example {#navigation-example}

Take this HTML:

<ul class="nav nav--secondary" role="navigation">
  <li class="nav__item">
    <a href="/">Home</a>
  </li>
  <li class="nav__item nav__item--active">
    <a href="/">Products</a>
  </li>  
  <!-- … -->
</ul>

Then:

.nav is a block (the component name)
.nav--secondary is a modifier (a variant of the component)
.nav__item is an element (a DOM element inside the component)
.nav__item--active is an element modifier (a variant of the element)

I include the role attribute here for good measure, so we don't forget about accessibility.

Selector specificity in BEM {#specificity}

Because BEM stems from OOCSS, the goal is to keep selector specificity (weight) as low as possible. We then write the CSS like this:

.nav { 
  /* Rules common to all navigations */ 
}

.nav--secondary { 
  /* Changing rules for this modification */ 
}

.nav__item {
  /* Rules for this element */ 
}

.nav__item--active {
  /* Changing rules for this element modification */ 
}

This has two benefits: selectors keep a low specificity, and we don't repeat CSS code.

Keeping selector weight low {#low-weight}

Selectors like .nav.nav--secondary then become pointless, thanks to prefixing the modifier.

Not repeating code needlessly {#no-repetition}

A common problem with non-object-oriented CSS is repeating declarations from .nav in modifiers like .nav--secondary.

True, we could then allow ourselves simpler HTML such as <nav class="nav--secondary">, but the CSS would be complex and horribly hard to maintain. Simpler HTML is no advantage either, because we can no longer see from it what is a component and what is its modifier.

You can find more about specificity in the OOCSS article.

An element within a modifier {#element-in-modifier}

The only exception where a two-class selector is acceptable is an element inside a modified block:

.nav--secondary .nav__item {
  /* Changing rules for the navigation item
     in the secondary navigation */
}

An element is always dependent on its parent block, and it would make no sense to make it standalone. At the same time, it would be quite annoying to create modifiers for all the elements inside a modified block (.nav__item--secondary).

For practical reasons it is therefore the only thing in the BEM naming system allowed to have double the selector specificity.

What not to do {#what-not-to-do}

Let me point out a few more pitfalls.

BEM and the trap of nesting in preprocessors {#preprocessor-nesting}

Some people make writing BEM syntax easier in CSS preprocessors by nesting:

/* Better not do this: */
.nav {
  &__item { }
  &--secondary { }
}

Just please don't overdo it. Nesting in preprocessors is a good servant but a bad master. It is not problematic in itself, but in the code of less experienced CSS authors it leads to monolithic blocks and bracket hell.

Another problem can arise when searching in editors. You might find yourself searching for .nav__item — and in code with the "ampersand" syntax that simply won't work.

Multiple block nesting {#multiple-nesting}

In the DOM structure you can nest freely. The hierarchy of CSS selectors, however, should always stay single-level. So .block__element__heading is wrong. It should be .block__element-heading.

This is so that the CSS selector does not depend on the DOM structure and you don't have to change it with every HTML tweak. Don't mirror the DOM structure in your CSS.

Crossing components {#crossing-components}

I often see constructs like this in CSS:

.button {
  /* Code for the Button component */
}

.card .button {
  /* Changes to the Button component when it appears inside Card */
}

Sometimes there is no way around it, but in principle crossing components is wrong. It then becomes hard to say whether the code belongs to the card component or to button. It is better to create a modifier like button--small. Leave crossbreeding to the gardeners — don't try it with components.

We are almost at the end. The last part of the text is devoted to using BEM in inhospitable conditions.

Using BEM in a non-BEM environment {#bem-in-non-bem}

What if your project uses something like Bootstrap, which is written in an object-oriented way but without BEM naming?

If Bootstrap or another library dominates the codebase, I would drop BEM for the sake of consistency. Bootstrap also has its own coding standards, so I recommend staying within their guard rails. Code Guide is not very strict, but it is a perfectly adequate guideline for most situations.

If, however, you were using Bootstrap or another library only as an add-on to your own robust code base, I would consider either prefixing the library selectors or your own parts of the code. In the early days of one of my projects, for example, we used the vc- prefix to distinguish our components from the Bootstrap ones.

You have reached the end. There would be more to say about BEM, but I will save that for another time.

The CSS display property: outer and inner display explained

Sun, 14 Jun 2026 10:53:50 GMT

The CSS display property, from the basics to the modern syntax

The display property tells the browser how to render an element in CSS.

There is nothing to it. And yet this article will try to show you that it can be a surprisingly complicated thing.

Those of you who know its basic values such as block or inline may be surprised that since 2020 we have had a new version of the specification that adds a whole range of further options — the "CSS Display Module Level 3". w3.org/TR/css-display-3

Let's start with a simple overview of the most useful values of the display property. You probably already know most of them.

Value	How it renders
`inline`	An inline-level element that creates no line breaks before or after itself (the default).
`block`	A block-level element. It breaks the line before and after itself.
`inline-block`	Internally a block-level element, externally inline, creating no line breaks.
`flex`, `inline-flex`	Creates a flexbox layout. The inline variant does not break lines before and after.
`grid`, `inline-grid`	Creates a grid layout. The inline variant does not break lines.
`table`, `inline-table`	A table layout. The inline variant again forms a table within a line.
`none`	Does not render the element, nor its descendants.

</div>

The table is far from covering all the options and their specific behaviors, pitfalls, and tricks. So read on.

Did you know, for example, that…?

With the flow-root value you no longer need a "clearfix" to contain floats, that is, to reset a floated layout?
Browsers now support multi-keyword values such as inline flex?
Besides none, there is also the contents value for hiding an element. And do you know what it can do?

Outer and inner display {#typy}

The first thing we need to realize is the plain fact that, according to the specification, there are now two types of display:

Inner display
The value of the display property determines how the browser lays out the element's descendants, in other words its inner elements. This is where values such as flex, grid, or table belong.
Outer display
The value defines how the element itself is displayed relative to its surroundings. The view from the outside. This is determined by values such as inline, block, or none.

Got it? Excellent. This will come in handy once we start talking about multi-keyword values.

Outer display {#vnejsi}

Outer display essentially determines the role of the styled box in the page's flow.

<figure> <img src="../dist/images/original/vdlayout/css-display-inline-block.jpg" width="1600" height="450" alt="CSS display - inline and block"> <figcaption markdown="1"> The display property. The outer display values are our old acquaintances. </figcaption> </figure>

This type of display includes the following values:

inline
Creates a box that is "inline-level". It breaks nothing before or after itself, it simply renders within the line.
block
Generates a box that is "block-level". Put simply, this means it renders across the full width of its parent and breaks the line before and after itself.
inline-block
Generates a box that behaves like an inline box on the outside and always generates a new block context on the inside. By the way, the specification treats this value going forward merely as another notation for the keyword pair inline flow-root. More on that later.
run-in
Generates an "inline-level" box with special behavior — it tries to insert itself into the following block element. If a block element follows the "run-in" element, the "run-in" becomes its first inline box. If an inline field follows, the "run-in" element becomes a block element.

You can try all the options out in CodePen.

CodePen: codepen.io/machal/pen/wvzYXeg

The variant with the run-in display type is missing from my demo, because it is not supported anywhere other than Internet Explorer (!).

CodePen does not work in this granddaddy of browsers, so you would get nothing out of the demo. See support on CanIUse.
caniuse.com/run-in

The granddaddy is sadly dead by now, though, so you do not need to care about run-in either.

Inner display {#vnitrni}

Inner display values switch on a new formatting context inside the affected element (the term "formatting context" is used for this in CSS).

The formatting context affects the way inner elements are rendered, and possibly the behavior of properties applied to the element.

flow
The flow value switches on flow formatting ("flow layout"). This is the normal way of displaying, which is automatically turned on by the values block, inline, and inline-block. It is the default layout mode in CSS.
flow-root
Creates a block context container (like display:block) and lays out its content using flow ("flow layout"). The flow-root value, however, always generates a new block formatting context for its content, so you do not need to clear floats with a "clearfix", for example. What is interesting about this value is that it is supported by all modern browsers.
flex
Switches on the flexbox formatting context. It turns the styled element into a flexbox container and its direct descendants into flexbox items.
grid
Starts the grid formatting context. It turns the styled element into a grid container and its direct descendants into its items.
table
Turns the element into a table. In this case, however, there are two "containers". display:table generates a table container, which creates a block formatting context and contains an additionally generated table grid box, which creates the table's formatting context.
ruby
This is exotic and unnecessary in a Central European context. "Ruby annotations" are short runs of characters placed above or below the base text, used in East Asian typography as a pronunciation guide. Feel free to forget about it.

I have prepared two explanatory CodePens where you can test what you see in the image.

In the first one, we simply have three elements placed in a single parent, with no layout.

CodePen: codepen.io/machal/pen/KKgGeQQ

The second CodePen is more interesting. All three inner elements are "flowing", floated:

.container p {
  float: left;
}

CodePen: codepen.io/machal/pen/WNGayad

You can see the result in the image.

<figure> <img src="../dist/images/original/vdlayout/css-display-outer.jpg" width="1600" height="450" alt="CSS display - inner display with floated children"> <figcaption markdown="1"> The inner display value options with inner floated elements. </figcaption> </figure>

Normal flow display (display:flow) cannot contain floats, we would need the aforementioned "clearfix".
display:flow-root contains floats, it always creates a new block formatting context.
Floats have no effect on display:flex and display:grid.
Floats do affect the inner elements in display:table, because the parent here is in a normal block formatting context flow.

Let's go through a few more specific values.

Generating boxes with markers: list-item {#list-item}

The display:list-item notation causes the element to generate a ::marker pseudo-element.

If no inner display type value is given, the default is flow — like display:flow. If no outer display type value is given, the default type is block — display:block.

Thanks to this, we can style our container as if it were a <ul> or <ol> element:

.container {
  list-style-type: square;
}

CodePen: codepen.io/machal/pen/gOwqJmq

The first example in the following image shows the list-item display type.

<figure> <img src="../dist/images/original/vdlayout/css-display-etc.jpg" width="1600" height="450" alt="CSS display - list-item, none, contents"> <figcaption markdown="1"> Other types of (non-)display in CSS. </figcaption> </figure>

We will discuss the second and third values from the image in the next section.

Hiding elements: the none and contents values {#none-contents}

To all the possible methods of controlling how boxes are rendered to the screen, we must also add methods of not rendering.

The following two values of the display property serve this purpose.

none – neither the element nor its descendants are rendered to the screen at all.
contents – the element itself is not rendered to the screen, but its descendants are.

The contents display type works as if the element were replaced in the DOM tree by its content (including pseudo-elements such as ::before and ::after).

CodePen: codepen.io/machal/pen/zYKmaMb

Display types for internal layout: the table- and ruby- values {#table-ruby}

Display models that force an internal layout, such as display:table and display:ruby, have a complex structure with several different roles that their descendants can fill.

As mentioned above, the display:table notation does create a table container, but that container creates a block formatting context.

So we do not achieve a tabular display this way. To do that we would need additional elements representing the rows and cells of the table with the correct display property values (table-row, table-cell…).

It is similar with display:ruby, only the inner elements are different.

Multi-keyword values {#viceslovna}

This is a new thing, added to the specification in the second half of 2020 by the last browser to do so, which was Chrome, implemented in 2023.

Do you remember when I wrote about the different types of display — inner and outer? If not, quickly skim the start of this text or its headings. Then you will understand why multi-keyword values for the display property make sense to me.

The single-keyword values above can in fact be taken as shorthands for multi-keyword notations of inner, outer, or specific display.

Shorthand	Full notation	What is generated
`none`	-	nothing
`contents`	-	element omitted, descendants generated
`block`	`block flow`	block box
`flow-root`	`block flow-root`	block box that always creates a new block formatting context
`inline`	`inline flow`	inline box
`inline-block`	`inline flow-root`	inline box that always creates a new block context
`run-in`	`run-in flow`	run-in box (an inline box with specific rules)
`list-item`	`block flow list-item`	block box with an additional list item marker
`inline list-item`	`inline flow list-item`	inline box with an additional list item marker
`flex`	`block flex`	block flex container
`inline-flex`	`inline flex`	inline flex container
`grid`	`block grid`	block grid container
`inline-grid`	`inline grid`	inline grid container
`table`	`block table`	block table wrapper box
`inline-table`	`inline table`	inline table wrapper box

</div>

It is probably clear from the table, but just to be safe here are three examples:

display:block denotes a block element (block) placed in the normal document flow (flow).
display:inline-flex defines a flexbox container (flex) placed within a line (inline).
display:list-item renders a list element (list-item) placed in the normal flow (flow) and at the same time block-level (block).

And that is everything about the display property, thank you for your attention.

CSS selectors: a complete guide to selectors and combinators

Sun, 14 Jun 2026 10:53:50 GMT

CSS selectors

This guide fills a gap in my coverage of CSS fundamentals.

While researching it, I noticed that surprisingly few resources cover selectors this comprehensively in one place. So here is one.

I'm aiming primarily at beginners, but I think refreshing this topic won't hurt more advanced readers either. Let's start with a table summarizing the most important things you'll find in this article.

The most important selectors {#key-selectors}

Selectors pick a particular group of elements in the DOM and let you style them.

Selector	Syntax
Class	`.class`
Element	`tag`
Identifier	`#id`
Attribute	`[attr]`
Everything	`*`

</div>

The most important combinators {#key-combinators}

Combinators join simple selectors into more complex groups and let styling apply only under certain conditions.

Combinator	Syntax
Descendant	`A B`
Child	<code>A > B</code>
Next sibling	`A + B`
Subsequent sibling	`A ~ B`

</div>

I'm deliberately leaving out pseudo-classes, which undoubtedly belong among CSS selectors. But I want to keep this within the scope of an article, not a book.

Element selectors {#elements}

These selectors pick elements from the DOM by HTML tag name.

Type selector – `tag` {#type}

This contains the name of an HTML element and represents an instance of that element type in the document tree.

Examples:

h1 — represents all <h1> elements in the document.
li span — selects all <span> elements nested inside an <li> element.

Universal selector – `*` {#universal}

A special variant of the type selector that represents an element of any type.

Examples:

* — represents all elements in the document.
body * .box — represents an element with the .box class that is nested at the second level inside a <body> element.

Attribute selectors {#attributes}

Selectors that pick elements by attributes — their presence, a match against their entire value, or a match against part of the value.

Class selector – `.className` {#class}

One of the best-known and probably the single most useful selector, which picks elements by class.

It represents elements belonging to the class identified by the class attribute in HTML.

Example:

<div class="box">
  <p class="a"><span class="a">…</span></p>
  <p class="b"><span class="a">…</span></p>
  <p class="c"><span class="a">…</span></p>
</div>

The .a selector picks both <p class="a"> and all the <span class="a"> elements.

More examples:

.heading — all elements that have the class attribute set to heading.
h1.heading — all <h1> elements that have the heading class.
h1.heading.heading-large — all <h1> elements that have both the heading class and heading-large.

You may have noticed that the syntax .heading is equivalent to the tilde attribute selector (i.e. [class~=heading]).

Class selectors are the foundation of almost all web styling today — think of methodologies like OOCSS, BEM, but also newer utility CSS.

ID selector – `#id` {#id}

The ID selector represents an instance of an element whose identifier matches the value of the id attribute.

Example:

<div class="box">
  <p class="a"><span class="a" id="first">…</span></p>
  <p class="b"><span class="a">…</span></p>
  <p class="c"><span class="a">…</span></p>
</div>

The .a#first selector picks only <span class="a" id="first">.

In HTML documents it's possible for multiple elements to match a single ID selector. That's fine from the CSS selector's point of view — but of course not from the standpoint of HTML semantics or accessibility.

Attribute presence and value selectors – `[attr]` {#attr-value}

Here we test whether an attribute exists on an HTML element, or detect its value.

These are the selectors that look for the presence of an attribute or a specific value on an HTML element.

Types of attribute selectors:

Selector	Explanation
`h1[title]`	An `<h1>` element that has a `title` attribute with any value.
`h1[title=Hello]`	Exact-match attribute selector. An `<h1>` element whose `title` attribute is exactly `Hello`.
`h1[title~=Hello]`	Tilde attribute selector matching one value. An `<h1>` element whose `title` attribute contains the string `Hello` in at least one value. Values are separated by spaces for the selector's purposes, so `<h1 title="Hello world">` satisfies it.
<code>h1[title\|=Hello]</code>	Prefix-match selector. This one is peculiar. The matched value must be either exactly `Hello`, or start with `Hello` immediately followed by a `-`. It really only makes sense for matching language codes. For example, <code>[hreflang\|="en"]</code> matches both `en` and `en-US`.

</div>

Substring attribute selectors – `[attr^=]` {#attr-substring}

Here we pick elements by matching part of an attribute's value. These are selectors for finding substrings within an attribute value.

Types of substring attribute selectors:

Selector	Explanation
`h1[title^=Hello]`	The caret attribute selector represents an `<h1>` element with a `title` attribute whose value begins with `Hello`.
`h1[title$=Hello]`	The dollar attribute selector represents an `<h1>` element with a `title` attribute whose value ends with `Hello`.
`h1[title*=Hello]`	The asterisk attribute selector represents an `<h1>` element with a `title` attribute whose value contains `Hello`.

</div>

In all substring selectors, if the value were an empty string, the selector represents nothing. The element simply isn't selected.

Case-insensitivity flag `[ i]` {#attr-case}

Thanks to this newer flag, we can turn off case sensitivity.

By default, selectors for HTML do distinguish between uppercase and lowercase.

The i identifier stands for "insensitive" — that is, not distinguishing uppercase and lowercase in the selector.

Examples:

h1[title=Hello] — picks <h1> elements with a title attribute valued Hello, but not hello.
h1[title=Hello i] — picks <h1> elements with a title attribute valued Hello and also hello.

By the way, even this relatively new flag is supported by all modern browsers. See CanIUse.com.

Take a look at a demo from reader Lukáš Chylík.

CodePen: cdpn.io/e/eYVWOEQ

The s identifier before the closing bracket (]) stands for "sensitive" — case sensitivity. Currently only Firefox supports it, but s] isn't really needed in HTML, because it just replicates the browsers' default behavior.

Combinators {#combinators}

Combinators are special characters that let you combine simple selectors into more complex ones and extend a selector's reach only when certain conditions are met — such as an element being nested inside a particular parent in the DOM.

Descendant combinator – `A B` {#descendant}

The whitespace combinator separates two selectors (A B) and selects a descendant (B) that is nested inside a particular element A.

A selector in the form A B represents an element B that is any descendant of some ancestor element A.

Example:

<div class="box">
  <p class="a"><span class="a">…</span></p>
  <p class="b"><span class="a">…</span></p>
  <p class="c"><span class="a">…</span></p>
</div>

The .box .a selector picks the <p class="a"> element and also all the <span class="a"> elements.

More examples:

.heading span — all <span> elements that are descendants of elements with the heading class.
h1 em — all <em> elements that are descendants of an <h1> element.
h1 * em — all <em> elements that are descendants at the second level or deeper inside an <h1> element.

Child combinator `A > B` {#child}

The greater-than combinator (A > B) selects element B that is a direct descendant of element A.

So while A B selects B at any level of nesting inside A, A > B selects only the B elements that are direct descendants of A — its "children."

Take an example:

<div class="box">
  <p class="a"><span class="a">…</span></p>
  <p class="b"><span class="a">…</span></p>
  <p class="c"><span class="a">…</span></p>
</div>

The .box > .a selector picks only the <p class="a"> element.

More examples:

.heading > span — all <span> elements that are direct descendants of elements with the heading class.
h1 > em — all <em> elements that are direct descendants of an <h1> element.
.box ol > li p — all <p> elements that are descendants of <li>, where <li> must be a direct descendant of <ol> and a descendant at any level of an element with the .box class.

Whitespace around the child combinator is optional. h1 > em and h1>em are identical. The spaced form is preferred for readability.

Next-sibling combinator `A + B` {#next-sibling}

The plus combinator (A + B) selects element B that is an adjacent sibling of A.

The elements represented by both selectors share the same parent in the document tree, and the element represented by the first (A) immediately precedes the element represented by the second (B).

Here's an example:

<div class="box">
  <p class="a"><span class="a">…</span></p>
  <p class="b"><span class="a">…</span></p>
  <p class="c"><span class="a">…</span></p>
</div>

The .a + p selector picks only the <p class="b"> element.

More examples:

h1 + p — the <p> element that immediately follows each <h1>.
h1.heading + h2 — the <h2> element that immediately follows each <h1> with the heading class.

Spaces are again optional. h1 + p is the same as h1+p, but prefer the former.

Subsequent-sibling combinator – `A ~ B` {#subsequent-sibling}

The tilde combinator (A ~ B) selects element B that is a sibling of A but does not immediately follow it.

Both elements share the same parent. The difference from A + B is that with the tilde combinator the elements need not be adjacent.

Back to the example:

<div class="box">
  <p class="a"><span class="a">…</span></p>
  <p class="b"><span class="a">…</span></p>
  <p class="c"><span class="a">…</span></p>
</div>

The .a ~ p selector picks the <p class="b"> and <p class="c"> elements.

More examples:

h1 ~ p — all <p> elements that share the same parent as <h1>.
h1.heading ~ h2 — all <h2> elements that share the same parent as an <h1> with the heading class.

Spaces in the selector are again optional.

Browser support {#support}

All the CSS selectors I mention here are fully supported in every browser, including MSIE. The only exception is the case-sensitivity flag ([title=Hello s]), which you won't get working in that old browser.

There is, however, one group of selectors — mentioned in the Selectors Level 4 specification — that has no support.

Column selectors – `A || B` {#column}

A || B — the column combinator. It selects element A belonging to column B. See, for example, col.selected || td in tables.

It would be useful to have such a selector, but no browser supports it yet, just like the similarly focused :nth-col() and :nth-last-col() pseudo-classes.

In the continuation of this text, I'll focus on pseudo-classes in CSS, which are really just slightly peculiar selectors.

Inbox Zero: How to Escape Email Chaos for Good

Sun, 14 Jun 2026 10:53:50 GMT

Inbox Zero: how to escape email chaos

Email doesn't have to be a source of dread. Your inbox doesn't have to overflow with marketing newsletters, half-finished threads, and irrelevant noise. It doesn't have to be full at all. And you don't have to keep forgetting things and letting people slip through the cracks.

You don't have to feel a small pang of guilt every single time you remember your inbox exists.

I know two ways out. The first is to pretend email doesn't exist. The second is Inbox Zero, a method for processing email systematically.

<figure> <img src="../dist/images/original/inbox-zero-main.jpg" width="1600" height="900" alt="An empty, calm inbox — what Inbox Zero feels like"> <figcaption markdown="1"> This is what we all want. Sometimes it's enough to switch off the badge on the app icon. Sometimes you need more — a method. </figcaption> </figure>

Why email still deserves your respect {#e-mail-vyhody}

Among some professionals, email has earned such a bad reputation that they flee to real-time chat tools (Slack, Teams, instant messaging in general) or pick up the phone for every little thing. Sooner or later, that leads to forgotten decisions, people left out of the loop, and general communication chaos.

Email has real strengths. The recipient shouldn't expect an instant reply, so you get time to think. Conversations leave a searchable, permanent record. Email isn't as built for interruption as IM, which makes it far friendlier to deep work. And everyone has an email address — even people who barely use it — which makes it the one truly universal platform.

Email simply complements every other channel beautifully. I'd go so far as to call it the essential cornerstone of online communication. It has a bad name, but maybe only because people use it badly.

For me, the manual for using email well is called Inbox Zero. What surprised me is how few people actually know and use the method.

<figure> <img src="../dist/images/original/inbox-zero-stats.jpg" width="1600" height="900" alt="A tongue-in-cheek statistic about Inbox Zero"> <figcaption markdown="1"> Rigorous scientific research has shown that the overwhelming majority of people appreciate an article about Inbox Zero. </figcaption> </figure>

That's part of why this article exists. Let's get into it.

What is Inbox Zero? {#inbox-zero}

Inbox Zero is a method whose goal is to process and organize incoming email efficiently. The aim is to keep your inbox regularly empty — or close to it.

Inbox Zero was invented and popularized in the 2000s by Merlin Mann, a productivity expert.

In practice, by the book, it looks roughly like this:

At least once a day, you give your inbox dedicated time.
You go through your messages, and each action follows the four Ds (Do, Delegate, Defer, Delete).
You then either archive or delete each message.
Profit! The inbox is clean.

The main point of Inbox Zero is to lower the stress that comes with email, raise your productivity, and keep a sense of control over your communication.

The marketing pitch is that the goal is to keep both your mind and your inbox clear.

That's accurate. Genuinely.

In the rest of this article I'll expand on that and add my own experience.

I've personally used Inbox Zero for about ten years. I'd guess I switched over when Google Inbox arrived — the now-defunct, innovative Gmail alternative that, among other things, catered to Inbox Zero enthusiasts.

These days I'm back on plain Gmail, but more or less any email client will do the job.

What does Inbox Zero give me? Less stress from an overflowing inbox, less fear of falling behind, less forgetting, faster retrieval of information. Easier, more systematic organization of my work.

How I work and which tools I use {#komunikace}

Before we get into concrete, practical tips, I feel the need to put my version of Inbox Zero into a bit of context.

How do I work? I'm a freelancer; my specialty is web performance consulting, but the bulk of my work today is more or less management. With three colleagues I run consulting under the PageSpeed.ONE brand, where we have around fifty clients. As part of another team I help develop a speed tester. I also help run a developer community and occasionally write articles or ebooks.

I get around a hundred emails a day, plus messages on social media, in IM tools, and so on. It's quite a lot, and without a method I'd be sunk.

I use a ton of communication channels, like most people. Here's how I relate to each of them in the context of my take on Inbox Zero.

Email (Gmail) {#komunikace-email}

Email is my main communication hub. Every notification I could route there — mostly from Basecamp, our project management tool — lands in email. But I don't visit often, just a few times a day. Notifications are off. I use Gmail.

IM (Slack) {#komunikace-im}

We use Slack for real-time team communication. IM is essential for the occasional blocker or problem that genuinely can't wait.

We also have lower-priority channels just for chatting. I keep Slack notifications on only in the afternoon, when I'm not doing deep work, though I do peek in sometimes in the morning. The same goes for WhatsApp, Messenger, iMessage, and the rest of my personal communication.

If it's not on fire, I don't reply immediately. With the exception of my wife and kids, of course.

Phone {#komunikace-tel}

I use the phone very little, but it occasionally comes in handy for explaining more complicated — or rather moderately complicated — topics.

Some clients are very phone-oriented, and I try to respect that. Luckily I rarely have real emergencies and disasters at work, so I can usually pick up without fear of a major interruption and without stress.

After a long stretch of communicating only by email, you can get a feeling I call "emotional disconnection," so sometimes it's good to meet up or at least call. The phone is, after meeting in person, the most human form of communication for me. But I'd rather meet people than call them.

Video calls {#komunikace-call}

Online meetings (or, more aptly, "calls") have all but replaced in-person meetings in my field, and honestly that suits me. I'm in regular contact with most clients. Every now and then I prefer to meet in person. But it's getting harder and harder to push for in-person work meetings, don't you think?

So much for the wider context of how I communicate. Now, on to email and Inbox Zero. Before we begin, we need to meet a few prerequisites.

Prerequisite one: dedicated, limited time — say, after lunch {#predpoklad-1}

It's going to cost you time. There's no way around it. Make your peace with it. Emails in your inbox are waiting, and they don't have legs. They won't walk away and they won't resolve themselves unless you give them time. You have to set that time aside.

Some methods recommend dealing with email as fast as possible, or maybe once an hour, but personally that would kill me. I give email attention only a few times a day. It works roughly like this:

In the morning I don't look at the inbox at all. I'm deep in focused work, sorry.
After lunch I give email half an hour to forty-five minutes. That's my main Inbox Zero block.
In the afternoon I'm doing more managerial work; I peek into email occasionally and reply now and then so nothing gets stuck on me, but most of it I push to the next day anyway.

That half hour to forty-five minutes after lunch is in my daily schedule and I plan around it. There's no conjuring it out of thin air if my day is packed with other tasks.

I normally log email processing in Toggl as work:

Communication within PageSpeed.ONE projects I track as team management.
More complex, advisory emails to clients I track as paid work for them.
For all other email I have a "Communication" label, and I try to keep it under about 30 minutes a day. That covers unpaid client communication, various newsletters, anything around my own brand, the occasional personal email, and so on.

Notice that I deal with email after lunch. Yes, that's usually when I'm most tired in the whole day — and email also doesn't demand much of my brain capacity.

What about the other prerequisites? You'll want to tweak your email settings {#predpoklad-2}

Let's move on to the next step: reconfiguring everything so it's as un-annoying as possible and all in one place.

No notifications {#predpoklad-2-notifikace}

I'm a genuinely big opponent of real-time notifications and the drudgery of dealing with them as they arrive. The only things that actually buzz at me are text-message alerts and the occasional important IM from family. Email gets no exception.

<figure> <img src="../dist/images/original/inbox-zero-badge.jpg" width="1600" height="900" alt="A notification badge on a mobile email client"> <figcaption markdown="1"> A clear mind with this on your phone? Where on earth do you switch the thing off?! (Unsplash) </figcaption> </figure>

I've even turned off the little badges showing unread counts on every app icon. And yet, thanks to Inbox Zero, I still handle most emails within 24 hours.

Everything in one place {#predpoklad-2-jedno}

All my mailboxes, including the historical ones, forward into a single, most-current inbox that I actually use.

In Gmail I've disabled tabs like Promotions and Social. If it's meant to reach me, let it go straight to the inbox — including newsletters, of which I subscribe to somewhere between five and ten, and that still feels like a lot.

I don't subscribe to promotional mail at all, nor to notifications from social networks. Whatever happens on social media can stay there. I do check in occasionally — actually, unhealthily often, ahem.

I also barely use labels and categories in Gmail. The only exception is automated messages from various tools, like Google Search Console, because those can't be routed to Slack or another sensible place where our work notifications land.

Reasonable email length {#predpoklad-2-delka}

I used to write long messages. I notice this is common among (former) developers. These days I have an aversion to it, so if you send me a long email, you'll probably wait a while for a reply — or I'll just call you.

I try to hold the line on my own side too. I like methods, or rather descriptions of the ideal email, like Five.sentenc.es. Try to cram everything into five sentences. It won't always work, but it's a great exercise in brevity. For less experienced writers, it's worth learning the Five Ws method.

So how should you go through your inbox each day? Different people do it differently, and I don't want to force anything on anyone, so I can only offer my own process. For inspiration.

Step 1: prioritize {#krok-1}

I scan the emails with my eyes and start with the easiest ones. The point is to build momentum early. Let's be honest — processing email usually isn't the most thrilling part of the day.

Generally I first go through the team's internal messages, which means clearing all the Basecamp email notifications. I log that as its own time block.
Second come the other emails that can be handled quickly, in under a minute each. I log this as a separate "Communication" item. While I'm at it, I often clear various social notifications too.
Third are the specific, more complex emails I can track as dedicated time, usually for a particular client. These are mostly quick advice, a reminder of priorities, or pulling some data and sending an illustration.
Fourth are the emails I already know I won't get to. They're usually low priority. I defer those to the next day. There's about a tenth of them each day.

Step 2: act {#krok-2}

Something needs to happen with every email, and we can't just delete them all, can we…

<figure> <img src="../dist/images/original/inbox-zero-schema.jpg" width="1600" height="900" alt="A diagram of how Inbox Zero works"> <figcaption markdown="1"> A simplified — and still complicated — diagram. And really it's such a simple thing, isn't it? </figcaption> </figure>

The original Inbox Zero method works with these "D" actions; I've tweaked them a bit with my own experience:

Delete {#krok-2-smazat}

If an email isn't relevant or doesn't require action, just delete it. It probably came just for your information, or not even that. For me this splits further into two different actions:

Delete — emails I won't need to archive. They contain no important information, or they're just a duplicate of a Basecamp message (or another tool) where it'll be searchable anyway. Even so, it's good to respond somehow, so the people on the other end know you've seen it. Emoji reactions in Basecamp are great for this. Email doesn't offer that yet.
Archive — messages or threads that contain important information. I archive most messages rather than delete them. As a result, I know what nonsense I wrote to whom eight or ten years ago. You want that.

Delegate {#krok-2-delegovat}

If an email requires action but you're not the right person to deal with it, delegate it to the right person or team.

For me that means adding or updating an appropriate task for my colleagues. I don't actually delegate much, though, because our responsibilities are fairly well divided and we all know what we're supposed to do.

Do {#krok-2-vyridit}

If an email needs a quick, simple action you can finish within a few minutes, I do it right away. Reply, perform the requested action, whatever it is. This is where you'll feel like you actually got something done. Is it more than a minute or two of work? Then I track the time for the client.

Defer {#krok-2-odsunout}

For emails that need more time or effort but that you can't get to right now, set them aside for later. Use your task list or the snooze feature in your email client. They'll disappear from view, at least for now.

Deter {#krok-2-odmitnout}

Emails that are spam or irrelevant — just mark them as spam or unsubscribe. This one is especially satisfying.

Step 3: profit! {#krok-3-profit}

You're done. Every day you'll be rewarded with the sight of an empty inbox:

<figure> <img src="../dist/images/original/inbox-zero-gmail.jpg" width="1600" height="900" alt="Inbox Zero in Gmail"> <figcaption markdown="1"> Peace and quiet right here. </figcaption> </figure>

It's a good feeling. It doesn't have to be perfect right away. Mine isn't perfect either, even after all these years. But it helps. Give Inbox Zero a try.

On Writing: How to Start and Never Stop

Sun, 14 Jun 2026 10:53:50 GMT

On writing: how to start and never stop

Start writing. Just start. Right now. Or once you've finished this article.

Writing will deepen your knowledge and help the people around you. Writing will build your reputation.

But the best thing about writing is something else entirely. You can work your way into an incredible state of flow. You'll enjoy the act of writing itself. And you'll keep wanting to come back to it.

It's possible that writing isn't for you — I can't rule that out. But it's also possible that you're just approaching the process the wrong way. That's why this article exists. To help you.

You already have things to write about. Everyone does. The subject is you, your life, your friends, your family, your work. Something happens every day, and if you want it to, every day teaches you something. You can even get a story out of an ordinary trip across town.

It'll surprise you how useful or interesting your knowledge, experience, comments, or anecdotes can be to others.

Only a handful of people write about any given field, any given topic. Finding a niche where nobody else is standing is easy.

Writing is thinking. It lets you formulate your ideas, communicate better, and get better at what you do.

Write concisely, cut the filler. When you don't know how to start, start in the middle.

The difference between someone average and an expert is often simply that the expert writes.

I've been writing for almost 30 years. Did I have a talent for it? I don't think so. My first texts were terrible. I just wrote about what I enjoyed. And kept thinking about how to do it better next time.

Let me try to sum up what I think about writing and how you could get started too.

Why write at all? {#why-write}

There are plenty of reasons to write. But the best one is to find your way into a state where you simply enjoy it.

Sharpening your knowledge {#knowledge}

Writing sharpens your knowledge, because writing is thinking. Having to formulate your ideas forces you to actually think about the topic. Having to back up your claims with examples, data, or illustrations forces you to do research. That's how you get better at the subject.

Yes, you do have to actually do the thing you're writing about. If you want to write about web development, you can't know nothing about it. But thanks to writing, within a few hours you'll become noticeably better at it than most other people.

Sharing knowledge and building a reputation {#reputation}

When you want to help one person, you explain it to them. When you want to help more people, you write it down. It's tempting once you realize you can help hundreds or thousands of people at once.

It's addictive when people start writing to you with positive feedback.

We mostly write for free, but you can still get something out of it. A reputation, for instance. That always comes in handy, whether you eventually turn it into money or not. But that's a topic for another time.

Flow like nothing else {#flow}

This is actually the most important part, because you don't have to write for the people out there — you can write mainly for yourself.

For me, flow is the main reason I write almost every day. With most pieces I drop into a state where the world disappears and the writing just pulls me in. It's a drug.

Tomorrow I'll want it again.

Can you write too? {#can-you-write}

By now you know I enjoy writing. I talk about writing with people, and I see that almost everyone would like to write something now and then — but they've got a pile of obstacles in the way. Let's look at them. Maybe we can jump over them together.

"I have no talent" {#talent}

Maybe so. We're either born with talent or we're not. Some people have writing in their blood; others have something else.

But people usually underestimate how far talent can be replaced by practice.

Somewhere in our heads we all have a muscle that produces great writing. And we either train that muscle or we don't.

Maybe some of you know me through my writing. Maybe you think I have a talent for it. But no, I don't think it was ever there. My high-school language teacher could explain that to you. My writing was pretty bad until I started training the writing muscle. Now it's a decent bicep.

Does my younger son have talent? When he texts me, I suffer, and I usually can't understand him at all. But in fourth grade he wanted to try writing a sci-fi novella. He started, dropped into flow, and finished it.

His work, "AI Destroys the World," had an idea and a plot. But it was unreadable, because it was riddled with mistakes. One prompt in ChatGPT fixed that, cleaning up the errors and the text overall. Suddenly an eleven-year-old turned out to be a fairly talented young writer.

The novella ended with what I consider the greatest closing line of any book ever:

In the end, though, it all turned out fine. Relationships were mended, the machines were repaired, and the president's grave was also restored. It was a tough seven years.

Does he have talent? I still don't know. It doesn't actually matter. Talent is overrated. We also have tools now. And then there's training the muscle.

"I was bad at it in school" {#school}

Almost anyone can say this, myself included. School generally isn't great at teaching practical skills. None of the writing habits I've built came from a classroom — and that's true for most writers I know. So it's no wonder teachers don't really know how to teach writing.

Teachers are, at best, theorists of writing. They couldn't write, and they couldn't teach you to.

Writing in practice turns out to be something completely different from what we remember from school.

So you can forget the misery of writing in school, with one exception: the outline. Writing an outline before you write is genuinely useful. The teachers were right to push it on you. I'll come back to the outline later.

"It won't be good, people will criticize me" {#criticism}

Yes, your first attempts won't be good. But iterate, and think about how to do it better the second time.

Or try rewriting the whole thing a week later. It'll be better, you'll see.

That perfectionist inside us, forbidding us from publishing an "imperfect" piece… Or is it more like fear? Fear that someone will tell you your writing is bad? Fear of embarrassing yourself?

Let me tell you something. I've written a lot. Every week I write something for social media, and almost every week a longer piece. I've written four books. I've had a lot of reactions, and sometimes they genuinely thrill me.

But one thing has never happened — nobody has ever come up to me and said one of my pieces was truly awful.

The worst thing that's ever happened with my writing is that an article didn't get as many readers as I expected. It didn't spark interest. Or a post of mine got no likes. Really. Nothing worse is waiting for you, either.

I think people are generally good at separating the text from the author. They'll read your piece, maybe they won't like it, but that's no reason to connect it to you.

People only remember the good pieces. Can you actually recall some truly terrible thing you read recently? Probably not. You didn't finish it. And you forgot the author long ago.

"I don't know what to write about" {#topic}

You don't — but you can. That's a skill you can learn, like any other.

Take the skill of driving home. Did you always know how to get home by car from somewhere new? No, you had to learn it. Or you had to learn to use a tool, like Google Maps.

In the same way, you can learn how to figure out what to write about.

Let's try it in practice. What did you learn at work today? That's generally a good topic. People usually overestimate how much everyone else knows. Unless you're a complete beginner in your field, if you learned something at work, it's probably interesting to the rest of us too. Write about it.

But you can write an interesting article even when you're just starting out in a field — as long as you can explain something in a way nobody else has yet.

The vast majority of people never write anything, precisely because they assume the result will be pointless. Maybe it's pointless to you, because you already know it. You just learned it. But it'll surprise you how many people out there will be grateful for what you know.

I sometimes don't know what to write about either, but I have tools. I keep a notes database (I use Evernote) where I log topics I'd like to write about someday. I keep adding to those notes as I read new articles or pick up new information from client work.

When I'm stuck for a topic, I check my notes. And I always discover I actually have an enormous backlog of things I want to write.

But you don't have to write only about your work. Something happens to you every day, your opinions surface every day, something funny pops into your head every day. Something interesting happens every day, even when you're not traveling anywhere.

You just have to look at the world the right way.

Every time something interesting happens, a piece I could write about it is already popping into my head. That, too, is a skill you can learn.

"Writing is torture for me" {#torture}

I once wrote on X:

To remind myself how painful writing an article is for some people, I decided to fix my bike myself. "I'll have it done in half an hour." Most of Sunday gone. The bike is more broken than before. Now I'm looking for a repair shop.

Yes, I can imagine that for someone, fixing a bike is just fun work they do every day. Not for me. But I believe it isn't fun for me only because I've spent very little of my life fixing bikes.

I believe I could get the same pleasure from fixing a bike as I get from writing this article. I'd just have to train the muscle.

Writing is torture for a lot of people. It's possible they'll simply never get the hang of it. But it's also possible they just don't practice much and are going about it the wrong way.

"Isn't writing obsolete by now?" {#obsolete}

This is something I often debate with younger people. "Why write books when nobody reads them anymore?" "Why agonize over an article when you could film it and turn it into a reel?" they tell me.

Yes, to some extent that's true, and to some extent people read less online these days. It's partly a generational thing.

On the other hand — text is not a dead format. Really, it isn't.

The book market may have its best years behind it, but online, people still read a lot.

What's changed are the expectations. Generic rambling on a topic that's been written about a million times, in the format of a dissertation like twenty years ago, no longer flies.

Shorter pieces work today. Pieces enriched with photos, examples, interactive demos, quotes, tables… work.

The best pieces are the ones with little text and a lot of everything else.

But if people care about the topic and you give it good form, they'll read even a really long piece — and one without images, like this one. If you're still reading, you're proof.

Text has a huge advantage. You can consume it at your own pace. Some people scan the headings, some the images, some slow down on a particular point and focus on it. Video and audio don't offer that — there you're almost entirely at the mercy of the author's pace and style.

Text is still the most searchable and scannable format there is.

And besides… even if you want to film a reel, you'll probably need to organize your thoughts first. You'll do the research, draft a structure, maybe even a script. Then you film it. You've actually done a big chunk of the writing process.

Writing is thinking. And the result of writing doesn't have to be text.

"…but ChatGPT…" {#chatgpt}

With the arrival of AI (or rather, language models), a lot of people started to panic. Supposedly AI will replace writers.

AI won't replace writers, but it will make some parts of the creative process easier.

I use ChatGPT for research. I simply ask it what the piece should be about and ask about things I don't know. Of course, I then verify everything with a search engine.

I use ChatGPT to check my drafts. What's missing? What's redundant? What might be hard to understand for a specific audience?

I love ChatGPT, but I can't imagine it writing an article for me. AI doesn't have your context. It doesn't have your knowledge, your style, your imagination, your personality.

Yes, an enormous volume of model-generated text is being produced, and will keep being produced. In some fields that'll be enough — generic news, for instance. But in specialized fields, or in creative writing? There'll be a lot of generated text, it'll be extremely similar, and therefore uninteresting to readers.

So what can your added value be? Your knowledge and experience, your style, your personality. Just like now.

I write more about working with AI on both code and text in Vibe Coding: I've built websites for 25 years, but the last two months were completely different.

So much for motivation and breaking through blocks. Now let's try actually writing something.

How to write {#how}

Pick a topic, build a structure. Trim that structure so the first draft takes you no more than an hour. Try to find the core message and write that first. Concisely, please.

Time to write {#time}

Put writing in your calendar, turn it into a habit, and don't write for too long in one sitting.

Writing has to be repeated until it becomes a habit, otherwise you'll never write anything. I write every Monday through Wednesday, always in the first hour of the morning. Sometimes, when I'm enjoying it, Thursday and Friday too. I have quiet, a clear head, and a topic prepared in advance. In those three hours I often write a whole article.

I think writing for three hours or more in one stretch is nonsense. Fatigue catches up with you and it stops flowing. You burn out, or, losing perspective, you overcomplicate the article. Some people struggle to stay at the level the text actually needs. The longer they write, the deeper into the topic they go. You don't want that.

That's why for years I've split my work time into one-hour blocks followed by a break. Roughly like at school.

I think it's very important to let the topic gradually form and settle in your head.

I finish shorter articles in those three hours. On day one I do the research, prepare the structure, prepare the examples, and try the topic out in practice if I can. On day two, in the second hour, I write the whole thing. On day three, in the third hour, I just do proofreading, images, and publish the finished piece.

Some articles, like this one, need more of those one-hour blocks — ten, maybe. But when an article is good, when I'm enjoying it and drop into flow, I have no trouble finding another hour anytime. Then it isn't work, it's a joy.

But it all starts with the time to write. One hour every morning. Or just some days of the week. Put it on your to-do list or in your calendar. If you don't create the time, your writing will be pushed aside by other obligations and will never happen.

The curse of the blank page {#blank-page}

Everyone knows it, even experienced writers. You have a topic, you've done the research, and now there's a blank page in front of you. How on earth do you begin?!

My recipe for this is simple. First, I always copy the outline I prepared earlier into the document. So when I start, the page isn't blank anymore.

And now the main trick of experienced writers — you don't have to write from the beginning. The beginning is hard. Write something about the main load-bearing idea first. Try to develop it, answer the likely questions, add examples, and so on.

Only then write the conclusion. And then you might realize the conclusion is actually a good beginning for the article, because it contains the summary.

Structure: put the important stuff up top, ask "why?" {#structure}

People do read online, but you have to win the battle for their attention. They're more patient with topics that interest them, or with authors they like. To boost your chances, make it easy for people to decide whether the text is for them or not.

First, write down the main idea — or at least what the article is about, or some surprising thing you discovered. That has to be in the headline or the first paragraph. It's called the inverted pyramid.

When I write about technology, I always try to answer three basic questions:

"What?" — what I'm writing about right now.
"Why?" — why it's interesting, important, useful, funny, or surprising to the reader.
"How?" — how to try the topic out in practice.

The "how" is important, don't forget it. People want to try out new knowledge as fast as possible, so I often add demos and practical applications to every article.

There's nothing complicated about it. These three questions have been my main checklist the whole time I've been writing.

I used these three questions to write this very piece.

Short, punchy, with verbs, the way you speak {#form}

Everyone can write, because everyone can talk.

In school they taught you to write so your language teacher would like it. But you can write differently — you can write the way you speak. The advantage is that nobody has to teach you this anymore.

The second advantage is that it'll be far easier for readers to read.

And then there's dictation. Dictation on a phone has come a long way, so a certain portion of my texts came about by dictating them into my phone. I then spent a long time editing, trimming, cleaning them up, sure. But dictation might be exactly the technology that helps you become a writer.

Write so it reads well. People online don't like long sentences. People don't like long paragraphs. Every sentence can be shortened. I'm doing it right now, and I assume that as a reader you don't mind at all.

When you do write longer sentences, you can suddenly change the pace or highlight information by using one thing. A short sentence.

When you want to emphasize a sentence, put it in its own paragraph.

If information is important, it should be in a heading inside the article. I'm not a fan of bolding text — to me it's a waste of attention. We have so many ways to highlight what matters: headings, sentences in their own paragraphs, bullet points, quotes, images, tables.

Better than bolding text is putting the information in a heading or another form of media.

When I do emphasize something inline, the way I'd emphasize it in speech, I use italics. Italics have the advantage of not pulling at the eyes, letting people read the text they chose smoothly.

Use verbs. A sentence without a verb is harder to read and harder to grasp. You can use such a sentence differently. As an exclamation, an accent. Otherwise, don't write much like this, without verbs.

Cut the filler. Nobody likes filler. When you reread your article, ask of every sentence whether it can be said more concisely and whether it even needs to be there at all.

You won't get far without feedback {#feedback}

Don't write for the drawer. A text comes alive only in another person's head, through their feedback.

If you're afraid of the failure of public publishing, shrink your audience.

Show your text to someone close to you. Ask them for their opinion or feedback.

My friend Ondřej Ilinčev, who has written for a long time and writes brilliantly, got started by emailing his articles to just a few clients at a time.

Another partner of mine, Robin Pokorný, writes among other places on his employer's internal blog.

Blogs used to have comments everywhere. Those were the golden days, because most people focused on the actual problems in the text. Today blog comments mostly don't work anymore. They've been replaced by comments on social media — but there are usually too few of them, which doesn't work for quality feedback. Or there are too many, and you don't want that either, because then they turn partly toxic and focus on the author themselves, or on something completely unrelated. Like the commenters' worldview.

Build yourself a safe environment of first readers. People who are kind to you, but who can also be honest.

If you dare to venture a bit further out, try social media. On Facebook and LinkedIn, for instance, you can write longer pieces. Pieces of just a few paragraphs work great.

Mastery in honing the core of an idea is offered by X and its post-length limit.

Check whether someone already writes about your topic. Send them your text — maybe they'll publish it. Don't worry, the media really aren't flooded with outside submissions. Very few people actually write.

I told you to definitely show your text to someone. Another person. But that "other person" can also be you. Just look at your text again a few days later. After a week it'll be even better. I've been my own editor this way for a long time. Texts and ideas ripen in the head.

I often surprise myself a week later at how badly I wrote something. But I can fix it.

Read your text out loud, or at least in a whisper. Does the read-aloud text make sense? Does it have good pace? Does it sound the way you speak? Reading your own text aloud really helps. You suddenly hear what you didn't see before.

Tools and skills: above all, learn to touch-type {#tools-skills}

Tools are overrated. But if you want, I'll mention the ones I use:

In Evernote (a notes database) I log ideas for pieces. I gradually flesh them out and add to them. When I learn something interesting about a topic, I add a link to that topic's page in Evernote. Then when I finally write it up, it's prepared and I don't have to do as detailed a research pass. I also often write the first drafts of my texts in Evernote.
I move texts from Evernote into Google Docs when I need feedback from other people. The collaboration features in Google Docs are indispensable.
I use ChatGPT as a writing assistant. It helps me do research and build structures. It gives me content feedback on my texts. It already does a lot of things brilliantly, though it doesn't yet catch all my language mistakes.
I store texts in Markdown. It's a format that's excellent for searching back through and editing. All my articles are in Markdown, all the chapters of all my books too. I can search back through Markdown when I want to add a link to a topic or edit something retroactively. Like deleting Internet Explorer from every text. That's a joy.
To make sure I'm writing well, I use grammar checkers and occasionally just a search engine. It's a shame to kill a piece with visible mistakes in it. A certain portion of readers is sensitive to that. I also watch out for correct typographic characters. Readers will forgive the odd mistake, but there can't be too many of them.

But choose your tools to suit yourself. Or don't. Tools won't make you a better writer.

There is, however, one skill I consider essential. It's something I hated in high school, only to discover a few years later that it's one of the most important skills school ever taught me.

Having all your fingers in play when typing is a superpower.

People sometimes tell me they don't understand my writing productivity. This is one of the answers. Between someone who touch-types and someone who types some other way, there's a huge difference in speed. That much I know for sure.

Writing is glorious {#glorious}

Writing can be one of the best things you ever do. It can help the world learn about you, just as you can help other people.

Writing can be so enjoyable that you choose it over the shows on Netflix.

You can write too. Carve out time for it, write from the core, write concisely, and improve through feedback from others or from yourself.

Start writing. Just start. Right now.

Here are some other resources on writing that I know well:

Ondřej Ilinčev wrote a nice piece on how to write an article in 3 hours. Ondřej is a master of writing efficiency.
I once enjoyed an article from a content agency that takes a more business-minded approach to writing. That'll come in handy if you want to squeeze some money out of writing.

What did I forget? What helps you with writing? Write to me by email or on social media.

Martin Michálek · Web & Performance

WebExpo 2026 in Prague: Switch Angel, Daniel Cuthbert, Mike Kus & FrontKec

An invitation to WebExpo 2026: Switch Angel, Daniel Cuthbert, Mike Kus & FrontKec

Four talks I'd hate to miss {#talks}

Recording FrontKec on Wednesday: a chat about the first day's topics {#frontkec}

A little discount from the garden…? {#discount}

Will AI Kill SaaS? Let's Think Again

AI is supposedly going to kill SaaS. Let's think about that one more time

We irrational humans and our AI catastrophes {#irrational-humans}

SaaSpocalypse {#saaspocalypse}

Joe and his invoicing software {#joe}

Day one — euphoria {#day-one}

Day two — what is git? {#day-two}

Day three — weird messages in the terminal {#day-three}

Day four — wait, the invoice is in euros? {#day-four}

Day five — "How dare you?" {#day-five}

SaaS is paid transfer of responsibility {#responsibility-transfer}

Vibe Coding: 25 Years of Building Websites, the Last Two Completely Different

Vibe Coding: I've Built Websites for 25 Years — the Last Two Months Were Nothing Like It

Swept Off My Feet {#riding-the-wave}

"Vibe… What?" {#vibe-what}

Vibe Coding vs. Vibe Engineering {#vibe-coding-vs-vibe-engineering}

Where Do I Start as a Beginner? {#where-to-start}

Me and Vibing: Four Examples {#four-things-i-built}

Example one: a prototype of the FrontKon site {#example-frontkon}

Example two: a website for my son {#example-son}

Example three: editing copy in PageSpeed.ONE {#example-pagespeed}

Example four: migrating Vzhůru dolů from PHP to Astro {#example-migration}

Developers Out of Work? {#developers-out-of-work}

Two types of developers {#two-types-of-developers}

You have to be a developer, or gradually become one {#you-have-to-be-a-developer}

"Software is eating the world" {#software-eating-world}

A Few Concrete Cursor Tips {#cursor-tips}

Modes in Cursor {#cursor-modes}

Context shortcuts {#context-shortcuts}

Vibe rules {#vibe-rules}

Models {#models}

Flow Not Found… or Is It There After All? {#flow}

This Is Big, but We Still Need People {#people-still-matter}

My 2025 in review: from freelancer to business owner

My 2025: entrepreneurial, strategic, successful — but also anxious and searching for form

A little anxiety about the world out there {#anxiety}

From freelancer to business owner {#business-owner}

PageSpeed.ONE: consulting is flying, but we want to push harder on the product {#pagespeed}

FrontKon and Frontendisti.cz: from community to company thinking {#frontendisti}

The little crisis {#crisis}

(Out of) shape {#shape}

"2025 was great!" {#great}

The art of saying no

The art of saying no

Why capable people drown {#why-capable-people-drown}

No is not arrogance {#no-is-not-arrogance}

From maker to manager: my pivotal 2024

From maker to manager: my pivotal 2024

From coder and content maker to manager {#maker}

Who else, if not you? {#who}

A new environment {#environment}

A new inner baby {#baby}

What else did 2024 bring me? {#more}

WebP images: the leaner alternative to JPEG, PNG, and GIF

WebP: smaller images without dropping anyone

Browser support: the Chromium crowd, plus Firefox and Safari {#browser-support}

A JPEG fallback with <picture> {#fallback}

How much data does WebP actually save? {#savings}

How to produce WebP {#how-to-produce}

Save on developers, spend on consultants

Save on developers, spend on consultants

The off-the-shelf platform trap {#off-the-shelf-trap}

WordPress, the classic {#wordpress-classic}

Just put it in the calculation {#put-it-in-the-calculation}

Web Vitals: Google's core metrics for real-world speed

Web Vitals: Google's core metrics for real-world speed

The metrics {#metriky}

Core Web Vitals {#core}

What about the other metrics? {#dalsi-metriky}

How to measure Web Vitals {#mereni}

CSS Units (em, rem, %, px, vh, vw): Which One to Use Where?

CSS Units (em, rem, %, px, vh, vw): Which One to Use Where?

A quick overview of useful units {#overview}

Which units to use in which situations? {#scenarios}

A JPEG fallback with `<picture>` {#fallback}

Type selector – `tag` {#type}

Universal selector – `*` {#universal}

Class selector – `.className` {#class}

ID selector – `#id` {#id}

Attribute presence and value selectors – `[attr]` {#attr-value}

Substring attribute selectors – `[attr^=]` {#attr-substring}

Case-insensitivity flag `[ i]` {#attr-case}

Descendant combinator – `A B` {#descendant}

Child combinator `A > B` {#child}

Next-sibling combinator `A + B` {#next-sibling}

Subsequent-sibling combinator – `A ~ B` {#subsequent-sibling}

Column selectors – `A || B` {#column}