Yes, fotolog.com doesn't exist anymore but I would gladly elaborate. (full explanation here: http://minid.net/2019/04/07/the-css-utilitarian-methodology/)
resume: why go with an OO architecture, when you can use inmutable classes and never again repeat the same properties in your CSS files. In the end, you end up developing faster and you can mantain code easily without having to build the entire UI arquitecture in the CSS. CSS was created to separate style from the content, but also, because back then, HTML wasn't built like we do today with frameworks. Now that we use reactive HTML we can just print inline CSS, but that is a problem, so the functional CSS comes better.
It never scaled terribly well in its original state, and with every iteration became more bloated, so we came up with methods of controlling the sprawl; but imo glut of Modern CSS Implementations and their many and varied permutations not only feel like they are not only fighting against the original concepts, but also against each other.
Which isn't to say they're bad or anything, but simply that CSS is old, everything else has changed dramatically, its probably time we went back to the drawing board.
I've researched all the major newspapers code. From 1996 to 2019 and all of them grew exponentially in size and complexity. It is how you state it: the arquitectures force developers to do bad code. Unmantainable (most devs change jobs, go and read 9k rules) and websites morph over the years carrying lots of legacy code because it takes too much time to fix everything. That's why functional is superior to everything. The problem: all devs are biased with the OO way. It's hard for them to see the benefits.
Yes, functional CSS goes against current best practices, so people write it off without giving it a try. It's a shame as I think it's the best way of doing CSS at this point. For web apps at least.
Is a single purpose class still a class? Not in the conventional sense - In CSS' lexicon it's a group of things, right?
I've got nothing against the approach - it solves a problem - but it's not how CSS was intended to be used.
CSS modules, CSS components, BEM, heck even Sass and Less fall into the same area of trying to wrangle huge unsorted lists of loosely composed attributes into something meaningful.
So if there is a requirement to bend the rules, the problem is with CSS itself.
Heck, even at the most rudimentary level of organising your CSS falls foul - the accepted best method for sorting attributes within a selector anybody seems to have come up with is alphabetical, which feels weird because it weaves layout, typographical and aesthetic behaviours. Why alphabetical? Because nothing else makes much sense, ...so it wins out by default?
I still maintain CSS is a mess from top to bottom.
Please, elaborate on the first statement. In CSS a class is a class, we're not tied to group things. Original CSS wasn't group purpose, mainly due the lack of properties, you could see more single or a couple of properties per class.
I'm taking about classes with an enforced 1:1 relationship with a DOM node, via a unique computed className.
Since there is no requirement for a cascade for this, you've effectively made an ID out of a class.
All the reasons styling off IDs isn't ideal in the traditional CSS metaphor still apply, specificity, verbose stylesheets, etc. But now it's defined as a class too.
I would not call them "best practices" anymore, since those practices only bring a notable decrease on loading, rendering and painting performance. As well a bloated architecture in the short term and a huge file size.
