[vim-guru]

CSS has become significantly more user-friendly than in the past, with most browsers now behaving consistently. It's worth learning as there is no build step involved, and it avoids cluttering your markup with excessive code.

You could opt to use style attributes directly within your HTML. Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar methods. Is it just to save a few keystrokes? Using style attributes even seems more straightforward since it doesn't require translating code in your head.

I simply don't see the appeal.

[morbicer]

There's a bunch of things you can't do with style attributes, just to pick a few:

- Pseudo-classes (e.g., :hover, :focus)

- Pseudo-elements (e.g., ::before, ::after)

- Media queries

- Keyframes and animations

And the DX in a larger project isn't great either.

On the other hand, this upcoming standard is a great addition for collocating styles https://developer.mozilla.org/en-US/docs/Web/CSS/@scope

[nilslindemann]

https://developer.mozilla.org/en-US/docs/Web/CSS/@layer also solves a lot of problems.

[jeanlucas]

Indeed, it also solves a lot of problems

[jitl]

These days tailwind is often paired with a component abstraction system that takes place of css classes as an abstraction system. Component abstraction achieves an even more powerful separation of semantics from styling, compare:

    <h1 class=hero>Cool page</h1>

vs:

    <Hero>Cool page</Hero>

In both cases you need to go find the “hero” abstraction, but in component world we are also abstracting over the HTML tag name in addition to whatever styling stuff.

When it comes to defining the “stylistic detail” in either case, it has been separated from the “content” which is our page source file. I am happy to pay a build step to get better separation of concerns - content from presentation.

[aembleton]

> I simply don't see the appeal.

- Not having to name CSS classes

- Easier to read as it's inline with the rest of your HTML

- Standardised way of naming so that everywhere uses the same conventions

- Not having to manage a separate file and remove unused components

- Being able to use media queries, which I couldn't do in a style tag

- No risk of changing a class that is used elsewhere. CSS has global scoping which has its benefits but is risky.

[agos]

no, a single html attribute containing "relative before:absolute before:top-0 before:h-px before:w-[200vw] before:bg-gray-950/5 dark:before:bg-white/10 before:-left-[100vw] after:absolute after:bottom-0 after:h-px after:w-[200vw] after:bg-gray-950/5 dark:after:bg-white/10 after:-left-[100vw]" is not "easier to read" (example taken at random from the Tailwind homepage)

[oneeyedpigeon]

Just viewing the source of the Tailwind homepage breaks me out in a cold sweat. And then there's:

    > console.log(document.querySelectorAll("body > script").length)
    27

[aembleton]

Easier to figure out what to change without affecting other HTML components, though.

[superq]

Individually applied styles kinda defeats the purpose of cascading style sheets though.

As someone who's quite conversant with regular CSS, I really did like the ease of applying whatever style I wanted right in the code without needing to "worry" about whether this div is a "panel" or a "hero" or whatever, but it really does tend to make a huge mess of my HTML in very short order.

[8n4vidtmkvmk]

Have y'all not heard of css modules or BEM?

[jitl]

pointless make-work compared to inline-styles-like workflow like tailwind, if you have a component framework

[8n4vidtmkvmk]

You might like Styled Components then, if you're using React anyway. Not sure if there's similar systems for other frameworks. I don't consider it pointless make-work to develop a consistent stylesheet to use throughout your app though.

[presentation]

Use PandaCSS, the result is similar but the syntax is a readable object instead of… that

[skeletal88]

The problem is that with bootstrap I have card, table, etc. With tailwind I have an unreadable alpabet soup when I am not a designer but a developer and am not familiar with tailwind.

[Ralfp]

And then you build on that, and you have card-alert, card-message card-message-small, card-body-alert, card-body-message, card-form, card-login-form together with extra sass variables for them.

And then you ask "why not just have variable for each component, not each component's style?" and this is where tailwind steps in.

[gedy]

I greatly agree with you, but should mention that there is DaisyUI which is a Tailwind plugin that adds these for you. It seems inspired by Bootstrap and others: https://daisyui.com/

[mablopoule]

This is the big one for me. In any big enough or unfamiliar frontend project, my go-to way to explore the codebase is to launch the front-end, and use the inspector to check the elements, and then search-back in the codebase the relevant classes to see what page/component display that, and how does it fetches the data.

If there is only an alphabet soup, I no longer have a simple set of classes I can grep the codebase with to quickly find the relevant components.

[yurishimo]

This is just not true. You can absolutely grep the soup (I do it daily). Most UI components share a lot of common baselines but include a specific modification for use in place (often a color or extra spacing). That means most of the time, the entire class string is unique to that element, even if the classes themselves are not. At most, you might have a couple of duplications, but then you should probably be looking at a template level component if the functionality is related.

`mx-4 py-2 rounded-xl shadow bg-green-500` is just as easy to global-search for as `notice--success`

[jitl]

Use the component library’s inspector/devtools to identify components. Eg in a React app, look at the React component tree rather than the DOM tree

[lawn]

> Easier to read as it's inline with the rest of your HTML

I really don't think a big blob of text with a bunch of unnamed divs is easier to read.

The styles night be easier to find but they're absolutely not easier to read.

[benjiro]

> - Not having to name CSS classes

Most websites are maybe 20 components and localized pages. Not exactly that hard to name and keep constant. Can not think of names, just ask one of the AIs.

> - Easier to read as it's inline with the rest of your HTML

Only if you do a few styles. The moment you have mobile + desktop + dark/light you start to leave lines half a mile long.

> - Not having to manage a separate file and remove unused components

Counterpoint: Components/templates are still the same hell to manage.

> - Being able to use media queries, which I couldn't do in a style tag

CSS ... literally the bread and butter.

> - No risk of changing a class that is used elsewhere. CSS has global scoping which has its benefits but is risky.

Counterpoint: You will end up with styles that are applied to parts, then copied, forgotten to change, and then have a mix of styles that conflict with each other.

And you do not use global scoped CSS, but localized per page. All you need is local CSS + a single parent id/class and voila. Local scoped will not mess with global. Do not do stupid stuff like button { style style style }. No, make global scoped iButton, so you never run into the issue off having parental styles doing funny things to child styles.

Let me introduce our lord and savvier called Nested CSS + Named CSS tags ... Reusable, standardized, ...

Tailscale is frankly a solution for front end JS frameworks, and less for any server rendered html. Use local CSS for html pages that are really local. No need to make global CSS for price cards that you only use on one page. But if something is used over multiple pages, buttons, ... that is global. Simple, no?

Ironically, i am in the process of actually removing Tailscale everywhere because the recent 3 > 4 upgrade screwed so much up. What stayed good? My actual CSS nexted/tag components that i never.

That is one of the issues with frameworks in general, etc, things between versions can really mean a lot more work vs just having everything "basic".

I feel a lot of issue that people have with CSS are more related to not having a proper understanding about CSS, and ignoring some basics. Like do not style base tags. Use nested + custom naming tags, local css + a local id/css and you have no issue with overlap. Best of all, you gain the ability to make easier reusable components as your CSS are the components, not some JS/... whatever call you need to do to render something. It gets messy fast if your breadcrumbs is a components with items, and you need to change something later on. But if its a basic breadcrumbs{} css, adding feature is just a matter of adding naming.

Trust me, took me years to get out of this mindset (and it helped that CSS evolved a lot but most people do not even realize that CSS today != what they know/grew up with)

[65]

Big one: Way smaller CSS bundle size.

[tipiirai]

It's because we've normalized React and tight coupling. Styling belongs to components, not in design systems. I feel the JavaScript-first engineering ecosystem needs brave new design-led companies, who see the power of modern CSS and systematic design.

[itzami]

> Historically, we avoided this to maintain a separation of concerns, but it's puzzling why some prefer reintroducing similar methods. Is it just to save a few keystrokes?

In bigger projects, if we start looking at the amount of files one has to deal with, Tailwind becomes very appealing. We've went through the regular `.css` route but then you have weird names, and, potentially, duplications or even conflicts. `css modules` is an option but you've now essentially duplicating the number of files that you have for each component / page. `sass` or `less` essentially bring the problems from `css modules` and regular `.css` into one.

I don't inherently like or dislike Tailwind (although I very much started by absolutely disliking it) but you feel its value in a project with 200+ files composed of components and pages

[dbbk]

You're seriously advocating for inline styles in the year 2025, it does not surprise me you are confused.