Hacker News new | past | comments | ask | show | jobs | submit login
Sass Guidelines (sass-guidelin.es)
134 points by klapec on Jan 6, 2015 | hide | past | favorite | 54 comments



No leading zeros?! [1] I'm pretty sure most math/engineering fields recommend leading zeros for readability, e.g, NIST: "For numbers less than one, a zero is written before the decimal marker. For example, 0.25 s is the correct form, not .25 s." [2]

If it's to make the resulting css file a byte smaller, shouldn't be the preprocessor be able to strip it out?

[1]: http://sass-guidelin.es/#zeros [2]: http://physics.nist.gov/cuu/pdf/sp811.pdf


Actually I am thinking of changing this. Someone brought the issue on GitHub: https://github.com/HugoGiraudel/sass-guidelines/issues/32. It is currently being discussed.


In a similar vein why do you prefer hex colors in shortened lowercase format? I've been partial to uppercase long form.


This is not in a similar vein. Leading zero's for values less than 1 is the correct way to write values less than 1.

3-character or 6-character hex values is only a matter of optimization (fewer characters, which the compiler should be able to handle), and consistency (having both the 3- and 6-character versions in the same file or definition). Case is personal preference and nothing more.


I agree. Even within the relevant field (front-end development), explicit leading zeros are encouraged. JavaScript code quality tools such as JSHint and JSLint will complain when the leading zero isn't explicit. E.g:

JSHint var foo = .1; // Unexpected '.'.

JSLint var foo = .1; // A leading decimal point can be confused with a dot: '.1'.


+1

The scientist in me... skin crawls when I see a lack of leading zeros.


The non-American, too - as far as I know only in America people are too lazy to put a zero where it makes sense.


Lazy to use zeroes, yet, pretty active downvoting.


Seconding this. Leading zeros are important for decimals because it is extremely easy to miss a single dot. This is less of an issue in the world of fixed width fonts, but I don't really think that's a valid excuse to buck the trend of every other engineering field.


It has been updated.


You still have it here:

    // Yep
    .element {
      color: rgba(0, 0, 0, .1);
      background: hsl(300, 100%, 100%);
    }

    // Nope
    .element {
      color: rgba(0,0,0,.1);
      background: hsl( 300, 100%, 100% );
    }


Fixed, thank you very much. :)


Well done!


This article is a goldmine—well done. I especially appreciate the care that's been taken to explain the rationale behind each suggestion.

I've worked with Sass fairly extensively, and have picked up some of these practices on my own, but not all of them. I'll definitely be consulting this page in the future.


The author, Hugo Giraudel, also writes one of the absolutest best blogs on Sass (http://hugogiraudel.com/). I've been using Sass heavily since 2009 and consider myself a fairly advanced user, but still learn new and useful things from Hugo's blog on a regular basis. This styleguide looks like an awesome compilation and extension of years of blog articles.


I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.


If you haven't seen it, there is this discussion in the issue tracker:

https://github.com/HugoGiraudel/sass-guidelines/issues/28


This is great, also check out http://cssguidelin.es/ on a related note. +1


Looks really nice but it kind of lacks tackling the difficult issues - like guidelines what to put into classes and how to name them to avoid css class soup. By the way the "7-1" foleer organization is not something you would do in a big programming project (organize things by their type but of use instead). There was a nice blog on it that used analogy of "Socks Drawer".


I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane.


I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.


I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.


I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.


I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.


I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane.


I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane.


I have to really disagree about @extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be @included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding @extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with @extend, yes, but in my opinion dryness and single-point-of-change are far more important than in-file discoverability, assuming your project layout is sane.


I have to really disagree about @extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be @included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding @extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with @extend, yes, but in my opinion dryness and single-point-of-change are far more important than in-file discoverability, assuming your project layout is sane.


I have to really disagree about @extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be @included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding @extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with @extend, yes, but in my opinion dryness and single-point-of-change are far more important than in-file discoverability, assuming your project layout is sane.


I have to really disagree about @extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise.

Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be @included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file.

Avoiding @extend file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules.

Discoverability is always going to take a hit with @extend, yes, but in my opinion dryness and single-point-of-change are far more important than in-file discoverability, assuming your project layout is sane.


Very good guidelines, agreeing with 99% of the things and learnt of mix at the same time !


Disclaimer: This is intended as a helpful correction, not nitpicking.

"... France about to move IN Germany" should be "... from France about to move TO Germany"

Cheers -- and thanks for a useful resource! :)


There are a few similar slip-ups in the article; the author is presumably not a native English speaker. However, despite that - and what really motivated me to comment - I find this really well written, and the odd mistake just adds a bit of character. Very impressed.


True, I am not a native English speaker (French here). Doing my best to fix all those tiny typos. Any report appreciated. :)


Now fixed. My apologies for the awful typo. :)


Great resource. I'm about to use Sass again after a hiatus of ~3yrs. Reading through this has been a great refresher on core principles and best practices.


Amazing. This is something that I would happily recommend. I've never seen so mature and deep guidelines and best practices. Kudos to the author.


Looks really nice but it kind of lacks tackling the difficult issues - like guidelines what to put into classes and how to name them to avoid css class soup. By the way the "7-1" foleer organization is not something you would do in a big programming project (organize things by their type but of use instead). There was a nice blog on it that used analogy of "Socks Drawer".


You changed leading zeros in the body, but in the to; dr at the end you didn't.

Great document!


Fixed, thanks!


OMG .... those tabs and leading 0's were holding me back ... now ... i can write great code.

And @while is a complete waste ... i mean ... it is the only thing that seperates it from less but what evez ... i glad i dont use it in my "read Sass" projects ... wtf you mean when designing a web site right?


Why strictly two spaces and no tabs? Ive found this to be a trend I just don't understand.

At my work we have ~30 front end developers and we have a strict tabs only policy, so everyone can use their IDE to choose their tab width depending on how they like it.

Am I missing some benefit?


How does your team successfully enforce a maximum line length while having a tabs-only policy? I know it's possible to do this, but in my experience, most teams I've encountered that have a tabs-only policy end up with lines of code that go on for miles because enforcing a maximum line length while having a tabs-only policy is more difficult than doing so while having a spaces-only policy. Long lines of code are especially annoying to people such as myself who have their editor split into multiple 100-character wide panes.


Interesting I guess the answer to that is we don't have a strict limit? Looking at a library now its all pretty much ~100ish but nothing set in concrete as a rule. That seems a bit restrictive IMO.

Our other coding style rules kind of keep it down generally I suppose, like for SCSS declaring selectors on new lines (like in this styleguide) and in JS keeping callbacks to one level etc..


Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?


Try using gulp, gulp-sass (libsass) and gulp-livereload (LiveReload.) It's almost instantaneous and you do not need to reload the page to see your changes. There's also a Grunt equivalent tool chain, but I find gulp faster and prefer to use code for configuration rather than using Grunt's giant config objects.


Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?


Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?


Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?


Is the primary benefit of SASS to reduce development time? I find it slows me down having to wait for it to re-parsed on every pageview during active development. Does it offer any other tangible benefits?


What is sass?


Its a CSS preprocessor. http://sass-lang.com/

In a nutshell, you write SASS with all sorts of bonus features that CSS doesn't do, and then you compile to CSS.


http://sass-lang.com/

"Sass is the most mature, stable, and powerful professional grade CSS extension language in the world."


OMG .... those tabs and leading 0's were holding me back ... now ... i can write great code.

And @while is a complete waste ... i mean ... it is the only thing that seperates it from less but what evez ... i glad i dont use it in my "read Sass" projects ... wtf you mean when designing a web site right? The fanboyism is intense in the sass community, ggs.




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

Search: