Skip to content

Instantly share code, notes, and snippets.

@s10wen
Last active September 22, 2016 15:51
Show Gist options
  • Save s10wen/0318e2cc46074eaae7a70fd27691abb4 to your computer and use it in GitHub Desktop.
Save s10wen/0318e2cc46074eaae7a70fd27691abb4 to your computer and use it in GitHub Desktop.
Sass Nesting using &
  1. Nesting:
.anElement {

  &_aBlock {
    …
  }

  &_anotherBlock {
    …
  }

  &_anotherBlockAgain {

    &:hover {
      …
    }
  }
}
  1. Limiting Nesting to Pseudo Elements:
.anElement {
  …
}

.anElement_aBlock {
  …
}

.anElement_anotherBlock {
  …
}

.anElement_anotherBlockAgain {

  &:hover {
    …
  }
}
@DaveKin
Copy link

DaveKin commented Jun 8, 2016

LONGHAND ALL THE THINGS!

Seriously - production source code should be a work of art, in structure, conventions, comments, accuracy.

Source code will inevitably need to be picked up and worked on by other people at some point (unless it's a private project that you actually want to be unfathomable).
Optimisations change over time as the browser landscape, protocols and server technology changes, accurate source code means that build systems can handle the changing requirements for optimisation.

.foo {
  &__bar {
  }
}

is fine if you're just throwing some styles together but in a large project, if I jump to: &__bar { ... on line 250 of a file, I need to scroll to the top to check which block I'm working in.

@s10wen
Copy link
Author

s10wen commented Jun 8, 2016

@csswizardry agreed, being able to easily find an element is the biggest win for me for a large project.

@13twelve
Copy link

The ability to search a codebase for a class name is super important.

anElement will be repeated in your output a number of times anyways, so being DRY I'm not sure is really a concern here.

My vote - no nesting except pseudo selectors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment