An in-depth guide to customising lists with CSS - Piccalilli
Think you know about styling lists with CSS? Think again!
This is just a taste of the kind of in-depth knowledge that Rich will be beaming directly into our brains at Web Day Out…
Think you know about styling lists with CSS? Think again!
This is just a taste of the kind of in-depth knowledge that Rich will be beaming directly into our brains at Web Day Out…
This is an excellent one-stop shop of interface patterns:
This is an organic collection of common JS patterns that can be replaced with just HTML, CSS, and no, or very low, JS. As HTML and CSS continue to mature, this collection should expand.
There have been so many advances in HTML, CSS and browser support over the past few years. These are enabling phenomenal creativity and refinement in web typography, and I’ve got a mere 28 minutes to tell you all about it.
I’ve been talking to Rich about his Web Day Out talk, and let me tell you, you don’t want to miss it!
It’s gonna be a wild ride! Join me at Web Day Out in Brighton on 12 March 2026. Use JOIN_RICH to get 10% off and you’ll also get a free online ticket for State of the Browser.
Jemima runs through just some of the exciting new additions to CSS:
Replacing 150+ lines of JavaScript with just a few CSS features is genuinely wild. We’re able to achieve the same amount of complexity that we’ve always had, but now it’s a lot less work to do so.
And Jemima will be opening the show at Web Day Out in Brighton on the 12th of March if you want to hear more of this!
There’s a new meta tag on the block. This time it’s for allowing system-level text sizing to apply to your website.
This episode of the Shop Talk Show is the dictionary definition of “rambling” but I had a lot of fun rambling with Chris and Dave!
This is depressing.
Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing “jank” in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.
This is a great way to think about client-side JavaScript!
Also:
Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.
Progressive enhancement is about building something robust, that works everywhere, and then making it better where possible.
You might not need (much) JavaScript for these common interface patterns.
While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.
Yes! Client-side JavaScript should do what only client-side JavaScript can do.
The core idea of the event is to get you up to speed on the most powerful web platform features that you can use right now. I love that because it aligns perfectly with what I’ve been working on over the last couple of years: finding ways to break old habits to get the most out of CSS.
Eric Meyer and Brian Kardell chat with Jay Hoffmann and Jeremy Keith about Shadow DOM’s backstory and long origins
I enjoyed this chat, and it wasn’t just about Shadow DOM; it was about the history of chasing the dream of encapsulation on the web.
Explore the platform. Challenge yourself to discover what the modern web can do natively. Pure HTML, CSS, and a bit of vanilla JS…
This is a superb way to deprecate a little JavaScript library. Now that you can just use HTML instead, the website for Pikaday has been turned into a guide to choosing the right design pattern for your needs. Bravo!
Pikaday is no longer a JavaScript date picker. Pikaday is now a friendly guide for front-end developers. I want to push developers away from the classic date picker entirely. Especially fat JavaScript libraries.
We’ve arrived at an industrialised process, one that’s like an assembly line for applications. Frameworks like React have become the machinery of that assembly line. They enable us to build efficiently, to build at scale, to build predictably. But they also constrain what we build.
But what aren’t we building? What new kinds of experiences, what new kinds of applications, what new kinds of interaction could we create if we were deeply exploring and engaging with the capabilities of the platform? I don’t know, because we’re not building them. We’re building what the frameworks enable us to build, what the assembly line can produce efficiently.
Collectively, as an industry and as a profession, consciously or not, we’ve chosen this maxima that we’re stuck on. We can build what React or Vue or Next or name your framework/library enables us to do.
I share John’s despair at this situation, but I don’t share his belief that large language models will save us.
So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”
Grrr… it turns out that browsers exhibit some very frustrating behaviour when it comes to the video element. Rob has the details…
When I set about writing this article, I intended it to be a strong argument for progressive rendering. But after digging into it, my feelings are less certain.
Framework monoculture is a psychology problem as much as a tech problem. When one approach becomes “how things are done,” we unconsciously defend it even when standards would give us a healthier, more interoperable ecosystem. Psychologists call this reflex System Justification.
The explains a lot about React-driven front-end development!
When a single toolset becomes the default, we don’t just prefer it, we build narratives that justify it. And that’s when a tool quietly becomes a gate or even a destructive force.
I’m not the only one who’s amazed by how much you can do with just a little CSS these days.