Show HN: I decided to document and share my high-level CSS best practices | Hacker News Reader

Show HN: I decided to document and share my high-level CSS best practices

github.com

223 pointscsswizardry86 comments

I'm surprised by the lack of spaces in, say,

  .error{ color:red; }

I much prefer

  .error { color: red; }

  .error {
    color: red;
  }

(The latter is particularly nice because it implicitly acknowledges the likelihood that additional rules will be added.)

I don't recall seeing the space-compressed version much in the old days. Is it a new trend? I don't like it.

Personally, I prefer the non-spaced variant when dealing with one-lined css. Simply because grouping it visually in chunks makes it easier for me to skim through code.

Here I can recognize 4 chunks almost immediately:

  .error{ width:350px; height:200px; color:red; background:blue; }

While here everything gets mixed up due to its uniformed spacing:

  .error { width: 350px; height: 200px; color: red; background: blue; }

I don't understand how anyone using version control can use one liner CSS. There is code folding in all decent text editors.

I break about half of those rules and it works very, very well. Please don't label things that can be discussed as 'best practices'. One day some newbie will wonder across it, take it as gospel, and then will screw up projects by applying them when they don't make sense.

Also there is nothing wrong with magic numbers so long as you don't use them where a % would be more appropriate (e.g this text is 12px, because it looks nice). If CSS is used with out a pre-processor you have to use them, as there is no concept of variables.

> Please don't label things that can be discussed as 'best practices'.

This is valid point, however In the README there is the line ‘This document is a personal one, and for use at my place of work […] this is a document for me and Sky. You do not have to follow the advice given, nor do I provide any guarantee.’

In the context of our team I can afford to make more sweeping statements because I have the ability to discuss and expand on the caveats. Perhaps this document becomes less useful in places without that context.

> e.g this text is 12px, because it looks nice

This is not an example of a magic number, this is a design decision that was made regardless of code. Perhaps I need to me more clear on what a magic number is, but by that I mean anything that has no reason for being.

Cheers for the feedback, I might look at rewording some bits for clarity :)

So you are neatly packaging your knowledge, publishing it and marketing it (at least here and on reddit, not the smallest websites, possibly elsewhere) but somehow it's still a "personal document" and your "best practices" shouldn't be followed?

> "In the context of our team I can afford to make more sweeping statements"

As soon as you publish your document and market it the context of your statements changes. A lot. Think about all the *-killers that pop up every single day: the Internet loves to bash them when they fail.

I see your point. This started off as a personal/close-knit reference for me and my teams’ best practices. Then I thought I might as well share it, even if only one other person finds it useful then that’s better than keeping it to myself. I packaged it with caveats and disclaimers and you can take the advice or leave it.

A document was created for a small audience, sharing it was secondary, and an afterthought. It is not up to me to decide who follows them and who doesn’t; I merely made them public and people have the ability to pick, choose or even ignore at will.

You have some interesting opinions.

It would be better if you viewed your code less emotionally, and focused on getting the job done. Maybe then you'd be more productive?

>I break about half of those rules and it works very, very well.

Can you go into more detail about which rules you disagree with or find unnecessary?

Not who you're replying to, but on my list:

CamelCase vs using-dashes is strictly a developer preference. I happen to agree with the author of the doc about using dashes, but I'm not going to call my preference a "best practice". A "best practice" might be more akin to "if you're working on an already in progress project, don't start doing CamelCase if they're using-dashes, or vice-versa", IMO.

Another controversial one is whether or not to have each style on it's own line, or in the same line. The author prefers a new line for each style because it makes for easier diff-ing in version control. The argument could be made, however, that this style introduces too much whitespace and vastly reduces the number of styles you can view at one time, not to mention increasing the linecount of your stylesheet by at least a factor of 3. Neither is, IMO, a "best practice", it's just a developer preference (IME most devs do agree with this doc, however).

There's some other stuff that really just boils down to how the author prefers to read his CSS, and not really about how to structure it in a proven optimal way. I believe it's hard to argue that those are "best practices", something Wikipedia describes as "consistently shown results superior to those achieved with other means". I would like to see the argument that lining up your -webkit prefixed styles achieves this, for example.

Anyway, IMO, a lot of the recommendations in the doc are good advice, just mixed in with some personal preferences. Like the author wrote though, it is his personal best practices, so in that context I suppose these are Best Practices, only the scope is limited to just the author.

Magic numbers (you have to because CSS doesn't allow you to make variables), specify a height and width in pixels (works well if it doesn't contain text that may be changed and is the only way to do certain things) no index.

I suspect it is because I write HTML5 apps, rather than websites (distinguishing feature: HTML5 apps have no 'you don't have javascript' fallbacks and they can't reasonably have any.).

This is fantastic. While I disagree with some things (I'd rather standardize on px for everything, since em's have also been a huge headache for font-sizes), I love seeing the fact that this document exists.

I've written my own guidelines similar to this for different workplaces, though never publicized them. It would be wonderful if there could be some kind of consensus-best-CSS-practices standard out there, much like people have standardized on a couple common CSS resets, etc.

I've found that client-side developers tend to differ drastically in philosophies behind CSS coding, especially ones with less experience.

In my opinion, CSS is one of the most "dangerous" languages out there -- more often misunderstood and misused than any other language I've ever come across, including VB6 -- and thus most needing a standardized set of best practices.

>consensus-best-CSS-practices standard out there

No no no no. Best practices becomes an excuse for developers to switch of their minds and not think. In all cases there are exceptions to the best practices but people always forget that.

The reason there are differences between what people prefer is that they work on different problems. That is a good thing and should be encouraged, not squashed.

While I would never advocate developers not thinking for themselves, I think it's shallow to say that seeking out and following best practices is an excuse to not think.

In fact, some languages, like Rails, are considered opinionated by imposing certain practices and standards in order to streamline the repetitive implementations that most applications need. This frees the developer to focus and think more about the more complex and less repetitive tasks.

http://programmers.stackexchange.com/questions/12182/what-do...

Best practices is a useful tool for developers to switch their minds on to real problems. I don't want to think how to align vendor-specific styles, whether to use a class or ID here, whether to create IE-specific stylesheet or not.

While I can disagree with some points, I don't think it makes sense at all to express the disagreement. OP explicitly claimed that it's his best practices (not universal truth), and I think it's a very valuable thing to share anyway.

Here is a very petty point that isn't mentioned in the guidelines, but implied by example: Is there a good reason why people don't like putting a space after a colon? Such as...

    margin:0;

Instead of...

    margin: 0;

The latter looks much more natural to me (probably because I'm used to writing English and other syntaxes), so I don't believe there's an aesthetic benefit. Chrome Inspector and Firebug also prefer the latter, so I don't believe there's a tool benefit. If saving a byte before processing was an issue then we'd be hitting less CRs, so there's no real bandwidth benefit. I don't get it, but I keep seeing it more and more.

Is there some benefit to no-space-after-colon that I haven't considered? Was it established as a standard somehow while I wasn't paying attention?

For me it is purely habit. I think: to each their own, just aim for consistency :)

I always write

  margin:0;

instead of

  margin: 0;

Here's why.

The first reason I do is because you don't need to write that space. It doesn't seem like much but it makes a difference when you're writing up to more than 1000 lines for one CSS (I type every word using Notepad++).

Second reason is: by removing this space, it joins the property (margin) and the value (0) together. And because I write my CSS in lines, it makes a difference when scanning visually.

  input { background:white; border:none; float:left; font-size:14px; margin:0; padding:5px; width:400px;}

is easier for me to scan than

  input { background: white; border: none; float: left; font-size: 14px; margin: 0; padding: 5px; width: 400px;}

because I can easily target any pair property/value.

And the reason I don't mind the lack of space after the colon is probably because I'm French and in French there needs to be a space before and after a colon. So I guess that if I remove the one before I might as well get rid of the one after (for symmetry?!).

I'd never thought of it that way. However, for me,

    input,
    select {
        background: white;
        border: none;
        float: left;
        font-size: 14px;
        margin: 0;
        padding: 5px;
        width: 400px;
    }

Is more readable—each rule and selector on its own line. I am biased as I use Vim and half-page scroll lots, and like an 80-character maximum, though.

I started writing CSS just like that. It makes reading properties easy but takes a lot of vertical space (and unlike you, I hate to scroll). So I write properties on one line, which makes reading selectors easy (example: http://jgthms.com/wings.css).

I compensate by ordering my properties alphabetically so I can scan horizontally to find any property (background and border come first, margin and padding are near the middle, text-transform and width are near the end...).

> I compensate by ordering my properties alphabetically so I can scan horizontally to find any property (background and border come first, margin and padding are near the middle, text-transform and width are near the end...).

Not a bad idea... I'm stealing it.

I put "more likely to cause layout trouble" bits closer to the front where they'll be spotted more quickly. e.g., float, border, width, etc.

I don't write margin:0; but use margin: 0;

The reason is because of shorthand: margin: 20px auto 10px; === works | margin:20pxauto10px; === fails

Therefore, putting the space after the colon is pure habit for spacing reasons.

Yes, I understand that margin:20px auto 50px; works. It's just habit and preference.

Some nice ideas, but not many new ones. And the new ones don't always make sense:

"For each level of markup nesting, try and indent your CSS to match" <= that made my teeth itch. Mostly just down to personal taste, but I really find it quicker to read css if only the values are indented. It's easier to compare nested classes that way, as repeated values would occupy more similar space.

"Also write vendor prefixed CSS so that colons all line up" <= not all vendor css3 values have the same structure, so this can't be a standard (eg: gradients, mixed border-radius)

I suppose whether or not you add conditional support for IE is a matter of taste. I prefer to handle IE the boilerplate way, with conditionals determining what class the html element has, and including appropriate styles in the main css. Why sacrifice good, standards-compliant css for dirty IE?

> that made my teeth itch

Fair enough; any reason as to why?

> not all vendor css3 definitions have the same structure, so this can't be a standard

Well if it can’t be done then it can’t be done…

The "teeth itch" thing: It feels too much like over-ornamentation. It just wouldn't suit my style of work. I find it much faster to scan css when everything is vertically aligned. If I have to scan left and right as well as up and down, it takes me longer, and comparisons are slower.

It could also lead to lazy naming. I'd prefer to see intelligent names used instead. If your css is tab-synched with your markup you might be tempted to lazily name your attributes assuming that people will figure out due to the tabbing. But your css should make some kind of sense independent of the markup.

Also, it confuses the functionality of the nesting (IMHO). When I look at

    .nav
        .nav li
            .nav li span

It looks like the indents imply some kind of syntactic meaning. Is it tabbed because tabs now mean something? In which case the second line might be equivalent to

  .nav.nav li         which it is not.

Usually an indent implies some kind of relation to the previous line. For example when you indent the body of a function it helps to indicate that the body is part of the function. There's a logical difference and most likely even a scope level difference. The indents that you are adding to CSS don't work that way because each new line starts its select with no concern for the line above.

Also, there may be some deeply nested markup that doesn't require css except for the first and last level of nesting. Are you supposed to then have a series of empty tab levels in your css file? And then if you remove some of those nests in the markup, you have to remove them in the css? Not nice. The coupling provides no advantage.

If you're this concerned about the readability and/or modularity of your code, you should be using a css preprocessor like less/sass/scss. Even if you have css all dolled up like this, it will still take longer to update and manage than it would if you were using mixins and variable declarations.

Yes it is one more thing in the pipeline. But you should be minifying your CSS anyway, so you're already compiling your css in a way.

Any "CSS Best Practices" guide should start with "1. Use a preprocessor."

Also, don't use IDs? Really? The article referenced as a source for this claim ends with "Don’t stop using IDs, just be aware of where they can cause you headaches and know where to sensibly circumvent them. Anyone telling you not to use them at all is not wrong, but they’re definitely not right…"

That's good advice. Understanding how specificity works will make you realize, when designing your Twitter widget, relying on a selector ".tweet a" is unreliable, and use "a.tweet-link" instead.

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

Catch all response:

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.

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

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.

>> For each level of markup nesting, try and indent your CSS to match. > Nope.

Happy Cog does this (http://happycog.com/a/c/screen.css), Jason Santa Maria (http://v5.static.jasonsantamaria.com/c/screen.v2011083002.cs...), and many other well-respected designers.

2 things I would change.

1. There should never be a css reset, normalize is better.

https://github.com/necolas/normalize.css or with IE6/7 junk removed: https://github.com/CoryMathews/normalize.css

2. Structure the file in the method mentioned

http://smacss.com/book/categorizing

"So there would be 5 basic areas in your stylesheet.

Base Layout Module State Theme"

Thanks for the normalize link. I learned more about various browser inconsistencies from their comments than I have from months of self study.

Thanks for the categorising link too. That's something which I've often wondered/changed my mind about - and the OP doesn't offer much in the way of insight on it.

I'm a relative newb at CSS as I just launched my site last October... I'm mostly self-taught and I LOVE reading stuff like this. Can I beg you for a response?

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

Okay. I just got away from fixed widths and I like it, so I'm on board so far....

>Heights should never be be applied to elements. Never ever set heights on ps, uls, divs, anything.

Okay, but here's where I'm lost. I learned somewhat early on that for a container that will contain anything other than text, you should do something like:

  .container{
      height: auto !important;
      height: 100px;
  }

Supposedly this ensures that the page is pre-rendered okay before images and such are loaded. It may have been an IE6 workaround for something that I don't use anymore... whatever the reason it's still in my code, is it some rubbish that I should do away with?

I’ve honestly never heard of that being advocated; I’d drop that ASAP if I were you. If you want to ensure there is no page jump as images load then simply give the images width and height attributes :)

I do that already because that just makes sense, but I've been working to clean up my super-newb CSS recently and I'm trying to make it more manageable. I've been using trial and error for the stuff I'm unsure of but that one says it's !important and I didn't want to tempt fate. :D

I'll cut it and see what happens.

Welcome to the dark ages of CSS3! Where you have extremely emotional documents like this one, instead of programmer specs to follow. Does lining up colons have anything to do with anything? Of course not.

The reason we're in the dark ages: we have a subset of front-end designers that are extremely emotional because their code is on display for all to see (View Source). So they take it very defensively, even tho most coders worth their salt aren't 'Emotional About Their Code'.

Also NEVER use pixels. For devices like the 2048pixel width iPad, your so-called Web 2.0 designs with static bitmaps are old school.

In the coming years, all of your graphics will be CSS3 graphics for all header graphics, backgrounds, etc. Bitmap is just too old school for multiple DPI requirements.

Currently you have to rely on an emotional HTML/CSS ninja to get anything done. Soon the CSS3 graphics will be beyond 'lining up colons' and be software generated. I can't wait. Maybe then the whining will end.

I don't want to see any advice about CSS from someone not wanting to see IDs. This is beyond stupid.

That one really bewildered me too. Suddenly there's no motive for having a unique element on a page, and styling it's children accordingly? Nonsense.

It is really easy to shoot yourself in the foot when you add ids to the mix, and there's nothing CSS-wise you can do with ids that you can't do with classes.

For an example of where ids can trip people up, start at slide 66 of this presentation: http://www.slideshare.net/stubbornella/our-best-practices-ar...

I recently worked on a project with a relatively new to CSS developer, and I forgot how much people rely on IDs. I almost gave that person a blanket statement to not use IDs, but I guided him towards reusable classes instead.

It all boils down to reusability though. If you have an ID, say for a #promoCol, sure, there may only be 1 promo column on the page now, but what happens when the client/designer says, hey we need a promoCol on the right side as well? Do you go back and refactor #promoCol to .promoCol (as it should have been originally, IMO), or just add #promoCol2?

Maybe a column is a bad example as you might be able to deduce ahead of time that there MIGHT be more than 1. But you could say that of just about any element on the page. Theater was mentioned, but I've worked on sites where we had to add a second theater second to a page (yah...I know, wasn't my call.)

I would even go so far as to say, if you use IDs in any significant factor in your CSS, you are doing it wrong. And it has absolutely nothing to do with knowing how to work specificity, and everything to do with the additional flexibility not using IDs provides you (or your co-workers) both during an initial build and down the line when maintaining or updating a project.

I would much rather prefer for there to be #promoCol and #promoCol2. From my experience, promoCol2 often ends having more things in different than common from promoCol1.

I love IDs because I don't need to think about changing a class to fix one page only to see the same class screw up another page.

Do you go back and refactor #promoCol to .promoCol?

Yeah, that's exactly what you do. Just because your new dev doesn't know how to refactor (and it's hardly even refactoring, it's like a two-line diff) doesn't mean we all shouldn't use IDs.

IDs have an extra bit of self-documentation when you use them - when I see #promoCol, I know instantly that there's just one promocol, and I don't have to worry about breaking the look of another promocol while I'm fiddling with the CSS in there. If there's a class, you don't know how many things it applies to until you've done a grep over your project.

I also work for Sky (different part) and these guidelines seem mostly sensible to me, so much so I may recommend them to my team, with some caveats:

- Have no problem with IDs if they're used correctly for unique items. The cascade should not be an issue. - Formatting of css and vendor prefixes - these aren't guidelines they're personal preferences. There's no appreciable maintenance benefit for any of them in my opinion. Each to their own.

I am in favour of dashes too, On a big project you might spend literally 100s of hours writing or editing css, using dashes will save you enough time in keystrokes to have a an extra long lunch by the end of it.

His advice for using 'short selectors' for performance is just plain incorrect.

http://code.google.com/speed/page-speed/docs/rendering.html is a great page describing CSS performance.

Selectors like '.nav a' would not be allowed at all as a part of my team's CSS best practices, as it is a descendant selector that uses a tag as the key. (On the other hand, most sites, expecially non-dynamic sites, don't need to optimize CSS at all, as there are usually other things which are the bottleneck)

> We use hyphen delimited,

> lowercase selectors: .thisIsBad{},

> .this_is_also_bad{} but .this-is-correct{}.

I am a fan of mixing Camel Case and Dash Separated. I use Camel case for specific elements.

eg. ".addClientButton"

However, I use a mix of Camel Case and Dash Separated for IDs specifying a specific element in a specific part of the dom.

eg. "#newClientPanel-addClientButton"

I learned this method from looking at how apple.com does their styles on their check out screen. However, it doesn't look like they don't do it this way any more.

How do you handle making unique IDs? I guess I could switch to something like

.add-client-button and #new-client-panel_add-client-button

I don’t like .this-is-correct{} because sometimes you have the same variable name in Javascript too, where dashes won’t work.

Dashes map more cleanly to existing CSS syntax, eg nth-child, background-color, etc. Much like camelCase looks more like Javascript than my_variable.

I do something similar, where I use hyphens to delineate ideas and sub ideas (table-striped) but use camelCase when one of the class parts contains multiple words. (form-addUser)

This also plays well with my IDE which splits word selection on a hyphen, so if i want to change form-addUser to form-removeMonkey, it's just a single selection, where as if it was form-add-user, I would have to actually drag to select the text.

Why "We use hyphen delimited, lowercase selectors: .thisIsBad{}, .this_is_also_bad{} but .this-is-correct{}"? I understand if the point is about the styles itself having hyphens, like padding-bottom, but it breaks the complete expression selection with ctrl+arrows (or even with the double mouse click) which I find much more annoying than using underscores instead of hyphens. I'm biased though, I prefer underscores to camelCase anytime (I do obey whatever is the rule on any project).

No reason other than that is what I started off with and I’d rather keep things consistent. Had I started off with underscores then I’d be asking the team to stick with that.

I guess that section is more about ‘keep everything the same’ rather than ‘we must specifically use hyphens’ :)

Cheers, H

I recently brought this up with my own team after updating a 4-language piece on a project. It was originally pieced together at different times and was inconsistent. However, I was testing the waters with them trying to sell them on underscores.

We've all been using dashes in CSS for so long, but nowadays I personally feel like I'm writing so much JS that I'm longing for underscores.

Downsides: 1. You have to press shift a lot more when writing css 2. ???

Upsides: 1. You can use the "same_name" in CSS and JS 2. You can double-click easily

Feel free to expand on this, we haven't made the change, it's just something that crossed my mind recently :)

Underscores in JavaScript are non-standard too.

The reason I would advocate using hyphens is you should do what the language (standard libraries) do. For example:

    css:
    margin-left, border-bottom (hyphenate)

    javascript:
    getElementById, documentNode (lower camel case)

    ruby:
    each_index, has_key? (underscore)

This would be an interesting discussion. I prefer to use the same coding style for the whole project without caring how the original authors of each language did it. I do however understand that the language API follows the original convention so one would eventually break it by following by reasoning. Ex in js: make_element_slide(getElementById('box')).

One tiny tip I have is to use underscores in ids and hyphens in classes. That way if I see $(".things-to-find") the fact that "thing-to-find" is not recognizable as a javascript variable gives that much more of an indication that it will be (relatively) expensive. Likewise #doodad_im_styling looks bad in css files since it doesn't match anything else.

Granted I violate both of these principles, when appropriate, but they're there to keep the average case in line.

The advice to be explicit when using shorthand is excellent. This has come back to bite me many times (you end up re-writing background and margin declarations to undo your clever shorthand).

The multiple measurement units is cool too: particularly unitless line-height, magic numbers, and relying on parent box sizing.

Great stuff, thanks for sharing this. Couple questions:

Do you find indenting descendant selectors helpful?

For your comments, do you adhere to CSSDoc or any particular convention?

Thanks for the comment, I’m glad you like it :) The shorthand one is a really interesting one; it takes while to kick the habit and be purposely more verbose, but you soon get tired of undoing previously accidentally-set styles.

> Do you find indenting descendant selectors helpful?

Oftentimes yes; it can give a new developer more of a clue of the markup structure that a previous developer intended to be used. I can see at a glance that `x` needs to be in `y` but `a` needs to be a sibling of `b`. Of course you could just glean that yourself by looking at and reading all the selectors individually, but it’s nice to get an idea of structure at a glance.

> For your comments, do you adhere to CSSDoc or any particular convention?

Nothing official; I have my own habits but no documented standard. I like the look of http://warpspire.com/posts/kss/ though :)

> When building components try and keep a DRY, OO frame of mind.

Two different things here. OO can mean having excessive numbers of things (files, objects) to do something that can be done more clearly and consisely without them, and it could be argued that having additional files is less DRY if you don't need to provide the same amount of code. So it is good to be DRY before OO.

I wrote a rebuttal

http://csswizardry.com/2012/03/hacker-news-rebuttal/

`Whilst this is a very timid example, it does help illustrate how a lot of preprocessors’ built in ‘helpful’ aspects actually go against our ideals; .nav li a{} could (and should) just be .nav a{}.`

Not if .nav li a{} and .nav a{} are specifically meant to be differing nests. They could but might not 'should'

> Not if .nav li a{} and .nav a{} are specifically meant to be differing nests.

But in the example they aren’t differing nests; if you change your example then obviously it isn’t correct any more.

If you're truly reusing the example from above, shouldn't it be:

  .nav {
    li {}
    a {}
  }

If that's not the case, why is your first "nested" pure CSS example this:

  .nav a {}

instead of

  .nav li a {}

Because `.nav li a{}` is overly specific; that’s my whole point.

EDIT Hold on, I think I get you… My example was an example of someone writing something incorrectly. An example of it being written correctly would indeed be:

    .nav{
        li{}
        a{}
    }

Cool, we're on the same page. =)

Could someone perhaps take the relevant suggestions from this HN discussion and modify a fork of the repo? I would do it myself, but I don't think I am proficient enough at CSS to sift through the comments effectively.

that's good idea. i have written a bunch of my own guidelines which i'm going to beef up with some of these. the problem with creating a list of the 'relevant' suggestions is that it differs for every developer, project and company. someone's 'relevant' may be another's 'pointless'

Some great general rules here, although I don't employ all of them personally, will definitely be using some to beef up my own guidelines. Cheers!

Might as well add a "formatting" section and include some tips on ways to format css. Also tools like procssor.com or cleancss.com

Thanks for this. This is extremely useful for non-designers.

you lost me when you banned IDs. learn how to use specificity properly before claiming you have best practices.

He does know how specificity works, I guess. But he is talking about reusability and inheritance. Still I find the claim way too harsh. I use id's in my CSS occassionally. For #wrapper or #carroussel maybe. It it premature optimization to (re-)write everything to classes. Your HTML should be leading.

Reply on news.ycombinator.com