Generated by SassMeister.com.

SassMeister-input.scss

// ----
// libsass (v3.2.5)
// ----

/* fighting bem */

/* a simple todo-list. B, E, no M */
.todo-item { color: #eee }

.todo-item__mark { content: '*' }

/*
 * let's introduce some state...
 * the inclination is to use a modifier.
 * but if we do that, we conflate layout modifiers with state modifiers.
 */

.todo-item--small .todo-item__mark { font-size: 80% } /* layout modifer */
.todo-item--complete .todo-item__mark { content: '✔︎' } /* state modifier */

/* SUIT css has an approach raises a unique approach for state. */

.todo-item--small .todo-item__mark { font-size: 80% } /* layout modifer */
.todo-item.is-complete .todo-item__mark { content: '✔'︎ } /* state modifier */

/* This is good but state is sprawling and increases surface area for cascade bugs. */

.todo-item.is-complete .todo-item__mark { content: '✔'︎ }
.todo-item.is-complete .todo-item__name { text-decoration: line-through }
.todo-item.is-complete { color: #aaa }

/* ... only exacerbated with various permutations */
.todo-item.is-due:not(.is-complete) .todo-item__name { color: red }


/* if you're yelling at me because I'm not using Sass: here's what it looks like in sass */

$module: ".todo-item";

#{$module} {
  color: #111;

  &--small {
    font-size: 80%;
  }
  
  &.is-complete {
    color: #aaa;
  }

  &__mark::before {
    content: '*';

    #{$module}.is-complete & {
      content: '✔'︎;
    }
  }

  &__name {
    #{$module}.is-complete & {
      text-decoration: line-through;
    }

    #{$module}.is-due:not(.is-complete) & {
      color: red;
    }
  }
}

/*
 * i'm not personally a fan of Sass.
 * i tend to think that it's more different than it is better.
 * it's defenitely less grepable and has more indirection.
 *
 * sass or not, there as a lot of structure that comes with
 * handling state in a language as declarative as CSS.
 */

/* this is an abjectively trivial example.
 * not only is this a dumb todo-list.
 * it would be the most terrible one ever published.
 * think about adding editability and the minimal changes to ship this.
 * imagine how quickly this objects becomes complicated in a non-trivial app.
 * most of you don't have to imagine...
 * you write non-trivial apps and this has totally fallen over
 */

/* CSS IS NOT EQUIPPED TO HANDLE THE COMPLEXITIES OF LAYOUT AND STATE */

/* If we were able to take all state out of this object, it would be much simpler to reason about */

$module: ".todo-item";

#{$module} {
  &--small {
    font-size: 80%;  
  }
}

/* ...and, at this point SASS doesn't make a whole lot of sense. I'd rather have the grep-ability */

.todo-item--small { font-size: 80% }

/* so, we've removed state—that was easy—where does it go?
 * well, a while ago, a friend of ours was telling us how he was
 * styling his components in react.
 * this seemed more than a little crazy but we started to wonder if
 * it would be a good place just for state styles.
 * i mean, React is already managing the state to show the class
 * if it's performant enough, why not apply the style directly?
 */
 
/* and this works great.
 * not only does it clean of the stylesheet.
 * it gave us testability
 */
 
/*
 * We had to change the way we talked about CSS
 * STYLE IS NOT CSS
 * Separation of "APPEARANCE" and "FUNCTION"
 * Appearance were things like it's size, color, how deep it's border-radius is, etc
 * Function were styles that were a direct result of it's state.
 */

SassMeister-output.css

@charset "UTF-8";
/* fighting bem */
/* a simple todo-list. B, E, no M */
.todo-item {
  color: #eee;
}

.todo-item__mark {
  content: '*';
}

/*
 * let's introduce some state...
 * the inclination is to use a modifier.
 * but if we do that, we conflate layout modifiers with state modifiers.
 */
.todo-item--small .todo-item__mark {
  font-size: 80%;
}

/* layout modifer */
.todo-item--complete .todo-item__mark {
  content: '✔︎';
}

/* state modifier */
/* SUIT css has an approach raises a unique approach for state. */
.todo-item--small .todo-item__mark {
  font-size: 80%;
}

/* layout modifer */
.todo-item.is-complete .todo-item__mark {
  content: '✔'︎;
}

/* state modifier */
/* This is good but state is sprawling and increases surface area for cascade bugs. */
.todo-item.is-complete .todo-item__mark {
  content: '✔'︎;
}

.todo-item.is-complete .todo-item__name {
  text-decoration: line-through;
}

.todo-item.is-complete {
  color: #aaa;
}

/* ... only exacerbated with various permutations */
.todo-item.is-due:not(.is-complete) .todo-item__name {
  color: red;
}

/* if you're yelling at me because I'm not using Sass: here's what it looks like in sass */
.todo-item {
  color: #111;
}

.todo-item--small {
  font-size: 80%;
}

.todo-item.is-complete {
  color: #aaa;
}

.todo-item__mark::before {
  content: '*';
}

.todo-item.is-complete .todo-item__mark::before {
  content: '✔'︎;
}

.todo-item.is-complete .todo-item__name {
  text-decoration: line-through;
}

.todo-item.is-due:not(.is-complete) .todo-item__name {
  color: red;
}

/*
 * i'm not personally a fan of Sass.
 * i tend to think that it's more different than it is better.
 * it's defenitely less grepable and has more indirection.
 *
 * sass or not, there as a lot of structure that comes with
 * handling state in a language as declarative as CSS.
 */
/* this is an abjectively trivial example.
 * not only is this a dumb todo-list.
 * it would be the most terrible one ever published.
 * think about adding editability and the minimal changes to ship this.
 * imagine how quickly this objects becomes complicated in a non-trivial app.
 * most of you don't have to imagine...
 * you write non-trivial apps and this has totally fallen over
 */
/* CSS IS NOT EQUIPPED TO HANDLE THE COMPLEXITIES OF LAYOUT AND STATE */
/* If we were able to take all state out of this object, it would be much simpler to reason about */
.todo-item--small {
  font-size: 80%;
}

/* ...and, at this point SASS doesn't make a whole lot of sense. I'd rather have the grep-ability */
.todo-item--small {
  font-size: 80%;
}

/* so, we've removed state—that was easy—where does it go?
 * well, a while ago, a friend of ours was telling us how he was
 * styling his components in react.
 * this seemed more than a little crazy but we started to wonder if
 * it would be a good place just for state styles.
 * i mean, React is already managing the state to show the class
 * if it's performant enough, why not apply the style directly?
 */
/* and this works great.
 * not only does it clean of the stylesheet.
 * it gave us testability
 */
/*
 * We had to change the way we talked about CSS
 * STYLE IS NOT CSS
 * Separation of "APPEARANCE" and "FUNCTION"
 * Appearance were things like it's size, color, how deep it's border-radius is, etc
 * Function were styles that were a direct result of it's state.
 */