That's a good point. I'm by no means a HTML/CSS/JS guru but this seems the wrong way around to me. Maybe components that honour the "base" tags e.g. <p>, <h1> etc that the classless stylesheet has defined could be developed (please accept my lack of awareness of those that already do exist).
So instead of a component assuming, it needs to be pointed to the tag you, as developer/designer, require - perhaps via a config parameter. Interesting comment about using SASS to namespace, but then the elegant simplicity of these stylesheets starts to get chipped away IMHO.
I think the issue there is that there are thousands of available CSS properties. Without assumptions, every single one would have to be specified for every single class. Imagine the same for JS or any other language, you would have to re-write the standard lib if you couldn't rely on it.
I’ve been structuring my styles with CUBE.css (https://cube.fyi) for a few months now and a classless approach fits the composition piece very well.
Example: In a particular context (say the <h3> tag in the <header> of each <section>) I almost always want a default style. On changing that style, I don’t want to modify markup. In future, when adding more pages, I don’t want to remember the particular combination of css classes that I’ve used elsewhere. When a particular face out is different (this <article> is a modal) then I can add meaningful class names to convey intentions.
From a practical perspective, I’ve found it to give me 90% of the UI I want at 10% of the cost.
OT: Do you by chance have any pointers on where to stay up-to-date on modern frontend development?
As a dev I've been out of the frontend game for a few years, when BEM was widely used. When I started working more on frontend again a few months ago I tried to look around for developments in terms of methodologies (e.g. "is there a 'next BEM'?"), but didn't really find anything and didn't even know where to look. Even just hearing about newer aproaches like CUBE would be nice, regardless if they end up being fit for production usage.
I'm not sure what other advice to give. A lot of this was collected over time in response to frustrations I felt around the direction front-end has been moving in (css-in-js, atomic css etc.) and looking for people writing criticisms of it.
It keeps the HTML about as clean as it can be, more often than not. Many of these classless CSS frameworks you can substitute arbitrarily without ever changing the markup. Which can be very useful for small static sites with hand-edited HTML like the Old Web people used to bake.
I certainly appreciate that "Old Web" feeling from the time before CSS when Browser default/built-in stylesheets were more opinionated and tried to do nice things without forcing you to do all of your styling by hand. Classless frameworks can feel like a good throwback to that era, and a useful compromise from today's browsers' awful default styles and the sorts of CSS frameworks that include everything and a kitchen sink and are designed much more for "apps" than just a clean document full of information.
From the few I know, the classes are mostly shortcuts to css features (container are one of the exception), which are of course defined as custom classes but they don't create a new layer of (name,meaning) unlike what I assume we were all doing.