If you're afraid some random other CSS may come in and ruin your existing classes, you've got other problems. In Javascript I can override random functions in prototypes and leave you to deal with it, but that doesn't mean you should program as if I might.
I've become accustomed to writing SCSS rather than CSS to make generating properly scoped components easier. It saves a lot of declarative repetition when all I want is to style the first and last spans of a div tagged with a certain class while also styling the other components inside the div. I know there are many advanced features in CSS generation libraries but this is all I really care about.
I'm a strict believer in separation of concerns on the web. Not just because it produces cleaner code, but also because it makes custom user styles easier to accomplish.
That said, custom tags are an elegant solution I haven't really considered yet. I found out about them when I couldn't really rely on browsers supporting them and have ignored them ever since. I think they're probably the best of both worlds, though I expect many HTML generation libraries to choke on them.
Custom elements are very well supported today! I’d encourage you to spend more time with them!
Modern devices are pretty fast though, so maybe it's not an issue - but I know in the past the cost of doing CSS rule evaluation has been a problem.
I'm more wary about this than I used to be since someone managed to accidentally cause tsc to need multiple seconds to compile a single file by making a small change to a type definition. Big O still can bite you!
some other CSS can come along
and co-opt what big means
Yes, if someone would redefine "card", that would be a problem. That's why this "base class" should not be as short as just "card" but rather "userInfoCard" or something like that.
some other CSS can come along
and co-opt what big means
Author goes on to show how to give them parameters, news at 11. ;-)
I wrote a bit about this problem from the perspective of a clojure and clojurescript developer on my blog. https://drewverlee.github.io/posts-output/2021-8-26-css-opti...
The reason, clojure and clojurescript is relevant is those programming languages can easily compile to css, allowing users to easily add pl features that don't exist in css and not force devs to learn the same concepts twice. It can do this becuase as a lisp, turning clojure native hashmaps into classes (or attributes if you prefer) is like pouring water into a container. We numerous libs to do this in the clojure ecosystem, here is a reddit discussion around the newest one: https://www.reddit.com/r/Clojure/comments/w56tg8/shadowcss_c...
Though i would personally opt for the slower page perf and faster dev performance of just using cljs compiled to inline-styles solution, as i suggest in my blog.
Of course there might be performance benefits to coding at the lower css level directly, but on average that's not a good tradeoff for most teams i have worked on. s
On top of that, a strange attitude: apart from the embarrassing argument that "old" technology is bad, the author assumes that HTML is written by hand, apparently by a team of monkeys taking pride in the intensity of their fuzz testing, rather than generated correctly from templates.
Hence the emphasis on defensive coding and on treating easily fixed mistakes as a disaster (as if web developers routinely edited pages in production without testing).
It’s true that as systems scale often templating systems are introduced to alleviate writing html, but these systems are rarely complete which means developers - meeds unmet - need to “drop down a layer” and in that should be set up for success not failure. Having a design system that use brittle underlying primitives will not set developers up for success.
However, there's a foot-gun in the first paragraph. In the mid-nineties practically no one was using "black and white" monitors. I remember a few ancient DOS test-only stations at a school and a single amber-monochrome hardware terminal (connected to big-iron at work) in that time period. Everything else doing real work was Win3.1 and color Mac by then. Netscape browser had already dropped and was popular; no one was using it in black and white.
This was in California. May be slightly ahead, and I'm not taking developing countries into account. But color was so compelling it was already not-uncommon by the late 80s.
Data-attributes on html elements are only for JS behavior in my usage, and CSS classes are for styling.