That’s a big no-no to me.
I do not think having @scope dramatically improves the situation of maintainable CSS. Nested rules will quickly go out of hand if one is not careful. Plus, we already have sass and postcss-nested for years.
CSS nesting is already mainline, so no preprocessing is needed at all. @scope is something different from nesting.
I like to use tailwind, but I feel that it should not be included in a standard phoenix application.
IMO it comes with too many strings attached.
I do this, but my webapps are mostly small internal tools (or startup ideas that never go anywhere). Mostly I tend to start with classless frameworks (mvp.css, classless.css etc), then add styles gradually in a CSS file. I’m not sure why separating styles from markup was always a terrible idea, but maybe I like terrible ideas.
2 Likes
It is not a terrible idea at all, it is following one of the most fundamental engineering principles. Separation of concerns. I would like to encourage any web developer to do a little research of the history of how this all came to be. There is no reason why tailwind needed to be utility classes, it could have been semantic, and if it was they probably wouldn’t have hit all the issues they have had.
1 Like
The fact that people defend this esoteric idea of separating styles and markup always baffles me. Like yeah, you don’t want to send a massive dump of crap in 1998, and CSS is a nice enough way to extract out a design system yet keep things small. But come on its $CURRENT_YEAR. IMO DiasyUI is basically the logical conclusion of how far you can take a CSS design system, while being as ergonomic as possible. But it is what is: a hack. And if you want to extend every possible minor variation as it’s own semantic variant class defined in some god-forsaken stylesheet, please go for it. But I will be using utility classes bc it’s the closest thing we have to sanity in web styling.
And yes you could make a number of small classes by yourself to augment these one-offs. But what do you get when you keep pushing down that road? A worse version of tailwind that you had to make yourself bc you’re too stubborn to just use it.
If an analogue to the style attribute was created that was as performant and extensible as CSS, and there was a bombproof implementation of properly composable markup tags to replace what we could consider a “class”, I have no doubt it would be lauded as a great improvement. Like it or not, CSS-in-JS is popular for a reason, despite the fact that it is a MASSIVE hack and very complex.
4 Likes
I think separation of concerns is only a design principle, and the fact that we still have such different opinions after so many years of web development shows that we either haven’t found the right solution yet, or that the right solution doesn’t exist at all and everyone just uses what they like best and what they can work with best.
3 Likes
To be fair, it’s not just Phoenix that’s defaulting to it. This is part of Figma’s MCP server’s prompt:
⏺ figma-dev-mode-mcp-server:get_code (MCP)(nodeId: "4281:120016", clientFrameworks: "phoenix,liveview", clientLanguages: "elixir,html,css")
⎿ const imgImage35 = "http://localhost:3845/assets/8e4ae2ec49b12125c2263a7dc8aee796cd721972.png";
const img = "http://localhost:3845/assets/f695215f2811ef96fa3fcd1aa05038d9dfcc8b73.svg";
const img1 = "http://localhost:3845/assets/9e10c4327a0c790367bf62ff3fd9e729ec186000.svg";
… +412 lines (ctrl+r to expand)
⎿ Use tailwind if available, otherwise detect the project's styling approach (e.g. CSS in JS, CSS Modules, theme providers, etc) and follow it. Use vanilla CSS only if no system is detected. Do not install any dependencies
In most cases it really doesn’t matter, browser engines are fast and latency tend to eat everything. But if you’re targeting a native experience with web, then it’s completely unavoidable as you have to consider how the browser engine works.
I’m afraid you have entirely missed the point. I am not suggesting that one should avoid using semantic HTML elements when they do exist. The problem is that most of the time they do not, and attempting to shoehorn your UI into the pitiful handful of native “semantic” controls handed to you by the platform will inevitably result in a bad user interface.
Here is a component reference from Leopard in the late 2000s. Look at how many of these have no semantic analog in 2025. How do you create a tab bar? With radio buttons? Does that sound semantic to you?
What about a combo box? Here it is, straight from the W3C. This is the best semantic HTML has to offer. Two divs and a ul in a trench coat.
Accessibility is about more than screen readers, or even disabilities. Have you ever sat down and watched a “regular” person try to use the web? It makes my blood boil. What we (programmers) have wrought upon the rest of the world is unforgivable.
Decades ago we had menus that tracked mouse movement with a triangular hitbox so that you could move to the next (nested) menu without accidentally closing it. Today, in 2025, it took me 20 seconds to click on the correct wayback snapshot because the hover kept kicking off before I could get it. I truly wish I was making this up.
The viewpoint that you are espousing is dead. It is so completely, utterly dead that there is no point in wasting another second of human cognition to further it. Even the web platform itself has conceded this point. Let’s move on.
And what, pray tell, would that developer learn during this history lesson? Perhaps that the purpose of the cascade was to allow the user agent to provide its own stylesheet which websites would then selectively override?
Of course in modern times browser developers have made an effort to standardize those user agent stylesheets and web developers have adopted a standard practice of completely overriding them with reset styles. All of this completely nullifying this “separation of concerns”, which has amounted to nothing more than a fantasy.
It is clear that the designers of the time had little concept of the application platform the web would become (and how could they?). The behaviors provided by CSS are very sensible for styling documents and absolutely excruciating for building applications.
The reality is that CSS in JS is the best path forward (short of throwing CSS and the DOM away altogether), though in practice it need not be JS (it could just as well be Elixir). But I did not even want to try going down that rabbit hole on here, lol.
1 Like
