CSS in 2025: Let's write html inlined styles as if it was 2005 and separation of formatting/representation was never invented. I talk of tailwind, of course.
I was recently doing some very specific web scraping of some very public very static documents. About 25% of them use a soup of divs with hashes for class names. Not a <main> or <article> or <section> in sight. I am fine with the idea of what tailwind does but like at least using semantic tags where appropriate could be a thing.
I don't think "separation of concerns" is entirely dead. Ideally, the CSS is readable and maintainable, and that implies structure. If you have a bunch of (co-)related components, you don't want to find/replace tailwind class names when you need to change the layout. So you separate that part of the layout in classes based on (layout!) functionality. You can see that as "concerns."
You can separate concerns without violating locality of behavior, and that’s exactly what tailwind does.
It admittedly does not do a good job at being very DRY but I think that’s poorly applied to HTML/CSS in general, and the most DRY css is often over abstracted to the point of becoming nigh uninterpretable.
I can't believe this isnt better understood. Style definitions on reusable components are good. The idea that your css doesn't have to know about your html just creates tons of problems and complexity. Global themes and reusable styled are fine.
If we are talking about statically defined html then sure. make your global css files.
SoC is how all maintainable software is built. A function for A, a class for B, DDD-spec'd modules and features, databases on separate machines, API definitions, queuing systems, event systems, load balancing, web servers.
You don't even need to think of the web to see how content and presentation are different. Try editing a text file with hard line breaks in and you'll quickly understand how presentation and content are orthogonal.
HTML vs. CSS is a separation of technologies. If HTML was really only about the content and the CSS was only about styling, we wouldn't have to write div soups to style our websites (.container-wrapper .container .container-inner { /* "separation" */ }) and we wouldn't have to adjust our HTML when we change the layout.
I find that most div soup is going away with CSS Grid. CSS Grid is often best when you lose wrappers and nesting. subgrid and display: contents help pop layers when you can't touch the HTML nesting, but now a lot of nesting feels unnecessary in the first place.
Having worked on teams that wrote bad (S)CSS and teams that wrote bad tailwind, I prefer bad tailwind.
With tailwind, I can guarantee that changing a style in one component will only change that component. With css, there is no such guarantee. So of course the (wrong) way many devs fix it that is to add a new class, probably doubly specific, sometimes with important, and then everyone is sad.
Are we still complaining about Tailwind? This ship has sailed. The world is so much better than the old BEM/LESS hell, it is wonderful. UnoCSS is even greater in empowering frontend developers.
What stops you from doing the same thing in CSS? It is trivial to assign a specific CSS class to an element that is the root node of a "component" and scope rules under that.
Obfuscate? I can learn tailwind and use it in dozens of projects. I can use tailwind in my project and onboard dozens of developers immediately. I can learn your CSS conventions and use them in exactly one project.
If everything in your code is a React component, I get why you would just want to write the styles right there.[0]
Then again, why write `<Button>` if you could just write `<button>` and style it with standard CSS.
> If everything in your code is a React component, I get why you would just want to write the styles right there.
Even for keeping the style close to the component, you can just use standard css.
Create a folder Button, create two files Button.tsx and Button.css in that folder, import the css file in the tsx file, add a class "button" on the first element the tsx file renders, start all the rules in the css file with ".button " to encapsulate the style.
People will say it's too much work, but it took me like 5 sec.
Because button is literally anything clickable. Not everything is a boxed button. You cannot just globally add a style to <buttton> and call it a day. For example, an upvote (^) button, a close (x) button, etc. A lot of clickable elements aren’t inside a [click me] box
The "C" (Cascade) in CSS doesn't suck, the education about it sucks.
People don't know how it works, then things go wrong so they learn to work around it.
That's what led to things like div + class soup that you get with the BEM naming convention or Tailwind.
The cascade is actually awesome, super powerful and if you know how to use it, it can greatly simplify your code.
Education is the problem and the solution.
---
To anyone outside the CSS space, this is the closest analogy I can find:
In the American education system, there was a recent-ish change where children are "taught" to read using a method of just learning the shape of every word (e.g. "thermally" has a th at the start and ly at the end, so it must be the word "thermally", despite other similar looking words like thematically).
The method was disproven but the American education system still uses it.
Now illiteracy rates are climbing where almost 1/4 Americans (USA) can't read.
It's basically the same thing with CSS, where developers don't know what the code they're reading/writing is actually going to do.
If you're building a "webapp" where you think in terms of components, no point keeping the style sheet separate..
If you're building a "website" which is basically a list of hyperlinked documents with the same styling, having just one style sheet would make sense...
Of course, there's a lot of gray area in between the two...
At the end of the day, the most that most of us can really do is be annoyed at the quirks of these leaky abstractions in the large codebases that's thrust upon us.
If I may be so bold, the coding agents are really good at this stuff. Save yourself the pain of front end and make a clanker do it. Or at least make the clanker to the heavy lifting and just do tweaks yourself.
Yeah and it's a really good idea. You can't really 'separate layout from style.' The layout and the style are both parts of the UI. HTML isn't the content, it's the layout.
Even if you believe separation of concerns is the eleventh commandment, HTML and CSS are the same kind of 'concern' anyway. They're both at representation layer. Pretending you can decouple them is just burying the head in the sand.
I dislike the examples here where the "old" way works in all browsers, but the "new" way only works in Chrome/Edge. IMO, it's irresponsible to include such examples, since it makes the Blink monoculture worse.
Agreed; wish the default filter was "newly available" since that includes all 3 major browsers (Chrome/Edge, Safari, Firefox) but still includes new stuff that isn't "baseline" yet.
Sometimes I'm developing an internal tool or something only for myself / handful of people. I'm perfectly fine saving time and complexity using a one liner modern CSS solution instead of having to rely on some hacky unreadable code to support 10 years of legacy browsers.
It is an idea I started playing with when custom properties landed in browsers, around 2016 or 2017? Around 2021 I started using the technique in client sites too.
Now I want to write a 2026 version of the post that talks about container queries too. The technique becomes more powerful if you can rely on container queries and on the cqw unit. (You cannot always. That stuff is still new.)
For an example of the convenience cqw offers if you can rely on it, see the snippets I have in this:
3) :is(...), before you had to write :not(:not(...)).
4) :where(...), similar to :is(...), but the selector weight inside :where becomes 0. Useful when you need deep/complex selectors without increasing the selector weight.
As a tip - most LLMs are unaware it exists due to either knowledge cutoff or not having enough training data for it.
As a recommendation, include some examples of it in your AGENTS.md. Here's what I use:
--------------------------------------
## CSS nesting (required)
When writing CSS (including component `css()` strings and `soci-frontend/soci.css`), *use modern CSS nesting* where it improves readability and reduces repetition.
- Prefer nesting with the `&` selector for pseudo-classes / pseudo-elements and compound selectors.
- Avoid duplicating the parent selector when nesting can express it once.
- Reference: [MDN `&` nesting selector](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...)
Mine is text-box: trim. Twenty years of trying to explain to graphic designers why it’s next to impossible possible to get the top of a capital letter to a box, I feel free like a bird.
Why/how do you grep selectors? Seems overly optimistic to be able to guess the particular rule pattern that is applying a style. Browser tools are much more reliable.
Stop pinning things to the edges of the screen and window. Some sites have literally over 50% of the viewable area taken up by irrelevant static elements. Let the content scroll, like god intended.
In case the author happens to read these - final statement in native CSS nesting is no longer true.
"The only small difference from Sass: for element selectors you need the & prefix. In Sass you could write a { color: red } inside a parent, but native CSS requires & a { color: red }."
It was true for a bit, but fixed within 2-3 releases iirc. You can now freely nav { a { color: red; } }
In the past this was a major issue that meant useful features were only ever usable after IE/Safari finally supported them half a decade later, but it has seriously gotten better. Sadly as a result of Chromium's overbearing presence, but it's a helpful outcome at least.
Problem with safari though is that it’s tied to OS updates that many people just defer for insanely long periods of time. So unlike the other browsers, it’s not evergreen, so if you need to support any iOS users or Mac users who don’t use chrome etc, you’re out of luck
That would actually fix some ugly CSS I have. The demo works. Neat.
Except... the demo doesn't use either the old syntax or the new syntax. The browser support is wrong (Firefox doesn't support it, the site says Firefox 16+; it says Chrome 43+ but in reality it's much newer: Chrome 148+). It says "Since 2018" but the spec was introduced in 2024.
So maybe an interesting overview of things that might be available or might not, but the filtering and data on the site doesn't seem to be useful.
Readit News
I disagree. And that makes me the loser here
I can understand how it might be useful for certain types of web development, e.g. landing pages where the content and styles are tightly coupled.
So as a technology, it's OK. But my god its userbase is toxic and obnoxious.
It admittedly does not do a good job at being very DRY but I think that’s poorly applied to HTML/CSS in general, and the most DRY css is often over abstracted to the point of becoming nigh uninterpretable.
If we are talking about statically defined html then sure. make your global css files.
You don't even need to think of the web to see how content and presentation are different. Try editing a text file with hard line breaks in and you'll quickly understand how presentation and content are orthogonal.
You don't have to: https://csszengarden.com/
With tailwind, I can guarantee that changing a style in one component will only change that component. With css, there is no such guarantee. So of course the (wrong) way many devs fix it that is to add a new class, probably doubly specific, sometimes with important, and then everyone is sad.
Non-BEM CSS with ids and multi-classes everywhere was hell.
I have never been happy on how I manage CSS. With tailwind, I am still unhappy about my styles but I can make my ugly UIs faster.
[0]: https://mastrojs.github.io/blog/2025-11-27-why-not-just-use-...
Even for keeping the style close to the component, you can just use standard css.
Create a folder Button, create two files Button.tsx and Button.css in that folder, import the css file in the tsx file, add a class "button" on the first element the tsx file renders, start all the rules in the css file with ".button " to encapsulate the style.
People will say it's too much work, but it took me like 5 sec.
Not saying it’s good/bad, but it feels like that’s the use case
People don't know how it works, then things go wrong so they learn to work around it.
That's what led to things like div + class soup that you get with the BEM naming convention or Tailwind.
The cascade is actually awesome, super powerful and if you know how to use it, it can greatly simplify your code.
Education is the problem and the solution.
---
To anyone outside the CSS space, this is the closest analogy I can find:
In the American education system, there was a recent-ish change where children are "taught" to read using a method of just learning the shape of every word (e.g. "thermally" has a th at the start and ly at the end, so it must be the word "thermally", despite other similar looking words like thematically).
The method was disproven but the American education system still uses it.
Now illiteracy rates are climbing where almost 1/4 Americans (USA) can't read.
It's basically the same thing with CSS, where developers don't know what the code they're reading/writing is actually going to do.
If you're building a "webapp" where you think in terms of components, no point keeping the style sheet separate..
If you're building a "website" which is basically a list of hyperlinked documents with the same styling, having just one style sheet would make sense...
Of course, there's a lot of gray area in between the two...
At the end of the day, the most that most of us can really do is be annoyed at the quirks of these leaky abstractions in the large codebases that's thrust upon us.
Even if you believe separation of concerns is the eleventh commandment, HTML and CSS are the same kind of 'concern' anyway. They're both at representation layer. Pretending you can decouple them is just burying the head in the sand.
At least html and CSS are both presentation. React/JSX now confuses presentation and business logic.
React was originally designed to be the "V in MVC". You can still use it that way. React becomes very simple when you only use it as the V in MVC.
Deleted Comment
https://modern-css.com/smooth-height-auto-animations-without... This claims `interpolate-size` is newly available and works in all major browsers.
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P... This states `interpolate-size` only works in Chrome/Edge.
I tested the demo and it's definitely not working in my copy of Firefox.
https://moderncss.dev/
One of the best educational resources for modern CSS.
BTW, one of the reasons I love modern CSS is front-end performance. Among other things, it allows you to make smaller DOMs.
I talk about a modern CSS technique that does that here:
https://op111.net/posts/2023/08/lean-html-markup-with-modern...
It is an idea I started playing with when custom properties landed in browsers, around 2016 or 2017? Around 2021 I started using the technique in client sites too.
Now I want to write a 2026 version of the post that talks about container queries too. The technique becomes more powerful if you can rely on container queries and on the cqw unit. (You cannot always. That stuff is still new.)
For an example of the convenience cqw offers if you can rely on it, see the snippets I have in this:
https://omnicarousel.dev/docs/css-tips-know-your-width/
1) Nested selectors.
2) :has(...).
3) :is(...), before you had to write :not(:not(...)).
4) :where(...), similar to :is(...), but the selector weight inside :where becomes 0. Useful when you need deep/complex selectors without increasing the selector weight.
As a tip - most LLMs are unaware it exists due to either knowledge cutoff or not having enough training data for it.
As a recommendation, include some examples of it in your AGENTS.md. Here's what I use:
--------------------------------------
## CSS nesting (required) When writing CSS (including component `css()` strings and `soci-frontend/soci.css`), *use modern CSS nesting* where it improves readability and reduces repetition.
- Prefer nesting with the `&` selector for pseudo-classes / pseudo-elements and compound selectors. - Avoid duplicating the parent selector when nesting can express it once. - Reference: [MDN `&` nesting selector](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...)
### Quick reference
#### Pseudo-classes / no-whitespace attachment
```css .button { color: var(--text);
} ```#### Pseudo-elements
```css .fade { position: relative;
} ```#### Descendant nesting (whitespace implied)
```css .card { padding: 12px;
} ```#### “Reverse context” (`.featured .card`) using `&`
```css .card { .featured & { border-color: var(--brand-color); } }
"The only small difference from Sass: for element selectors you need the & prefix. In Sass you could write a { color: red } inside a parent, but native CSS requires & a { color: red }."
It was true for a bit, but fixed within 2-3 releases iirc. You can now freely nav { a { color: red; } }
86-90% support
Browsers: Yeah, but beware of limited availability, most of those creative examples are in the 40-50% browsers support range.
https://wpt.fyi/interop-2025
Not if you filter the examples. Click "widely available".
That would actually fix some ugly CSS I have. The demo works. Neat.
Except... the demo doesn't use either the old syntax or the new syntax. The browser support is wrong (Firefox doesn't support it, the site says Firefox 16+; it says Chrome 43+ but in reality it's much newer: Chrome 148+). It says "Since 2018" but the spec was introduced in 2024.
So maybe an interesting overview of things that might be available or might not, but the filtering and data on the site doesn't seem to be useful.