I have said since SCSS introduced the idea that if you 'need' it you probably either don't know how to group selectors appropriately, don't know how to search/replace, or simply have too much CSS for your own good.
But to be fair, I'm the guy who says 90%+ of websites out there have no legitimate reason to use more than 48k of CSS in one file per media target... and since most sites don't even use proper media targets, well...
Just like how most websites have no real excuse for the dozens or even hundreds of K of markup they waste on 8 to 16k of text content and dozen or so content images.
Also that 48k number is me Mr. Scott-ing my estimates; figuring out how much I really need, then doubling it as a safety margin.
I could see how it might be useful if you have far too many different elements of different names to make selector grouping difficult, or if you had hundreds of K of CSS -- but those are both things I wouldn't do in my development process in the first place.
It's part of why all this CSS pre-processor nonsense feels like a complete waste of time and effort to me, and offers no usability or workflow improvements for how I go about doing things. When people talk about any alleged "advantages" I look at what they're doing, look at what I'm doing... and genuinely have no clue what they're talking about. It's -- from my perspective -- more work, more time, and indicative that if they somehow think it is "easier' then there is something wrong with their methodology and the resultant code.
Which is why more often than not my advice in those cases would be to pitch it all in the trash and to start over; since it would be faster -- for me at least -- to rewrite it from scratch than it is to try and fix the messes these tools get people into.
So much of it just reeks of not leveraging semantics or selectors properly, trying to compensate for the "specificity hell" created by the BEM or Framework "endless pointless classes for nothing", and a general lack of understanding inheritance or even the "cascading" part of Cascading Style Sheets.
As I've said many times many places the past decade, maybe, just maybe -- and I know, crazy idea -- if people would stop wasting 100k of markup, 250k of CSS, and a megabyte of JavaScript spanning two dozen or more files on doing the job of 16k of markup, 24k of CSS, and 24k of scripting in three files, maybe they wouldn't be throwing more work into the mix with this type of nonsense.
But no, that might involve actually learning how to use HTML and CSS before making up your mind on if those tools are worth using.
Jason Knight
The less code you use, the less there is to break
I have said since SCSS introduced the idea that if you 'need' it you probably either don't know how to group selectors appropriately, don't know how to search/replace, or simply have too much CSS for your own good.
But to be fair, I'm the guy who says 90%+ of websites out there have no legitimate reason to use more than 48k of CSS in one file per media target... and since most sites don't even use proper media targets, well...
Just like how most websites have no real excuse for the dozens or even hundreds of K of markup they waste on 8 to 16k of text content and dozen or so content images.
Also that 48k number is me Mr. Scott-ing my estimates; figuring out how much I really need, then doubling it as a safety margin.
I could see how it might be useful if you have far too many different elements of different names to make selector grouping difficult, or if you had hundreds of K of CSS -- but those are both things I wouldn't do in my development process in the first place.
It's part of why all this CSS pre-processor nonsense feels like a complete waste of time and effort to me, and offers no usability or workflow improvements for how I go about doing things. When people talk about any alleged "advantages" I look at what they're doing, look at what I'm doing... and genuinely have no clue what they're talking about. It's -- from my perspective -- more work, more time, and indicative that if they somehow think it is "easier' then there is something wrong with their methodology and the resultant code.
Which is why more often than not my advice in those cases would be to pitch it all in the trash and to start over; since it would be faster -- for me at least -- to rewrite it from scratch than it is to try and fix the messes these tools get people into.
So much of it just reeks of not leveraging semantics or selectors properly, trying to compensate for the "specificity hell" created by the BEM or Framework "endless pointless classes for nothing", and a general lack of understanding inheritance or even the "cascading" part of Cascading Style Sheets.
As I've said many times many places the past decade, maybe, just maybe -- and I know, crazy idea -- if people would stop wasting 100k of markup, 250k of CSS, and a megabyte of JavaScript spanning two dozen or more files on doing the job of 16k of markup, 24k of CSS, and 24k of scripting in three files, maybe they wouldn't be throwing more work into the mix with this type of nonsense.
But no, that might involve actually learning how to use HTML and CSS before making up your mind on if those tools are worth using.