4 ms·

This is pretty common advice and not a point of contention for front-end folks. > if you're only going to be using the style once on a page Herein lies the th

This is pretty common advice and not a point of contention for front-end folks. > if you're only going to be using the style once on a page Herein lies the the problem. You now can't use that header anywhere else, meaning the it's non-composable. You end up writing less, and more maintainable CSS when you treat components as immutable and composable. Most people consider the additional readability of separating out the `id` to be negligible.

BinaryIdiot 11y ago
> You now can't use that header anywhere else, meaning the it's non-composable. You end up writing less, and more maintainable CSS when you treat components as immutable and composable. You can use that header on any page and you're not going to re-use it on the same page. Why does it need to be "compose-able" at all? Either way this is a silly argument because there is no problem here. You have a set of CSS styles you want applied to an element on the page that will never have a copy, etc? You can use ID or Class and you can even swap them with the same level of difficulty. This is entirely a non-issue no matter what way you go; it's more of a style thing.
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 ago
  But 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

BinaryIdiot 11y ago

> You now can't use that header anywhere else, meaning the it's non-composable. You end up writing less, and more maintainable CSS when you treat components as immutable and composable. You can use that header on any page and you're not going to re-use it on the same page. Why does it need to be "compose-able" at all? Either way this is a silly argument because there is no problem here. You have a set of CSS styles you want applied to an element on the page that will never have a copy, etc? You can use ID or Class and you can even swap them with the same level of difficulty. This is entirely a non-issue no matter what way you go; it's more of a style thing.

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 ago
But 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