Skip to content

Instantly share code, notes, and snippets.

@jesgundy
Created June 27, 2013 18:43
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jesgundy/5879190 to your computer and use it in GitHub Desktop.
Save jesgundy/5879190 to your computer and use it in GitHub Desktop.
Outlining a system for writing Sass.

Sass 'Alphabetization'

I wanted to outline a potential system for organizing Sass declarations. Since Alphabetization has also been a hot topic (of which I am in favor), it outlines how things such as nesting, @extend, @include, and comments would all fall into the same system. This is by no means a perfect system - but after using Sass for a variety of different things, this is the organization I've found that can deal most easily with edge cases.

Please feel free to critique / edit / etc.

Order of Items

  1. Module label - Succinct top-level label for the section of code (if applicable)
  2. Selector
  3. Documentation / Comment Block - As a sublime text user, I like having any documentation nested within top level selectors so that they are hidden with all of the nested content.
  4. @extend - Typically only one of these are used, but if more than one is present, alphabetized
  5. @include's - Alphabetized
  6. Standard CSS Declarations = Alphabetized
  7. Media Query (Includes) - They should be placed immediately following the standard css declarations. Child selectors will house their own Media Query includes.
  8. Child Selectors - Styles applied to children. Be careful not to nest more than necessary! Notice the link selector is not nested inside of the list item. Declarations should continue to be alphabetized.
  9. State Specific Styles - Should be placed below the children to ensure that children styles can be altered as a result of the parent state. (If a media query @include falls into this category, it would be placed here, beneath child selectors.)

Regarding placement of the Media Queries - They are included with the CSS declarations because child elements will contain their own Media Query based styles. We don't want to have to jump back out of a selector to apply styles unless it's necessary - like it is with state specific classes & psuedo-classes. It also helps avoid css specificity conflicts.

Example Code

// Mobule Label
.list-example {
  // Comments / Documentation explaining usage	
	@extend .list-basic;
		
	@include mixins;
			
	properties: values;
	
	@include media-query-mixin {
		properties: values;
	}

	li {
		properties: values;
	}
		
	a {
		properties: values;
	}
		
	&.active-state,
	&:psuedo-state {
		properties: values;
			
		li {
			properties: values;
		}
		
		a {
			properties: values;
		}
	}		
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment