#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 #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 .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.