> For each level of markup nesting, try and indent your CSS to match.
Nope.
> Also write vendor prefixed CSS so that colons all line up
Nope.
> When building a new component write markup before CSS
Yes!
> Instead of building dozens of unique components, try and spot repeated design patterns abstract them; build these skeletons as base ‘objects’ and then peg classes onto these to extend their styling for more unique circumstances.
This is a bone of contention amongst front-end developers. If you're Facebook, and you have a deep and wide site architecture that would otherwise result in masses of duplication, this makes sense (although arguably using CSS preprocessors like LESS or SASS would make even more sense), but these rules do not make sense for small to medium sized sites. If anything, they encourage a thin layer of abstraction on what would otherwise be entirely presentational markup. You were on to something when you said start with your markup: classify your marked up elements by giving them IDs and classes according to what they are and what they do, and then declare rules for how things of that type want to look.
> All components should be left totally free of widths; your components should always remain fluid and their widths should be governed by a grid system.
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.
> Heavily location-based selectors are bad for a number of reasons.
Nope. What you're arguing against is a rule that has a high degree of specificity. Naturally there is a sane limit to how specific a selector should be (if you want to avoid specificity wars) but `.sidebar h3 span` is not too specific a rule.
> An over-qualified selector is one like div.promo
Alternatively you might call this a self-documenting selector. If you're going to apply a class to multiple types of element and you want them to all inherit the same rules then sure, don't apply an element name too — otherwise you're adding classes which communicate zero information to a developer unfamiliar with the markup structure.
> Do not use IDs in CSS at all.
NOPE NOPE NOPE NOPE NOPE. Understand specificity rules. Write good selectors. Don't outright ban IDs just because you're not careful enough to write clean CSS.
> As a general rule, all layout and box-model rules can and will work without an IE stylesheet if you refactor and rework your CSS.
Hahahahahahahahahhaa.
I'll echo comments from others here; these are not ‘best-practices’ — they're just a set of arbitrary rules that you might find work for you, but you might find they don't. I'd argue that if you enforce these vigorously, your projects are succeeding in spite of these rules, not because of them.
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.
I find it bizarre that the author would admonish against multiple rules on a single line due to version control, yet would recommend making colons line up for vendor prefixes. Sure, it's probably not often that a new vendor prefix would come along (or one would accidentally initially be forgotten), but adding a new (longer) prefix would require introducing a diff to the other lines even though they haven't truly been changed.
If you change any code it will show up in a diff, whether that be vendor prefixed or not. A vendor prefix changing is just the same as a padding value changing; if code needs to change then change it and you will fully expect to see it show up in a diff.
Single line CSS’ problem is that a diff of it can be a little misleading.
Nope.
> Also write vendor prefixed CSS so that colons all line up
Nope.
> When building a new component write markup before CSS
Yes!
> Instead of building dozens of unique components, try and spot repeated design patterns abstract them; build these skeletons as base ‘objects’ and then peg classes onto these to extend their styling for more unique circumstances.
This is a bone of contention amongst front-end developers. If you're Facebook, and you have a deep and wide site architecture that would otherwise result in masses of duplication, this makes sense (although arguably using CSS preprocessors like LESS or SASS would make even more sense), but these rules do not make sense for small to medium sized sites. If anything, they encourage a thin layer of abstraction on what would otherwise be entirely presentational markup. You were on to something when you said start with your markup: classify your marked up elements by giving them IDs and classes according to what they are and what they do, and then declare rules for how things of that type want to look.
> All components should be left totally free of widths; your components should always remain fluid and their widths should be governed by a grid system.
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.
> Heavily location-based selectors are bad for a number of reasons.
Nope. What you're arguing against is a rule that has a high degree of specificity. Naturally there is a sane limit to how specific a selector should be (if you want to avoid specificity wars) but `.sidebar h3 span` is not too specific a rule.
> An over-qualified selector is one like div.promo
Alternatively you might call this a self-documenting selector. If you're going to apply a class to multiple types of element and you want them to all inherit the same rules then sure, don't apply an element name too — otherwise you're adding classes which communicate zero information to a developer unfamiliar with the markup structure.
> Do not use IDs in CSS at all.
NOPE NOPE NOPE NOPE NOPE. Understand specificity rules. Write good selectors. Don't outright ban IDs just because you're not careful enough to write clean CSS.
> As a general rule, all layout and box-model rules can and will work without an IE stylesheet if you refactor and rework your CSS.
Hahahahahahahahahhaa.
I'll echo comments from others here; these are not ‘best-practices’ — they're just a set of arbitrary rules that you might find work for you, but you might find they don't. I'd argue that if you enforce these vigorously, your projects are succeeding in spite of these rules, not because of them.