Utility First CSS Isn’t Inline Styles | Sarah Dayan | CSS Day 2024 

I share your skepticism, but I do find it interesting that the 'separation of concerns' between HTML and CSS was never really there. Often, to achieve a styling goal, one is left with no choice but to restructure the markup. The idea that markup is strictly semantic and unrelated to styling is a fantasy. Even CSS grid is not a powerful enough tool to prevent me from touching my markup if I'm only interested in making a 'visual' change. An HTML document is a way of serializing data for the end-users visual system. The structure of the document is inseparable from the way it is styled. The 2 documents are rarely changed independantly. But yes, there is that overhead of learning the framework, there's the ugliness of a long string of classes, there's the repetition, there's the need to add a comment above elements to describe what they are. Tailwind advises that we should just create another component every time we want to re-use a collection of styles. No thanks, my project explorer is already hard enough to navigate and then I also have to... oh... 'name things'. The 'reusable palate' is overrated, especially when you consider that you often want to re-use 'groups of atoms' instead of just atoms, and so you create an old-school 'class', and there goes all discoverability/predictability that the atomic CSS palate is meant to solve. Tailwind fixes some issues but then introduces new ones. I also don't love HTML+CCS. Styling is messy and imprecise and chok-full of pinch-your-noes hacks.

@@stephenpaul7499Yeah that’s because html was never designed to be styled this way, it was just a way of giving some very basic word processor document like formatting for text documents. Then they layered decades of hacks on top of hacks to get it to do what it does now. If you were starting from scratch, you wouldn’t design html, css, or JS the way they are. It’s long past time to do a hard reset on how websites are encoded. WASM is a good start but you lose out on standard APIs doing a lot of lifting for you so you have to download large binaries to get a framework onto the client.

⁠​⁠​⁠@@stephenpaul7499As for your point about Tailwind fixing some issues then making new ones to replace them, it’s because it’s an extreme in the opposite direction. There’s no perfect solution but a better solution is a combination of well named classes and utility classes which group multiple properties. In rare cases you can do single property utility classes but the. You’d want to have them refer to variables so they could be used in other classes to minimize the use of simple utility classes to elements that don’t already need a class. If it does need a class and the property from a utility class or two, just use the css variables. This is a good balance of abstraction, not needing to give everything a name or rely on complex selectors, and keeping the actual values in a single place.

You can change them 🙂

The reason tailwind.config.js exists. 😬

⁠​⁠@@SarahDayanDevThat’s not fun, really not fun in Bootstrap where the grid classes are named and understood by the set values. Which means changing them can make some meaningless

How is using utility classes f’ing up html different from using ‘semantic’ classes? Or what is the better alternative?

Watch the video rather than just reading the title before commenting in the future.

@@JoepKockelkornYou end up with lots of classes. The counter argument is that it’s still 20-60% less code than inline styles and you still get a modicum of abstraction, but for non-trivial layouts that require elements to have tons of classes, then those can change with media queries, it can get messy. Basically if you’re regularly doing significant changes to your layout, utility classes can save a lot of time. If you do a big overhaul once every several years or more, it’s probably not going to save much vs the cognitive overhead, especially as the html is likely to have to change as well and if you’re changing everything then and new css is available too, you’re probably more or less starting from scratch and the benefit of faster refactoring becomes irrelevant.

This is the most confusing part of the talk for me: `.clearfix` is a utility class, but it is not atomic. if you make it atomic, it would be this `.after:table.after:clear-both.after:content-['']` (i am not a tailwind expert, this is just an example to illustrate the point, not the actual classes). I think this section would lose some viewers because it is kind of off topic.

It’s evident you’ve not used it if you think it’s bloated. Tailwind only outputs what you use.

Wdym? Inline styles are the fastest way for a client to load css :)

@@SaroVerhees Do your own research on the HTML protocol purpose, user agents, external CSS, and caching.

because it is not an issue anymore, its just an ”issue” now that people for some reason still love to complain about like an old girlfriend.

@@KristianTheDesigner This substantiates the point. The same "developers" who are obsessed with performance, memory usage, file sizes, and optimized large applications have 0 issue with unnecessarily bloated and poorly structured HTML shipped over browsers, and call folks "boomers" and "old girlfriend" 🤔🤷‍♂.

@@mrdmajor Also I still prefer CSS, but I don't call people who like tailwind idiots :)