Cool but also reminds me why I use inline styles for everything. I don't want to fiddle with selectors. I want to put the styling right on the element.
In a large app you often can’t easily find all of the html. It’s less work by far to ensure you can find all of the CSS though.
And when the company decides to rebrand and change the color scheme for the whole app, which they will at least half the time, you’ll be glad not to be playing whack-a-mole. Problems that aren’t done when you think they’re done create a lot of friction with the rest of the org. Open ended problems cause engineering to look incompetent. The cost of that problem is immeasurable, and doubly so in a bad economy.
> In a large app you often can’t easily find all of the html.
Which is often a warning sign of a bad design. The times I've dealt with systems that bury a certain piece of text in either a content file or a template or the database...
> It’s less work by far to ensure you can find all of the CSS though.
Hmm... depends. I've seen things like React embedding the CSS directly in with the markup and component logic etc. So this hasn't necessarily gotten any better — in fact, a site consisting JUST of html files would probably be easier to find CSS in even if it's all added via inline style attributes.
There are no clean designs on a large team. Anyone who tells you otherwise is selling something.
Zealots provide solutions that cannot possibly survive contact with actual humans. The rest of the team talks about them behind their backs.
> I've seen things like React embedding the CSS directly in with the markup and component logic etc.
You were talking about bad designs? Embedded styling is not Cascading Style Sheets. It’s embedded styling. There’s no sheet, and no cascade.
Nothing is free, and few things are easy. There are lines that are easier to maintain in practice than others, and separation of CSS is one of the former.
It’s not needless pedantry. Calling it CSS is using a crescent wrench as a hammer and calling it a hammer (a running joke on r/tools). You’ve missed the entire point and someone needs to remind you - and everyone listening in - what the point was.
We had in-line style before we had CSS. We are going back and nobody remembers why we’ve had CSS for twenty years? Read some history.
We're not in 2003, though. If you're working on a project with somebody and you insist they refrain from calling the contents of a style attribute CSS because it wasn't always technically CSS, nobody will thank you.
Edit: actually, even when I was working with CSS in 2003 (IIRC, we absolutely were using separate CSS files then), this attitude would have been unhelpful, to say the least.
With components. Same thing as when isolating styles to a component in various frameworks (e.g. Single-File Components in Vue) but instead of its own style tags I just put the styling directly in the HTML.
modern JS has a bunch of half-assed scenarios for solving this problem that allows you to solve almost everything CSS did a few years ago and helps keep people stuck in ineffective legacy ways of doing it because all their code would have to be rewritten to use straight css.
I know because every place I've worked in the last few years uses some form of CSS in JS.
FWIW, these are useful for more than styling. I don't do any front-end dev work, but I use these regularly in selenium to find components in the page to interact with.
And when the company decides to rebrand and change the color scheme for the whole app, which they will at least half the time, you’ll be glad not to be playing whack-a-mole. Problems that aren’t done when you think they’re done create a lot of friction with the rest of the org. Open ended problems cause engineering to look incompetent. The cost of that problem is immeasurable, and doubly so in a bad economy.