+
+
+
Adam Wathan
+
+ Adam is a rad dude who likes TDD, Active Record, and garlic bread with cheese. He also hosts a decent podcast and has never had a really great haircut.
+
+
+ ```
+
+3. Use those classes as "hooks" in my CSS/Less/Sass to style my new markup:
+
+ ```css
+.author-bio {
+ background-color: white;
+ border: 1px solid hsl(0,0%,85%);
+ border-radius: 4px;
+ box-shadow: 0 2px 4px rgba(0,0,0,0.1);
+ overflow: hidden;
+> img {
+ display: block;
+ width: 100%;
+ height: auto;
+ }
+> div {
+ padding: 1rem;
+> h2 {
+ font-size: 1.25rem;
+ color: rgba(0,0,0,0.8);
+ }
+> p {
+ font-size: 1rem;
+ color: rgba(0,0,0,0.75);
+ line-height: 1.5;
+ }
+ }
+}
+ ```
+
+Here's a demo of the final result:
+
+
+This approach intuitively made sense to me, and for a while this is how I wrote HTML and CSS.
+
+Eventually though, something started to feel a bit off.
+
+I had "separated my concerns", but there was still a very obvious coupling between my CSS and my HTML. Most of the time my CSS was like a mirror for my markup; perfectly reflecting my HTML structure with nested CSS selectors.
+
+**My markup wasn't concerned with styling decisions, but my CSS was very concerned with my markup structure.**
+
+Maybe my concerns weren't so separated after all.
+
+## Phase 2: Decoupling styles from structure
+
+After looking around for a solution to this coupling, I started finding more and more recommendations towards adding more classes to your markup so you could target them directly; keeping selector specificity low and making your CSS less dependent on your particular DOM structure.
+
+The most well-known methodology that advocates this idea is [Block Element Modifer](http://getbem.com/introduction/), or _BEM_ for short.
+
+Taking a BEM-like approach, the markup for our author bio might look more like this:
+
+```html
+
+
+
+
Adam Wathan
+
+ Adam is a rad dude who likes TDD, Active Record, and garlic bread with cheese. He also hosts a decent podcast and has never had a really great haircut.
+
+
+
+```
+
+...and our CSS would look like this:
+
+```css
+.author-bio {
+ background-color: white;
+ border: 1px solid hsl(0,0%,85%);
+ border-radius: 4px;
+ box-shadow: 0 2px 4px rgba(0,0,0,0.1);
+ overflow: hidden;
+}
+.author-bio__image {
+ display: block;
+ width: 100%;
+ height: auto;
+}
+.author-bio__content {
+ padding: 1rem;
+}
+.author-bio__name {
+ font-size: 1.25rem;
+ color: rgba(0,0,0,0.8);
+}
+.author-bio__body {
+ font-size: 1rem;
+ color: rgba(0,0,0,0.75);
+ line-height: 1.5;
+}
+```
+
+_[View on CodePen](https://codepen.io/adamwathan/pen/ZJepYj)_
+
+This felt like a huge improvement to me. My markup was still "semantic" and didn't contain any styling decisions, and now my CSS felt decoupled from my markup structure, with the added bonus of avoiding unnecessary selector specificity.
+
+But then I ran into a dilemma.
+
+## Dealing with similar components
+
+Say I needed to add a new feature to the site: displaying a preview of an article in a card layout.
+
+Say this article preview card had a full bleed image on the top, a padded content section below, a bold title, and some smaller body text.
+
+Say it looked exactly like an author bio.
+
+
+What's the best way to handle this while still separating our concerns?
+
+We can't apply our `.author-bio` classes to our article preview; that wouldn't be semantic. So we definitely need to make `.article-preview` its own component.
+
+Here's what our markup could look like:
+
+```html
+
+
+
+
Stubbing Eloquent Relations for Faster Tests
+
+ In this quick blog post and screencast, I share a trick I use to speed up tests that use Eloquent relationships but don't really depend on database functionality.
+
+
+
+```
+
+But how should we handle the CSS?
+
+### Option 1: Duplicate the styles
+
+One approach would be to straight up duplicate our `.author-bio` styles and rename the classes:
+
+```css
+.article-preview {
+ background-color: white;
+ border: 1px solid hsl(0,0%,85%);
+ border-radius: 4px;
+ box-shadow: 0 2px 4px rgba(0,0,0,0.1);
+ overflow: hidden;
+}
+.article-preview__image {
+ display: block;
+ width: 100%;
+ height: auto;
+}
+.article-preview__content {
+ padding: 1rem;
+}
+.article-preview__title {
+ font-size: 1.25rem;
+ color: rgba(0,0,0,0.8);
+}
+.article-preview__body {
+ font-size: 1rem;
+ color: rgba(0,0,0,0.75);
+ line-height: 1.5;
+}
+```
+
+This works but of course it's not very _DRY_. It also makes it a bit too easy for these components to differ in slightly different ways (maybe a different padding, or font color) which can lead to an inconsistent looking design.
+
+### Option 2: `@extend` the author bio component
+
+Another approach is to use the `@extend` feature of your preprocessor of choice; letting you piggy-back off of the styles already defined in our `.author-bio` component:
+
+```css
+.article-preview {
+ @extend .author-bio;
+}
+.article-preview__image {
+ @extend .author-bio__image;
+}
+.article-preview__content {
+ @extend .author-bio__content;
+}
+.article-preview__title {
+ @extend .author-bio__name;
+}
+.article-preview__body {
+ @extend .author-bio__body;
+}
+```
+
+_[View on CodePen](https://codepen.io/adamwathan/pen/ZJepLq)_
+
+Using `@extend` at all is [generally not recommended](https://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/), but that aside, this feels like it solves our problem right?
+
+We've removed the duplication in our CSS, and our markup is still free of styling decisions.
+
+But let's examine one more option...
+
+### Option 3: Create a content-agnostic component
+
+Our `.author-bio` and `.article-preview` components have nothing in common from a "semantic" perspective. One is the bio of an author, the other is a preview of an article.
+
+But as we've already seen, they have a _lot_ in common from a design perspective.
+
+So if we wanted to, we could create a new component named after what they _do_ have in common, and reuse that component for both types of content.
+
+Let's call it a `.media-card`.
+
+Here's the CSS:
+
+```css
+.media-card {
+ background-color: white;
+ border: 1px solid hsl(0,0%,85%);
+ border-radius: 4px;
+ box-shadow: 0 2px 4px rgba(0,0,0,0.1);
+ overflow: hidden;
+}
+.media-card__image {
+ display: block;
+ width: 100%;
+ height: auto;
+}
+.media-card__content {
+ padding: 1rem;
+}
+.media-card__title {
+ font-size: 1.25rem;
+ color: rgba(0,0,0,0.8);
+}
+.media-card__body {
+ font-size: 1rem;
+ color: rgba(0,0,0,0.75);
+ line-height: 1.5;
+}
+```
+
+...here's what the markup for our author bio would look like:
+
+```html
+
+```
+
+...and here's the markup for our article preview:
+
+```html
+
+```
+
+This approach also removes the duplication from our CSS, but aren't we "mixing concerns" now?
+
+Our markup all of a sudden knows that we want both of these pieces of content to be styled as media cards. What if we wanted to change how the author bio looked without changing how the article preview looks?
+
+Before, we could just open up our stylesheet and choose new styles for either of the two components. Now we'd need to edit the HTML! _Blasphemy!_
+
+But let's think about the flip side for a minute.
+
+**What if we needed to add _a new type of content_ that also needed the same styling?**
+
+Using a "semantic" approach, we'd need to write the new HTML, add some content-specific classes as styling "hooks", open up our stylesheet, create a new CSS component for the new content type, and apply the shared styles, either through duplication or using `@extend` or a mixin.
+
+Using our content-agnostic `.media-card` class, all we'd need to write is the new HTML; we wouldn't have to open the stylesheet at all.
+
+If we're really "mixing concerns", shouldn't we need to make changes in multiple places?
+
+## "Separation of concerns" is a straw man
+
+When you think about the relationship between HTML and CSS in terms of "separation of concerns", it's very black and white.
+
+You either have separation of concerns _(good!)_, or you don't _(bad!)_.
+
+This is not the right way to think about HTML and CSS.
+
+Instead, **think about _dependency direction._**
+
+There are two ways you can write HTML and CSS:
+
+1. ~~_"Separation of Concerns"_~~**CSS that depends on HTML.**
+
+ Naming your classes based on your content (like `.author-bio`) treats your HTML as a dependency of your CSS.
+
+ The HTML is independent; it doesn't care how you make it look, it just exposes _hooks_ like `.author-bio` that _the HTML controls._
+
+ Your CSS on the other hand is not independent; it needs to know what classes your HTML has decided to expose, and it needs to target those classes to style the HTML.
+
+ In this model, your HTML is restyleable, but your CSS is not reusable.
+
+2. ~~_"Mixing Concerns"_~~**HTML that depends on CSS.**
+
+ Naming your classes in a content-agnostic way after the repeating patterns in your UI (like `.media-card`) treats your CSS as a dependency of your HTML.
+
+ The CSS is independent; it doesn't care what content it's being applied to, it just exposes a set of building blocks that you can apply to your markup.
+
+ Your HTML is not independent; it's making use of classes that have been provided by the CSS, and it needs to know what classes exist so that it combine them however it needs to to achieve the desired design.
+
+ In this model, your CSS is reusable, but your HTML is not restyleable.
+
+
+CSS Zen Garden takes the first approach, while UI frameworks like [Bootstrap](http://v4-alpha.getbootstrap.com/) or [Bulma](http://bulma.io/) take the second approach.
+
+Neither is inherently "wrong"; it's just a decision made based on what's more important to you in a specific context.
+
+For the project you're working on, what would be more valuable: restyleable HTML, or reusable CSS?
+
+### Choosing reusability
+
+The turning point for me came when I read Nicolas Gallagher's [About HTML semantics and front-end architecture](http://nicolasgallagher.com/about-html-semantics-front-end-architecture/).
+
+I won't reiterate all of his points here, but needless to say I came away from that blog post fully convinced that optimizing for reusable CSS was going to be the right choice for the sorts of projects I work on.
+
+## Phase 3: Content-agnostic CSS components
+
+My goal at this point was to _explicitly avoid_ creating classes that were based on my content, instead trying to name everything in a way that was as reusable as possible.
+
+That resulted in class names like:
+
+- `.card`
+- `.btn`, `.btn--primary`, `.btn--secondary`
+- `.badge`
+- `.card-list`, `.card-list-item`
+- `.img--round`
+- `.modal-form`, `.modal-form-section`
+
+...and so on and so forth.
+
+I noticed something else when I started focusing on creating reusable classes:
+
+**The more a component does, or the more specific a component is, the harder it is to reuse.**
+
+Here's an intuitive example.
+
+Say we were building a form, with a few form sections, and a submit button at the bottom.
+
+If we thought of all of the form contents as part of a `.stacked-form` component, we might give the submit button a class like `.stacked-form__button`:
+
+```html
+
+```
+
+But maybe there's another button on our site that's _not_ part of a form that we need to style the same way.
+
+Using the `.stacked-form__button` class on that button wouldn't make a lot of sense; it's not part of a stacked form.
+
+Both of these buttons are primary actions on their respective pages though, so what if we named the button based on what the components have in common and called it `.btn--primary`, removing the `.stacked-form__` prefix completely?
+
+```diff
+
+```
+
+Now say we wanted this stacked form to look like it was in a floated card.
+
+One approach would be to create a modifier and apply it to this form:
+
+```diff
+-
+```
+
+But if we already have a `.card` class, why don't we _compose_ this new UI using our existing card and stacked form?
+
+```diff
++
+
++
+```
+
+By taking this approach, we have a `.card` that can be a home for any content, and an unopinionated `.stacked-form` that can be used inside of any container.
+
+We're getting more reuse out of our components, and **we didn't have to write any new CSS.**
+
+## Composition over subcomponents
+
+Say we needed to add another button to the bottom of our stacked form, and we wanted it to be spaced out a little from the existing button:
+
+```html
+
+```
+
+One approach would be to create a new subcomponent, like `.stacked-form__footer`, add an additional class to each button like `.stacked-form__footer-item`, and use descendant selectors to add some margin:
+
+```diff
+