Then it's possibly appropriate. I remain unconvinced even in large projects but I do think CSS is lacking some important features that would make this kind of practice redundant; the kind of things that LESS and SASS provide, like variables and mixins.
> Heavily location selectors hinder flexibility; components should not rely too heavily on where they live, they should be movable as easily as possible.
This again makes presumptions about what kind of site you're building. If you're aiming for heavily modular, reusable components where you'll be repeating markup patterns throughout, it may be more appropriate. Nonetheless, the example you cited looked like a small, common pattern that is easily self-contained enough to be reused in this way.
> IDs will only ever hinder a CSS developer; they offer zero benefit (where CSS is concerned) over a class, thus why would you ever bother using them?
Specificity is an important part of the cascade, and a tool in your box. Being able to target an element with a higher priority than another without needlessly complicating the selector is a feature I wouldn't voluntarily give up just because of some nebulous claim of harm they might cause. Another reason is the same one I don't agree with stripping off element names; they are self-documenting and give developers clear, unavoidable signposts about the nature of the elements they're targeting.
> I’ve just finished the rebuild a massive front-end, the project as a whole took over a year. Number of IE stylesheets: 0. It can be done.
Every project is different. Some will accept layout degradation in older browsers. Some won't. Some will demand extravagant layout effects that require extra time and effort to get working well in IE6-8. To suggest that IE-specific stylesheets are something you should be striving to omit is to needlessly burden developers with (potentially) unreachable goals.
That's the crux of my problem with these ‘best practices’ — developers who've yet to spend a lot of time thinking about how to structure their CSS well could come across these and head off in all manner of wrongheaded directions. Maybe that's why there aren't any universally agreed-upon CSS best practices beyond more simple techniques; the general rule I take with me is ‘YMMV’.
> This again makes presumptions about what kind of site you're building.
It doesn't matter whether you're building Facebook or the site for the window cleaner two doors down the road; you never want issues with maintenance, ever. Make sure you can move a person's wall post to a new location without issue, make sure Bob the window-cleaner can move a testimonial from the footer to the sidebar without issue. Size of project is wholly irrelevant.
> Specificity is an important part of the cascade.
It is, and an ID is the quickest way to f#&k with it. As is qualifying your selectors. You're tying yourself to commitments that you might not want to keep.
The things you are arguing against are the most fundamental in helping build maintainable websites.
If nothing else, the discussion you have sparked will serve useful for those of us that are clueless. I've even saved this thread locally to revisit once I feel knowledgeable enough to come to my own conclusions.
Then they're implicitly not ‘best practices’.
> We’re not Facebook, but we are big.
Then it's possibly appropriate. I remain unconvinced even in large projects but I do think CSS is lacking some important features that would make this kind of practice redundant; the kind of things that LESS and SASS provide, like variables and mixins.
> Heavily location selectors hinder flexibility; components should not rely too heavily on where they live, they should be movable as easily as possible.
This again makes presumptions about what kind of site you're building. If you're aiming for heavily modular, reusable components where you'll be repeating markup patterns throughout, it may be more appropriate. Nonetheless, the example you cited looked like a small, common pattern that is easily self-contained enough to be reused in this way.
> IDs will only ever hinder a CSS developer; they offer zero benefit (where CSS is concerned) over a class, thus why would you ever bother using them?
Specificity is an important part of the cascade, and a tool in your box. Being able to target an element with a higher priority than another without needlessly complicating the selector is a feature I wouldn't voluntarily give up just because of some nebulous claim of harm they might cause. Another reason is the same one I don't agree with stripping off element names; they are self-documenting and give developers clear, unavoidable signposts about the nature of the elements they're targeting.
> I’ve just finished the rebuild a massive front-end, the project as a whole took over a year. Number of IE stylesheets: 0. It can be done.
Every project is different. Some will accept layout degradation in older browsers. Some won't. Some will demand extravagant layout effects that require extra time and effort to get working well in IE6-8. To suggest that IE-specific stylesheets are something you should be striving to omit is to needlessly burden developers with (potentially) unreachable goals.
That's the crux of my problem with these ‘best practices’ — developers who've yet to spend a lot of time thinking about how to structure their CSS well could come across these and head off in all manner of wrongheaded directions. Maybe that's why there aren't any universally agreed-upon CSS best practices beyond more simple techniques; the general rule I take with me is ‘YMMV’.