Hacker News Reader

Comment by simonw | Hacker News Reader

Natalie Downe, my co-founder, has a very neat technique for organising CSS which she calls a CSS System. She described it in this talk:

http://lanyrd.com/2008/barcamp-london-5/sg/

She splits everything in to general styles (basic HTML elements), helper styles (things like forms, notifications, icons), page structure (header, footer, layout columns etc), page components (reusable composable classes for components that occur on different pages in different combinations, such as a news teaser) and over-rides (special cases for individual pages, rarely used).

She hardly ever uses IDs, preferring classes for almost everything - because CSS written against classes can be used more than once on a page.

She uses CSSEdit's groups feature to make the CSS easier to navigate - it's all in one file. http://macrabbit.com/cssedit/

View the stylesheets on http://lanyrd.com/ and follow the link at the top to the unminified version to see annotated examples.

View on HN

I checked the lanyrd.com stylesheet. I'm sorry to say but if your stylesheet is this big you are doing it wrong. 100K for a compressed stylesheet! So I'm not so sure her technique is a winner.

Lanyrd is a complex site - we have over 50 different page templates, all of which are styled using that one stylesheet. We get a lot of functionality out of that 100K. Not to mention that CSS compresses extremely well - served with gzip, the entire stylesheet is actually just 19745 bytes.

We use a far-future expires header (and serve from Amazon CloudFront), so browsers should only ever fetch the file once no matter how many pages on the site the user visits.

Oh really? Because every medium-to-large website I've ever looked at or developed has had a stylesheet that large. Facebook? Twitter? GitHub? 100k+ compressed stylesheets. Hell, even if your site is small-to-medium sized but very design-intensive, I could see you reaching that mark.

Don't worry, I'm sure all those developers are "doing it wrong" too.

Well did you check the stylesheet of Twitter for instance? Only 40K but even then.. why even that big for a simple Twitter homepage!? So I'm sorry you did not convince me. And maybe, I know it's a bold statement, they are doing it wrong.

I think it also has to do with frameworks. Sometimes frameworks spit out a lot of HTML you won't ever need. So the HTML is bloated in the first place. Then it's a hell of a job to style the mess.

When you are fortunate to control the HTML you should first start to optimize your HTML before you even start with CSS.

ID's are useful for unique element styling which will always be a case in a website. There's certain elements that are absolutely unique.

Goes hand-in-hand with javascript to ease selector targeting.

I never scope ID's either, that's the wrong way to do it. An ID is always unique so it is top-level.

The problem with absolutely unique elements is that, in a complex enough website (that evolves over time), they often end up not being unique after all.

I agree about IDs for JavaScript though.

Exactly, as far as CSS is concerned an id is effectively equivalent to a class name except when it breaks things.

Ids should be used only for scripts, and most of the time should be auto generated anyway.

It is not equivalent in any sense. Let's not forget specificity.

If you're relying on weird specificity chains, then your CSS is likely an unmaintainable mess.

Leave IDs for uniquely identifying an element on a page because you need to access it from a script.

Treating them like "Extra Strong" class names is a maintenance nightmare.

"I agree about IDs for JavaScript though."

Would you mind elaborating on the JavaScript point? Is it for convenience with document.getElementById or something?

Using jQuery, I tend to prefer class selectors the same as in my CSS.

Jquery class selector is the slowest selector, avoid them as much as possible. ID selector is the fastest. So, if your application is jquery intense, better avoid css selectors.

in modern querySelector implementations (any real browser), class look-ups are just as fast as IDs.

There's less of a win in ajax from applying functionality on a class level - there aren't typically multiple selector boxes on the same page that all hit the same ajax callback.

ID is unique on the page. Website can have many pages. If there is a need to style some element of the page differently scoped IDs can be handy.

Another problem with IDs is that they make the "point system" in selectors much more complicated than if you only use classes and elements.

What about an ID for main page elements and things that never will change like #header or #footer or #sidebar?

Ideally for those you would use the html5 header, footer, and aside tags, respectively. You can use the html5 Javascript shim to enable support for those tags in IE.

sidebar is not equal aside, and you can have several headers footers on one page.

I think most of you who answered this reply missed the point where CSS is not HTML… ID's should be used when they suit better. The same with classes. You end up constructing semantical html which a) easier to maintain and b) won't mix the design with the content on code-time.

+1 for never styling by IDs, which are global variables and should be used when all else fails.

Reply on news.ycombinator.com