Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: