A few ideas for writing maintainable CSS

[stphndxn]

In yesterday's design sync, we spoke a lot about object-orientated design and it feels that this thinking could lead us to some ideas about how we might approach molecular design! This feels great to explore this kind of thinking on the CSS level, too!

A few rules of thumb that we might explore could be:

• Avoid writing DRY code, unless purely coincidental. Try and keep away from writing @extends and @mixins, etc. to avoid making the unrelated related.
• single responsibility and open/close principles
• object-orientated
• separation of concerns

Keen to hear any thoughts on these and to kick-start the conversation! :smile:

[Alex-ray]

Great initiative @stevemdixon love where your going with this!

I sympathize with your thoughts around 'Avoiding writing DRY code for the sake of being DRY', I think this is one of those things that is easy to do with OO design and takes a lot of experience to get good at knowing when you should abstract something vs keep it specific.

In my experience I have found writing Modular CSS quite a bit easier to work with and maintain than OO CSS. They both definitely have their strengths and weaknesses, but I have found modular CSS to describe things in a way that is more in line with how most people think about designing websites.

In particular I have really loved the ideas around Scalable and Modular Architecture for CSS .

I have also really enjoyed the style guides by Google and Airbnb

I hope this gives you some good inspiration, love that you guys are having these conversations and would love to help in any way that I can :smile:

[stphndxn]

Thanks so much for this, @Alex-ray! :grinning: I love writing modular CSS and the Google and Airbnb style guides are awesome! A few ideas that also spring to mind is how we might lay out our properties, too!

Alphabetical

.declaration-order {
  bottom: 0;
  color: #333;
  display: block;
  float: right;
  font: normal 13px "Helvetica Neue", sans-serif;
  height: 100px;
  left: 0;
  line-height: 1.5;
  opacity: 1;
  position: absolute;
  right: 0;
  text-align: center;
  top: 0;
  width: 100px;
  z-index: 100;
}

verus

Box Model

.declaration-order {
  /* Positioning */
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  z-index: 100;

  /* Box-model */
  display: block;
  float: right;
  width: 100px;
  height: 100px;

  /* Typography */
  font: normal 13px "Helvetica Neue", sans-serif;
  line-height: 1.5;
  color: #333;
  text-align: center;

  /* Visual */
  background-color: #f5f5f5;
  border: 1px solid #e5e5e5;
  border-radius: 3px;

  /* Misc */
  opacity: 1;
}

[djfarrelly]

Awesome stuff @stevemdixon + @Alex-ray! I'd love to read through that SMACSS book for some ideas around that. Some quick thoughts as far as maintainability go:

• Love the "box-model" declaration order you mentioned, that's always been a personal fav as it groups things logically. Looking to the top for layout and end for color & other style makes the css easier to scan in my opinion :wink: Scanning an alphabetical list for related items like padding, width and margin force your eye to jump up and down in the list a lot haha
• The concept of "not writing DRY" code is interesting since I always try to be DRYer with js, php etc., but I think it's a good concept. This is yet another opinion, but I think Mixins and Extends are great for agencies who need to re-use mixins to build out a design mockup for a client on the tight deadline and using extend's make the classnames in the HTML cleaner which is great for one-off class extensions, but harder for a maintainable style guide. Using extends and mixins can also lead to a lot of duplicate CSS rules in the final css file :)

Love the convos going here!

[twanlass]

Ahhhhhh so awesome you guys! The fact that we're talking about avoiding DRY CSS already makes me tingle inside. @Alex-ray @stevemdixon and @djfarrelly you've all really hit the nail on the head in my opinion.

Writing modular CSS is fantastic for maintainability, quick iterations and even easily removing code later on without causing a bunch of regressions. It seems so backwards at first (as you mentioned @djfarrelly it's the opposite of what you'd do w/ JS or PHP) but after seeing classes on elements like <div class="blue wide extra-padding with-shadow no-border all-the-things"></div> or having someone inadvertently add a class or two to a mixin that doubles your CSS size overnight the path seems clear :-)

Variables really become the glue for consistency. No need for a .blue mixin when you can simply use the $blue (or better yet, $primary) variable instead. Other defining visual characteristics can also be defined as variables including border-radius and even interaction elements like transition!

A few other thoughts related to writing more maintainable code:

• Small, single responsibility components (as @stevemdixon) are really great.
• Using a solid naming convention (I'll def. add this to the other open discussion) helps to avoid unnecessary nesting and nasty CSS specificity conflicts. There's almost never a need to nest something more than 2 levels deep.
• It feels great to avoid per-view or per-page specific styles. With modular CSS you should be able to drop an element on any page and have it look the same. If there's a special circumstance then modifiers within a component work great here!
• If a component relies on another component for it's style, layout, etc that's a bad code smell :-)
• Avoiding inline styles :-)
• Avoiding CSS within JS or manipulating CSS with JS

Also - :+1: for the box-model declaration order :-)

Keen to hear from others and keep this conversation going!

[stphndxn]

Awesome stuff @stevemdixon + @Alex-ray! I'd love to read through that SMACSS book for some ideas around that. Some quick thoughts as far as maintainability go:

Love the "box-model" declaration order you mentioned, that's always been a personal fav as it groups things logically. Looking to the top for layout and end for color & other style makes the css easier to scan in my opinion :wink: Scanning an alphabetical list for related items like padding, width and margin force your eye to jump up and down in the list a lot haha The concept of "not writing DRY" code is interesting since I always try to be DRYer with js, php etc., but I think it's a good concept. This is yet another opinion, but I think Mixins and Extends are great for agencies who need to re-use mixins to build out a design mockup for a client on the tight deadline and using extend's make the classnames in the HTML cleaner which is great for one-off class extensions, but harder for a maintainable style guide. Using extends and mixins can also lead to a lot of duplicate CSS rules in the final css file :) Love the convos going here!

Awesome thoughts there, @djfarrelly! Since we jammed on this a few months ago, I've transitioned over to the box model way of constructing my classes! :grin: It feels super-natural! :grin: I'm curious as to any feels on spacing the different parts out? Similar to how Mark Otto did here?

I love your and @twanlass' thoughts on mixins and extends, too! This feels great as we might have variables at our disposal to help us out with not writing DRY code! :) Keen to hear more thoughts on this! :grin:

[twanlass]

cc @ivanaszuber. Any other frontend folks we're missing?

[djfarrelly]

Lots of great points @twanlass on specificity and nesting, so key in my mind. Less selector specificity also helps rendering performance in the browser which is a great win.

@stevemdixon, spacing between different parts to me doesn't matter. I guess I've done it when there might be lots of rules, but I don't end up labeling the sections. I don't know if it has to be a requirement, but maybe an option if it proves to be a more readable option!

[twanlass]

Loving the conversation here all! I have a few more thoughts on nesting and specificity :-)

• Class selectors (.some-class) are more efficient than tag selectors (though often a small difference it can add up)
• Class selectors are much less fragile than tag selectors since we often have to nest or scope tag selectors to apply resets or overrides
• Class selectors, while extra markup and more verbose, make avoiding nesting really easy

As a super simple example, say we have the following markup and we want to apply some styles to the list items of the <ul>:

<div class="some-section">
  <ul>
    <li>Some list item...</li>
    <li>...</li>
  </ul>
</div>

Using tag selectors, this becomes very fragile:

.some-section ul { 
  margin: 20px;
  padding: 5px;
  li {
    color: #333;
    font-size: 14px;
  }
}

A class selector however is much simpler, requires no nesting and is very portable (we can move the markup anywhere on the page without it breaking!):

<div class="some-section">
  <ul class="feature-list">
    <li class="feature-list__item>Some list item...</li>
    <li class="feature-list__item>...</li>
  </ul>
</div>

and style it with:

.feature-list { blah }
.feature-list__item { blah }

[stphndxn]

@stevemdixon, spacing between different parts to me doesn't matter. I guess I've done it when there might be lots of rules, but I don't end up labeling the sections. I don't know if it has to be a requirement, but maybe an option if it proves to be a more readable option!

Hehe, awesome! If it feels great to reduce initial line count in our .less files, we might remove the spaces? Super-happy with either approach! :smile:

@twanlass, I absolutely love this approach! I love how descriptive it is and might lend itself well to keeping our CSS files clean? :smile: