3 ms·
It's not composable if you only write raw CSS, they're perfectly composable via @extend's and @include's, e.g. #login-widget { @extends widget(); }
by Joe8Bit 11y ago
It's not composable if you only write raw CSS, they're perfectly composable via @extend's and @include's, e.g.
#login-widget {
@extends widget();
}
Best of both world's, the semantic meaning of id's with the composability of classes, plus, the compiler is smart enough to reduce duplicity to it's bare minimum
- nilliams 11y agoBut it's still not a good idea to use IDs. Why not: .login-widget { @extends widget(); } The specificity that ids bring alone are good enough reason to avoid them forever. They're a sledgehammer that can pretty much only be overridden by `!important`. If that somehow sits fine with you perhaps consider the rule the rest of the software world has accepted long ago -- 'this code will be changed'. The fact you think you will really only have one of these things on a page at once (hence making it suitable for an ID) ... that WILL change. There will come a day when you have a login-widget in your sidebar, yet at some obscene last-minute moment the customer will demand a dedicated login page too, your developers will want to use your base template (which has your login widget visible in the sidebar) creating 2 login widgets on-page, cursing your assumption that you thought you knew better. Ignoring that, you could forget my example above (I'm sure there's a way you could dismiss it as contrived) and learn a lesson from the OOP crowd and just never write singletons [0] ever. It's just a really bad assumption to think you'll only want one of a thing. [0] https://en.wikipedia.org/wiki/Singleton_pattern https://en.wikipedia.org/wiki/Singleton_pattern