This document is a personal one, and for use at my place of work. I decided to share it in the hope that it might be useful to others but if you disagree with anything please remember; this is a document for me and Sky. You do not have to follow the advice given, nor do I provide any guarantee. — https://github.com/csswizardry/CSS-Guidelines/blob/master/RE...
> Nope.
Fair enough.
> Nope.
Fair enough.
> If you're Facebook, and you have a deep and wide site architecture…
We’re not Facebook, but we are big.
> Nope. Again, grid systems are something that should be used on a case-by-case basis, according to the nature of the site you're building.
Okay, as mentioned this is doc used largely at my place of work where we do use a grid system. For places that don’t use one then this basically means ‘don’t apply dimensions to components; leave structure to parents and wrappers’. Hard coding dimensions on components should be avoided at all costs.
> Nope. What you're arguing against is a rule that has a high degree of specificity.
I’m not. Heavily location selectors hinder flexibility; components should not rely too heavily on where they live, they should be movable as easily as possible. Shorter, less location-dependent selectors aid this.
> Don't outright ban IDs just because you're not careful enough to write clean CSS.
I believe I’ve got my CSS nailed, thanks. 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? If all they can do is harm then just cut them out; even the most careful developers can get tripped up by the overly specific nature of IDs.
> Hahahahahahahahahhaa.
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.
Without ID's, functional, integration, regression, and even load testing are many orders of magnitude more difficult. If you are worldly enough to be offering best practice advice, I assume you or your organization tests at some point in your process?
Points 2, 3 and 4 are irrelevant here. Do not use IDs in CSS. Use them in markup and JS and tests, sure, just not in CSS.
Point 1: The speed difference between a class and an ID is so, so slight that it's almost non-existent. The specificity difference between a class and an ID is massive.
If a given ID element is uniquely styled (a very common use case), it seems backwards to me to explicitly give it a class so that you can select it by class instead of by the ID that already exists.
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.
I support your IE stylesheet ban. CSS can definitely be written without a separate IE CSS and be pixel perfect across browsers. Several techniques I've incorporated to help avoid browser inconsistencies:
Use a good clearfix.
Avoid margins and use padding instead as much as possible to avoid issues with margin collapse.
Be weary of inline-block.
IE style sheets drastically clean up the main stylesheet. O'reilly's book on CSS recommends to code to the standards and hack to the fringe browsers, and with good reason. Browsers change all the time. But they will always gravitate towards the standards. If you have have non-standards CSS your site will break in the future.
This document is a personal one, and for use at my place of work. I decided to share it in the hope that it might be useful to others but if you disagree with anything please remember; this is a document for me and Sky. You do not have to follow the advice given, nor do I provide any guarantee. — https://github.com/csswizardry/CSS-Guidelines/blob/master/RE...
> Nope.
Fair enough.
> Nope.
Fair enough.
> If you're Facebook, and you have a deep and wide site architecture…
We’re not Facebook, but we are big.
> Nope. Again, grid systems are something that should be used on a case-by-case basis, according to the nature of the site you're building.
Okay, as mentioned this is doc used largely at my place of work where we do use a grid system. For places that don’t use one then this basically means ‘don’t apply dimensions to components; leave structure to parents and wrappers’. Hard coding dimensions on components should be avoided at all costs.
> Nope. What you're arguing against is a rule that has a high degree of specificity.
I’m not. Heavily location selectors hinder flexibility; components should not rely too heavily on where they live, they should be movable as easily as possible. Shorter, less location-dependent selectors aid this.
> Don't outright ban IDs just because you're not careful enough to write clean CSS.
I believe I’ve got my CSS nailed, thanks. 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? If all they can do is harm then just cut them out; even the most careful developers can get tripped up by the overly specific nature of IDs.
> Hahahahahahahahahhaa.
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.