Post

Why we are still arguing about CSS in 2026. andreasmoller.dk/blog/why-we-...

Nice. 🎃 the scary words are „being able to ignore 95% of the codebase when implementing a feature …“ These can cause so many code bases to bloat up. This works if your project is small and short term. It adds up over time. And changes on the design system level become harder. (1/2).

I did consider making this the central theme of the post but it probably warrants a second one. The difference is that we are scared of different things. You are scared of bloat, and duplicating code which makes it much more work to make changes to the design system.

I am scared of complexity. Having a code base where you need to hold too much information in your head just to make a simple style change. I am so scared of this, that I am more than happy to accept a code base that is much less DRY.

I don’t mind that it is more work to update a design system. I worry about people updating it by mistake. With scoped styles you are trading efficiency for simplicity. On smaller projects that is not that useful. On large projects it is essential.

I would actually argue that this only works on smaller and contained projects. A large project (in my definition) is not defined by the number of users or devs. They become big the same way business grows: the second brand, that kreeps in, the next partner to support, the large campaign, the …

… shifting regulatory framework and so on. As you said: for multi-brand sites you lay a solid foundation that supports multiple themes, looks and animations. This also supports regular a/b testing (at least when having to rely on external tools).

I do cover this exact case in the post as a scenario where you might want to choose separation of concerns, but this is not related to the size of the project.

OK, if you want to stick to a tight definition of "size" let's call it "age", "maturity" or something else. Some complexities are inevitable with given time. Tastes change, brands mature, other tools are acquired instead of developed, build tools and frameworks die. Keeping close to the platform …

… will not completely prevent you from all repercussions of these events. But it always gives you room to breathe when these situations occur.

The platform was not designed for the kind of projects that people use it for today. As a result the platform had to evolve. HTML, CSS and JS went from being source code to being, lets call it whimsical assembly languages. It is kinda quirky, but it works.

developer.mozilla.org/en-US/docs/W... The idea of scopes is very much rooted in a JS mindset. When scoped styles arrived, the CSS crowd is still puzzled what do do with it. And the JS brotherhood ignores it by principle somehow. And yes, we are tired of that attitude, too.

Are you really so angry at developers that you have to reject any idea coming from someone who knows JavaScript? Scope is not a JavaScript concept. It existed decades before JavaScript, HTML or CSS. It exists across all programming paradigms.

The CSS @scope as nothing to do with scoping. I have no idea what it is supposed to do. As far as I can tell it is just a very clumsy way to write selectors.

I have no problem with anybody who does JS. The platform is actually developing amazingly. My problem is replacing basic JavaScript and Custom elements with framework and build centric workflows by default.