I think the way we currently write CSS subtly shapes the way we think about components. By having the visual styles completely decoupled from the semantic meaning, accessibility is easy to forget, because we can’t physically see missing attributes. When the styling hook is anchored to semantics, you can’t get the visual styles without also getting the parts that make it accessible.

Tom Bedor, on forwarding AI output to a colleague:

If you are requesting human attention, demonstrate human effort.

This reminded me of a line from Don’t ask to ask, if you’re not willing to do the work to solve your problem, why should we?

Today I learned via Paweł Grzybek’s post on Mastodon, where Temani Afif pointed out that text decorations propagate to their descendants, they aren’t inherited.

The difference between propagation and inheritance is that the descendants don’t get their own text-decoration property. So, the line, color, style and thickness are all determined by the ancestor where text-decoration was declared.

A descendant can still declare its own text-decoration, but that creates an additional decoration on top, it doesn’t modify or remove the ancestor’s.

Today I learned, adding tabindex="-1" to skip link targets is likely no longer necessary in modern browsers.

Manuel Matuzović tested skip links without tabindex="-1" on targets across major browsers and screen readers on macOS, Windows and Android, concluding it is safe to remove in most setups, thanks to sequential focus navigation starting point.

Furthermore, adding tabindex="-1" to skip link targets also introduces a regression in usability. With tabindex="-1" on main, clicking on any non-interactive area inside main makes main itself the focus starting point. So, the next tab press sends focus to the first focusable element in main, not the next one after where the user clicked. The gov.uk team removed tabindex from main for this reason.

Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them.

You can’t write a compelling narrative about the thing you didn’t build. Nobody gets promoted for the complexity they avoided.

Complexity looks smart. Not because it is, but because our systems are set up to reward it.

Today, while working through an exercise in Eloquent JavaScript, I learned about the concept of parity in maths.

The parity of an integer is its attribute of being even or odd. Thus, it can be said that 6 and 14 have the same parity (since both are even), whereas 7 and 12 have opposite parity (since 7 is odd and 12 is even).

– Weisstein, Eric W, Parity

Initially, I had assumed “same parity” meant “same value”, which is roughly what it means in English. However, in maths it’s narrower. It just means both numbers are even or both are odd.

Your AI coding agent, the one you use to write code, needs to reduce your maintenance costs. Not by a little bit, either. You write code twice as quick now? Better hope you’ve halved your maintenance costs. Three times as productive? One third the maintenance costs. Otherwise, you’re screwed. You’re trading a temporary speed boost for permanent indenture.

[…] The math only works if the LLM decreases your maintenance costs, and by exactly the inverse of the rate it adds code. If you double your output and your cost of maintaining that output, two times two means you’ve quadrupled your maintenance costs. If you double your output and hold your maintenance costs steady, two times one means you’ve still doubled your maintenance costs.

A developer who builds accessible interfaces is more skilled. Say this out loud. Repeat it often. A developer who creates accessible interfaces isn’t doing extra work; they’re doing the work the right way.

No matter how rapidly technology changes, I am coalescing around some core beliefs:

1. Things that are worth doing are worth doing well.
2. Things that are done well require time and effort.
3. You make meaning through the doing.
4. Ideas are common; effort is not.
5. There are no shortcuts.

I just read Dave Rupert’s post on Inverted themes with light-dark(). It’s great.

I wish light-dark() accepted any value and not just colors. I have a use case where I use lighter font weights in dark mode.

Bramus wrote about a custom --light-dark() function using @function, if() and color-scheme() that would solve this in the future.

Just watched the latest Whiskey Web and Whatnot episode with Chris Coyier and Dave Rupert. No one would’ve guessed that I was watching a web dev podcast from how much I was laughing.

At one point in the episode Adam mentions, “holy crap, my job is now leftover tokens in a burn window”. If Adam can feel like AI is making his work redundant then what hope do I have? 🙈

Harry Roberts on what CSS containment actually is, what each contain value does, and how to use it confidently on real projects without creating hard-to-debug side effects.

Last week, I built a visual explainer of the CSS Cascade.

I used anchor positioning with chained anchors to stack the cascade steps. It worked, but Safari 26.4 and earlier had a bug with chained anchors, so I had to exclude Safari entirely via an @supports hack.

I wasn’t entirely happy with that, so I refactored the layout to use a subgrid based approach with grid-template-areas. Since subgrid became Baseline Widely Available recently, the timing also worked out.

While I was at it, I also restructured the HTML such that each cascade step is now a list item inside an ordered list, which gives better semantics.

I built a visual explainer of the CSS Cascade, the algorithm that determines the “winning value” from a list of competing declarations.

After Web Day Out 2026, I was checking out Manuel Matuzović’s UA+ stylesheet. Manuel mentioned that he wraps all rules in an anonymous layer to avoid specificity issues. I realised I didn’t actually understand how anonymous layers worked, so I went back and re-read Miriam Suzanne’s cascade layers guide on CSS-Tricks. I really liked the way Miriam presented the cascade and specifically the order of precedence within each step.

Recently, while learning @scope, I had come across a diagram of the cascade in Bramus’ article on @scope. I had seen it before in his CSS Day 2022 talk as well but this time it stuck with me. The layout just made the cascade click visually.

I wondered if I could combine Bramus’ cascade diagram layout with the order of precedence information from Miriam’s article. The early CodePen prototype turned out well enough that I decided to polish and publish it.

There are still some things to be done. The website currently fails WCAG Success Criterion 1.4.4: Resize Text (Level AA) under certain conditions. I haven’t landed on a fix that works for the design yet. Hit me up if you have any ideas.

Simon Willison on what they mean by “good code”:

• The code works. It does what it’s meant to do, without bugs.
• We know the code works. We’ve taken steps to confirm to ourselves and to others that the code is fit for purpose.
• It solves the right problem.
• It handles error cases gracefully and predictably: it doesn’t just consider the happy path. Errors should provide enough information to help future maintainers understand what went wrong.
• It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future.
• It’s protected by tests. The tests show that it works now and act as a regression suite to avoid it quietly breaking in the future.
• It’s documented at an appropriate level, and that documentation reflects the current state of the system - if the code changes an existing behavior the existing documentation needs to be updated to match.
• The design affords future changes. It’s important to maintain YAGNI - code with added complexity to anticipate future changes that may never come is often bad code - but it’s also important not to write code that makes future changes much harder than they should be.
• All of the other relevant “ilities” - accessibility, testability, reliability, security, maintainability, observability, scalability, usability - the non-functional quality measures that are appropriate for the particular class of software being developed.

Libraries are bits of other people’s code that I call from my code. Frameworks are other people’s code that call bits of my code.

Writing code has never been the sole activity of a software engineer. The craft has always been figuring out what code to write. Any given software problem has dozens of potential solutions, each with their own tradeoffs. Our job is to navigate those options and find the ones that are the best fit for our unique set of circumstances and requirements.

When you offload your thinking, you might be on-loading someone else’s you’d never agree to — personally or collectively.

I couldn’t make it to Web Day Out 2026. Thankfully, Jeremy wrote about it and linked to a bunch of online talk about it. Special shout out to Josh Tumath who live-blogged each talk.

By all accounts, it was an excellent event. The regret at missing out (RAMO) is real. I remotely attended State of the Browser 2026 and I’d love it if more events offered a remote option.

Many of the speakers were kind enough to share a link to their slides. I haven’t checked out all of them yet, but I liked Manuel Matuzović’s talk ‘Breaking with habits’. So much so that I feel the urge to redesign my portfolio based on the approach he showed. For now, I’ll dive deep into his UA+ stylesheet and oli.css project to get a deeper understanding.