4 ms·

Ignore ID's? What? The point of an ID is it is a selector used to identify only one element on a page - A header or a footer for example. You can't replace that

by jjar 11y ago

Ignore ID's? What? The point of an ID is it is a selector used to identify only one element on a page - A header or a footer for example. You can't replace that semantic meaning with classes, if you're only going to be using the style once on a page then change it to an ID. Example: <div class="header inset aboutUs"> or <div id="header" class="inset aboutUs"> The difference is the second option shows at first glance what the element is supposed to be representing to someone reading your code.

cng2 11y ago
When managing css in large projects, specificity is your worst enemy. ID are not styled, if there are any. If your worried about being semantic for the header and footer, use the html5 header and footer tags.
- BinaryIdiot 11y ago
  > When managing css in large projects, specificity is your worst enemy I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. This doesn't mean I encourage using IDs all over the place; they should only be used when there can be a single version of that element on the page. But being specific also means using the cascade (e.g. html > body > div.mydiv versus just .mydiv).
  - tomjakubowski 11y ago
    > I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. You can handle 99% of use cases for specificity just nesting classes. Using IDs to settle specificity is the same as bringing an ICBM to a Nerf gun fight. When I was doing front-end development, I spent more time fighting back against overly specific CSS, thanks to IDs (and fellow developers who just sprinkled `important!` on everything until it worked), than struggling because I couldn't get specific enough without IDs.
    - BinaryIdiot 11y ago
      > You can handle 99% of use cases for specificity just nesting classes. Nesting classes can get really messy and I'm not sure that really makes sense to do in "99% of use cases" if the goal is to make something specific. Mixing classes allows you to apply multiple styles onto a single element which can be really handy but using that as the way to target a specific, single element means you can't re-use some of those classes in the same way otherwise you run the risk of targeting more than one element in the same way. Specificity should usually be handled through the cascade and / or IDs; that's what they were meant to do. Classes provide buckets of styles as do IDs and both can be used in the same way with IDs targeting only a single element and not a compose-able one. Ultimately you can specifically target in CSS a variety of ways. Outright saying one way is just wrong or "[an] ICBM" kinda ignores the use cases of the various ways to do it to attempt to force a single answer where I do not think a single answer is satisfactory.
  - martin-adams 11y ago
    I find the opposite is generally the case. I've maintained many projects which were highly specific and therefore ridged to enhancing. I try to reuse some style to only find it doesn't work when placed somewhere else in the HTML. Having too generic styles is also a problem though. E.g. styling a label element on the assumption it's in a form can be frustrating. It's all about the right balance and styling specifcally what you mean, not the specific structure of the HTML.
  - cng2 11y ago
    When running a large project, there is never just a single version of a ui element. For example, using media queries, different resolutions, zoom, and print. Or if write your css in oocss with separation of concerns. Being less specific allows your css to be more manageable to change in many different situations. In complicated layouts, cascades are very non-friendly. Styling elements directly also has very high specificity.
    - BinaryIdiot 11y ago
      > When running a large project, there is never just a single version of a ui element. For example, using media queries, different resolutions, zoom, and print. Not sure why you'd make such an absolute claim. When you say single version are you saying single html element or single CSS definition? If the former then I disagree (headers, footers, main containers of content, etc), if the latter then I don't understand how this would be the case. In HTML IDs are limited to one specific element but you can refer to it as many ways as you want in CSS which means you can use different media questions, handle resolutions, print, etc. So I'm not really sure I understand your point. > Being less specific allows your css to be more manageable to change in many different situations. In complicated layouts, cascades are very non-friendly. I've worked in a lot of really large projects and I'm not sure how little to no specificity could be more manageable due to side-effects. Ultimately you're going to need a mixture of specific and non-specific styling so arguing whether you should be more or less doesn't really make sense to me; just use the right level of specificity for the job at hand. If you have a page with specialized content you might want to be more specific there to not mess up another page. If you have a lot of re-usable components you probably want less.
lstamour 11y ago
Except in many cases, an ID can be replaced these days with an HTML5 tag that can be re-used, or with other attributes, e.g. aria ones, that mean more. And you might run into a circumstance where you have to repeat the header or footer -- perhaps you're allowing someone to edit the header or footer of your site and you want to do so in the middle of the page? Or you want to perform a complex animation that would require having multiple elements on the page at the same time. IDs ultimately are more brittle, and they don't do anything to enforce that they're only used once on a page. Their best use appears to be for hyperlinks or perhaps actual ID numbers (e.g. JavaScript) and not much else these days, if you're being consistent.
chrislloyd 11y ago
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

by jjar 11y ago

cng2 11y ago

When managing css in large projects, specificity is your worst enemy. ID are not styled, if there are any. If your worried about being semantic for the header and footer, use the html5 header and footer tags.

BinaryIdiot 11y ago
> When managing css in large projects, specificity is your worst enemy I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. This doesn't mean I encourage using IDs all over the place; they should only be used when there can be a single version of that element on the page. But being specific also means using the cascade (e.g. html > body > div.mydiv versus just .mydiv).
- tomjakubowski 11y ago
  > I couldn't disagree more. The more specific you are the less side affects you'll encounter in the rest of your project. When a project gets incredibly large if your styles are NOT specific you're going to run into a lot of unintended consequences. You can handle 99% of use cases for specificity just nesting classes. Using IDs to settle specificity is the same as bringing an ICBM to a Nerf gun fight. When I was doing front-end development, I spent more time fighting back against overly specific CSS, thanks to IDs (and fellow developers who just sprinkled `important!` on everything until it worked), than struggling because I couldn't get specific enough without IDs.
  - BinaryIdiot 11y ago
    > You can handle 99% of use cases for specificity just nesting classes. Nesting classes can get really messy and I'm not sure that really makes sense to do in "99% of use cases" if the goal is to make something specific. Mixing classes allows you to apply multiple styles onto a single element which can be really handy but using that as the way to target a specific, single element means you can't re-use some of those classes in the same way otherwise you run the risk of targeting more than one element in the same way. Specificity should usually be handled through the cascade and / or IDs; that's what they were meant to do. Classes provide buckets of styles as do IDs and both can be used in the same way with IDs targeting only a single element and not a compose-able one. Ultimately you can specifically target in CSS a variety of ways. Outright saying one way is just wrong or "[an] ICBM" kinda ignores the use cases of the various ways to do it to attempt to force a single answer where I do not think a single answer is satisfactory.
- martin-adams 11y ago
  I find the opposite is generally the case. I've maintained many projects which were highly specific and therefore ridged to enhancing. I try to reuse some style to only find it doesn't work when placed somewhere else in the HTML. Having too generic styles is also a problem though. E.g. styling a label element on the assumption it's in a form can be frustrating. It's all about the right balance and styling specifcally what you mean, not the specific structure of the HTML.
- cng2 11y ago
  When running a large project, there is never just a single version of a ui element. For example, using media queries, different resolutions, zoom, and print. Or if write your css in oocss with separation of concerns. Being less specific allows your css to be more manageable to change in many different situations. In complicated layouts, cascades are very non-friendly. Styling elements directly also has very high specificity.
  - BinaryIdiot 11y ago
    > When running a large project, there is never just a single version of a ui element. For example, using media queries, different resolutions, zoom, and print. Not sure why you'd make such an absolute claim. When you say single version are you saying single html element or single CSS definition? If the former then I disagree (headers, footers, main containers of content, etc), if the latter then I don't understand how this would be the case. In HTML IDs are limited to one specific element but you can refer to it as many ways as you want in CSS which means you can use different media questions, handle resolutions, print, etc. So I'm not really sure I understand your point. > Being less specific allows your css to be more manageable to change in many different situations. In complicated layouts, cascades are very non-friendly. I've worked in a lot of really large projects and I'm not sure how little to no specificity could be more manageable due to side-effects. Ultimately you're going to need a mixture of specific and non-specific styling so arguing whether you should be more or less doesn't really make sense to me; just use the right level of specificity for the job at hand. If you have a page with specialized content you might want to be more specific there to not mess up another page. If you have a lot of re-usable components you probably want less.

lstamour 11y ago

Except in many cases, an ID can be replaced these days with an HTML5 tag that can be re-used, or with other attributes, e.g. aria ones, that mean more. And you might run into a circumstance where you have to repeat the header or footer -- perhaps you're allowing someone to edit the header or footer of your site and you want to do so in the middle of the page? Or you want to perform a complex animation that would require having multiple elements on the page at the same time. IDs ultimately are more brittle, and they don't do anything to enforce that they're only used once on a page. Their best use appears to be for hyperlinks or perhaps actual ID numbers (e.g. JavaScript) and not much else these days, if you're being consistent.

chrislloyd 11y ago

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