clarkwinkelmann Just to mention it, we are using Less and compiling it at run time, so extensions can do a bit more than just append CSS, including completely override core rules
Perfect, with the way it's currently implemented in Flarum it's easy to fit this architecture in, even at a extension level. Applying these principles would actually make your LESS setup much more powerful as you prevent clutter and "specificity hell" completely.
It seems harder to find information on it now than when I first read about it. Probably thanks to the e-learning platform that's offering a paid course
Lucky for us, this video is all you need, and some practice. InuitCSS is a project boilerplate that follows this setup, if you prefer to see some code. There's a stylelint plugin now to ensure proper application, although I haven't used it, so I couldn't tell you for sure if it is good.
RSCSS' naming conventions perfectly complement the way Flarum uses Mithril components
https://rscss.io/components.html
Both methodologies can be used together. Apart from its naming conventions, RSCSS also has a certain application of SoC where cosmetic CSS is split from positioning properties that I think would benefit Flarums extensibility. This also fits in nicely with ITCSS.
All in all I think it would provide a cleaner, smaller, organized, manageable CSS codebase, more efficiently built, highly extensible, using both CSS and LESS' full power. What I imagine it would require is some additions to the Flarum docs, applying layers in your LESS compilation and, at this point, a bunch of refactoring.