Hacker News Reader

> This document is a personal one

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’.

> Then it's possibly appropriate.

It's definitely appropriate.

> 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.

Reason to USE ID's:

1-ID's are the fastest CSS selector.

2-ID's are the fastest Xpath Selector.

3-ID's are the fastest JQuery selector.

4-ID's make your front-end test-able.

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.

blather all you want, but the consensus here is IDs, when properly used, enable speed and specificity. you don't get to tell us what's best practice.

Ah yes, the almighty consensus has spoken. Dare not disagree or we shall smite you.

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.

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.