7 ms·

Looks great. However, I've never really understood this sort of approach: <ul class="collection"> <li class="collection-item">Alvin</li> <li cl

by pan69 12y ago

Looks great. However, I've never really understood this sort of approach: <ul class="collection"> <li class="collection-item">Alvin</li> <li class="collection-item">Alvin</li> <li class="collection-item">Alvin</li> <li class="collection-item">Alvin</li> </ul> Rather than assigning a "collection-item" class to each "li", would you not simply style the "li" in the context of "collection"? Bootstrap does a similar thing. Drives me nuts...

weego 12y ago
It's so you don't clobber the underlying styles, otherwise you end up having to reset on top of the frameworks resets and styles on the odd occasion you want one of the collection li's to not have the styles. I tend to agree with you, but I was heavily chastised by lead the front end dev at my last gig for ever directly applying design styles to tag entities as doing it as above is considered best practice at the moment (until the cycle comes around again to another best practice).
- pan69 12y ago
  >> but I was heavily chastised by lead the front end dev at my last gig for ever directly applying design styles to tag entities as doing it as above is considered best practice I'd say, keep it DRY [1]. http://en.wikipedia.org/wiki/Don't_repeat_yourself http://en.wikipedia.org/wiki/Don't_repeat_yourself
  - ahallock 12y ago
    It doesn't violate DRY. The repetition of "collection" is indicating a descendent component: https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md https://github.com/suitcss/suit/blob/master/doc/naming-conve...
    - BinaryIdiot 12y ago
      HTML provides nesting. Nesting indicates it is a descendent component. This would violate DRY.
      - ahallock 12y ago
        LIs are generic containers--the only way to narrowly scope LIs is to use hierarchical selectors, which leads location dependency and specificity issues. The class name creates a scope and you need to apply that to decedent components to enforce the scope. It's DRY within the naming convention, which doesn't mix element selectors with class selectors (or at least rarely).
        BinaryIdiot 12y ago
        > LIs are generic containers LIs are actually kinda special. It's incredibly difficult to create your own LI in, say, web components because of their specialness (at least I've never seen it work in all browsers though there are probably some crazy hacks to get it there (or at least close enough)). > which leads location dependency and specificity issues You have a list of a specific type so you put a class on it. Why would that specific type of list now contain items that can be used in multiple places versus in that specific list and why would they ever be moved from that specific type of list? I don't really understand the issue you're trying to convey.
- bbx 12y ago
  Tell your lead front dev this approach isn't best practice at all. You want one collection li's to not have the style? Use an alternative class on the ul: "collection collection-alt". You want nested li's to not inherit the styles? Use ".collection > li" in your CSS. In any case, assigning a class on each li goes exactly against CSS best practices, because it prevents taking advantage of the inheritance of property values or of advanced selectors.
  - dovel 12y ago
    I dont do this repeating class business but CSS Tricks 'css guidelines' web page says that when you do : '.collection li', it first searches through the page for all 'li's then wittles it down to the ones within the correct parent. Essentially that css selectors work from right to left. So I guess the idea is that classing up the li elements within a parent may be marginally quicker? I have never bothered though. Does anyone know more about this?
    - ddoolin 12y ago
      This is true, actually. They are read from right-to-left. I'm not sure how much extra resources are expended searching this way opposed to the other, though my guess would be the same as yours. It may be worth a benchmark?
    - anton-107 12y ago
      It used to be the issue in the "old browsers", modern browsers optimize the css query selectors to a very high extent, so users probably won't see a difference on any real web page / app
    - vbezhenar 12y ago
      Modern browsers do their best to optimize typical use-cases for CSS selectors and .collection li for sure will be handled optimally. You shouldn't worry about CSS selector performance unless you have to provide good performance for very old browsers or hit specific performance problem. Optimize for humans, not for computers.
- moron4hire 12y ago
  I've come to expect people who criticize others using "best practice" as their "source" are themselves not very good at what they do and are just cargo-culting ideas without any real understanding in underlying principles.
deleted 12y ago
[deleted]
danielmason 12y ago
There's a reasoning behind this. You may not agree with it, but it's good to fully understand the problem it's trying to solve. There are two problems with your suggested approach -- specificity and coupling. The rules of CSS are such that .collection > li is a more specific selector than .collection-item. So if you want a particular item in the list to be red, you can't just give it a class name .warning-item and style against that -- you have to match or exceed the existing specificity. In the simple case, this isn't too bad, but it's surprisingly easy to end up representing deeply nested structures in your CSS which are very difficult to override. The coupling problem is really just a way of saying that it might not be a good idea to describe the specifics of your HTML implementation in CSS. Class names are like an interface. One refactoring I've actually done a lot is switching out lists like the above for a combination of nav and anchor elements. It's great to be able to do that without needing to rewrite all the corresponding CSS, too. These are tools designed to help you manage complexity and increase flexibility, not dogma. If you don't find your HTML needing to change much, or you don't need to make styles overrideable, then YAGNI. Hopefully it makes sense why framework authors, whose work is explicitly designed to be overridden, would choose this approach.
- riquito 12y ago
  Performance is penalized too. Since CSS rules are parsed from right to left and you have probably a lot of "li" tags, the rule would be very inefficient. Of course this doesn't matter in small pages.
  - rimantas 12y ago
    It does not matter in any real life pages.
    - riquito 12y ago
      It did for Trello, to name an example (search for speed in http://blog.trello.com/refining-the-way-we-structure-our-css-at-trello/ http://blog.trello.com/refining-the-way-we-structure-our-css...).
  - 12y ago
CleanCoder 12y ago
SMACSS - Scalable and Modular Architecture for CSS.
yummybear 12y ago
My personal experience is: Using element names instead of class names can be problematic. In some frameworks you may need to use a different element or an element that wraps another element to achieve certain functionality. Some use generic names like "button large" as class names, but, again in my personal experience, it often causes problems. You might have other elements that need to be "large" and may need to be inside a button - but which "large" do you mean. So to keep things predictable, I've adopted the following practices: - Always namespace components. - Always ensure that selectors work even if the child has a wrapper around it. - Whenever possible use classnames instead of element names. And to ensure I don't get tendonitis (not sure if everyone agrees with this): - If possible provide a shorthand for at least the most used components (i.e. "col"/"col-i" for "collection"/"collection-item"
EugeneOZ 12y ago
What will you do when you need div.a list instead of ul.li?

by pan69 12y ago

weego 12y ago

It's so you don't clobber the underlying styles, otherwise you end up having to reset on top of the frameworks resets and styles on the odd occasion you want one of the collection li's to not have the styles. I tend to agree with you, but I was heavily chastised by lead the front end dev at my last gig for ever directly applying design styles to tag entities as doing it as above is considered best practice at the moment (until the cycle comes around again to another best practice).

pan69 12y ago
>> but I was heavily chastised by lead the front end dev at my last gig for ever directly applying design styles to tag entities as doing it as above is considered best practice I'd say, keep it DRY [1]. http://en.wikipedia.org/wiki/Don't_repeat_yourself http://en.wikipedia.org/wiki/Don't_repeat_yourself
- ahallock 12y ago
  It doesn't violate DRY. The repetition of "collection" is indicating a descendent component: https://github.com/suitcss/suit/blob/master/doc/naming-conventions.md https://github.com/suitcss/suit/blob/master/doc/naming-conve...
  - BinaryIdiot 12y ago
    HTML provides nesting. Nesting indicates it is a descendent component. This would violate DRY.
    - ahallock 12y ago
      LIs are generic containers--the only way to narrowly scope LIs is to use hierarchical selectors, which leads location dependency and specificity issues. The class name creates a scope and you need to apply that to decedent components to enforce the scope. It's DRY within the naming convention, which doesn't mix element selectors with class selectors (or at least rarely).
      - BinaryIdiot 12y ago
        > LIs are generic containers LIs are actually kinda special. It's incredibly difficult to create your own LI in, say, web components because of their specialness (at least I've never seen it work in all browsers though there are probably some crazy hacks to get it there (or at least close enough)). > which leads location dependency and specificity issues You have a list of a specific type so you put a class on it. Why would that specific type of list now contain items that can be used in multiple places versus in that specific list and why would they ever be moved from that specific type of list? I don't really understand the issue you're trying to convey.
bbx 12y ago
Tell your lead front dev this approach isn't best practice at all. You want one collection li's to not have the style? Use an alternative class on the ul: "collection collection-alt". You want nested li's to not inherit the styles? Use ".collection > li" in your CSS. In any case, assigning a class on each li goes exactly against CSS best practices, because it prevents taking advantage of the inheritance of property values or of advanced selectors.
- dovel 12y ago
  I dont do this repeating class business but CSS Tricks 'css guidelines' web page says that when you do : '.collection li', it first searches through the page for all 'li's then wittles it down to the ones within the correct parent. Essentially that css selectors work from right to left. So I guess the idea is that classing up the li elements within a parent may be marginally quicker? I have never bothered though. Does anyone know more about this?
  - ddoolin 12y ago
    This is true, actually. They are read from right-to-left. I'm not sure how much extra resources are expended searching this way opposed to the other, though my guess would be the same as yours. It may be worth a benchmark?
  - anton-107 12y ago
    It used to be the issue in the "old browsers", modern browsers optimize the css query selectors to a very high extent, so users probably won't see a difference on any real web page / app
  - vbezhenar 12y ago
    Modern browsers do their best to optimize typical use-cases for CSS selectors and .collection li for sure will be handled optimally. You shouldn't worry about CSS selector performance unless you have to provide good performance for very old browsers or hit specific performance problem. Optimize for humans, not for computers.
moron4hire 12y ago
I've come to expect people who criticize others using "best practice" as their "source" are themselves not very good at what they do and are just cargo-culting ideas without any real understanding in underlying principles.

deleted 12y ago

[deleted]

danielmason 12y ago

There's a reasoning behind this. You may not agree with it, but it's good to fully understand the problem it's trying to solve. There are two problems with your suggested approach -- specificity and coupling. The rules of CSS are such that .collection > li is a more specific selector than .collection-item. So if you want a particular item in the list to be red, you can't just give it a class name .warning-item and style against that -- you have to match or exceed the existing specificity. In the simple case, this isn't too bad, but it's surprisingly easy to end up representing deeply nested structures in your CSS which are very difficult to override. The coupling problem is really just a way of saying that it might not be a good idea to describe the specifics of your HTML implementation in CSS. Class names are like an interface. One refactoring I've actually done a lot is switching out lists like the above for a combination of nav and anchor elements. It's great to be able to do that without needing to rewrite all the corresponding CSS, too. These are tools designed to help you manage complexity and increase flexibility, not dogma. If you don't find your HTML needing to change much, or you don't need to make styles overrideable, then YAGNI. Hopefully it makes sense why framework authors, whose work is explicitly designed to be overridden, would choose this approach.

riquito 12y ago
Performance is penalized too. Since CSS rules are parsed from right to left and you have probably a lot of "li" tags, the rule would be very inefficient. Of course this doesn't matter in small pages.
- rimantas 12y ago
  It does not matter in any real life pages.
  - riquito 12y ago
    It did for Trello, to name an example (search for speed in http://blog.trello.com/refining-the-way-we-structure-our-css-at-trello/ http://blog.trello.com/refining-the-way-we-structure-our-css...).
- 12y ago

CleanCoder 12y ago

SMACSS - Scalable and Modular Architecture for CSS.

yummybear 12y ago

My personal experience is: Using element names instead of class names can be problematic. In some frameworks you may need to use a different element or an element that wraps another element to achieve certain functionality. Some use generic names like "button large" as class names, but, again in my personal experience, it often causes problems. You might have other elements that need to be "large" and may need to be inside a button - but which "large" do you mean. So to keep things predictable, I've adopted the following practices: - Always namespace components. - Always ensure that selectors work even if the child has a wrapper around it. - Whenever possible use classnames instead of element names. And to ensure I don't get tendonitis (not sure if everyone agrees with this): - If possible provide a shorthand for at least the most used components (i.e. "col"/"col-i" for "collection"/"collection-item"

EugeneOZ 12y ago

What will you do when you need div.a list instead of ul.li?