Earlier quoted context omitted.
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 mom…
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 v…
I guess it's come about from trying to be more semantic within the documents.
Declaring Headings with classes is a good example as well.
h1,
.h1{
font-size:20px;
}
h2,
.h2{
font-size:18px;
}
's while still keeping the content semantically correct and designers happy.
Another few other common ones are
strong,
.strong{
font-weight:600;
}
small,
.small{
text-size:10px;
}
It also does not really go against inheritance, themes like .collection-alt can still work.
Sometimes its an overkill and I don't always do it, but in some cases (heavily responsive sites) it has worked really well. Its also easier to work in a team with one approach, rather then just doing it for headings etc why not take the principle/standard across all styles.