Skip to content

Instantly share code, notes, and snippets.

@chantastic
Created November 13, 2015 06:04
Show Gist options
  • Save chantastic/0f1641d343b9d51ad7d0 to your computer and use it in GitHub Desktop.
Save chantastic/0f1641d343b9d51ad7d0 to your computer and use it in GitHub Desktop.
Generated by SassMeister.com.
// ----
// 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.
*/
@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.
*/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment