Loading...

Atomic OOBEMITSCSS in HTML & CSS

View: 527    Dowload: 0   Comment: 0   Post by: hanhga   Category: HTML-CSS template   Fields: Other

People love naming things. And developers love acronyms. And thus here we are, finding ourselves with all of these CSS naming conventions and methodologies: BEM, SMACSS, Point North, ITCSS, OOCSS, Title CSS, Idiomatic CSS, Atomic Design, SUIT CSS, Kickoff CSS, etc.

We often hear “Are you using OOCSS or BEM?” but these things are not mutually exclusive. In fact, most of the time, we’re taking concepts and ideas of the aforementioned ideologies, and mixing them up, customizing them to suit (no pun intended) our own needs.

So what have I been using these days? Well that would be Atomic OOBEMITSCSS. Yep. Atomic OOBEMITSCSS.

The first time I heard this ridiculous term was from a tweet via Dan Eden, who tweeted:

I’m sure he doesn’t even remember tweeting that joke, but the more I thought about it, the more I realized it wasn’t a joke, and it hasn’t left my mind since. OOBEMITSCSS is exactly we’ve adopted, too. That sounds crazy, but it makes sense when you break it down.

Atomic CSS

Let’s Start with Atomic Design. Atomic Design is a systems-thinking methodology solidified by Brad Frost. Upon further research in finding how it relates to styling, I came upon this article on Atomic Sass. While I’m not using the directory structure outlined there, I do use the concepts and ideas expressed by Brad’s Atomic Design methodology in design work and extend them onto my development work (via Sass modules and components).

The gist is basically to design and develop in terms of systems thinking — to create individual molecules or elements which, when combined and placed together, weave a web of modules, components, and eventually entire layout systems. (Officially, there are 5 components to this: atoms, molecules, organisms, templates, and pages) You can start to see this in the following example:

Take this example from my Pinterest board:

card

Here we see a card. This card is made up of a few atoms:

  • caption text
  • header text (pin type)
  • body text (caption)
  • callout text (message)
  • callout text (title)
  • callout image (mini board)
  • source icons
  • local icons
  • numeric treatment
  • main image
  • dividers

These are then pulled together in sets of molecules:

  • Image & Citation (main image + source icon + caption text)
  • Pin Metadata (pin type text + hr + body text + [local icon + numeric treatment] x2)
  • Callout (callout image + callout text (message) + callout text (title))

Those molecules then comprise an organism aka the card itself:

  • (Image & Citation) + (Pin Metadata) + divider + (Callout)

The home page of Pinterest is full of these organisms. They make up a big part of the homepage layout:

Pinterest homepage

These elements are reused and remixed in other places on the site:

Pin It Modal

In the above “pin view” modal (which we see by clicking the “Pin It “button), we see the same treatment as we do on the homepage without the callout on the bottom, and placed in a different context.

Clicking on the Image

This is the view from clicking the image itself. Notice how the same header treatment and on the *type* of pin and source icon follows us throughout both of these views on the site. Atomic design thinking allows us to create modular, consistent design systems.

BEM

BEM is the system I use to mark things up. BEM Stands for Block, Element, Modifier. This is especially useful on a huge team, like the one I am now working within at IBM. I wrote a post about it once, but other people have written better posts since (I can’t believe that was 2013!).

So let’s take a look back at our first example of the card:

card

How would we mark this up? Well we would separate the markup based on its atomic structure first. This means we would start at the most basic level, and extend from there. Let’s isolate a small section to examine its markup. (note: I am intentionally disregarding treatment for links and interaction here in this example, but the ideas for marking those up persist. Using atomic markup allows for easy reuse of script actions whenever building components. I.e. the action for clicking the heart will always change its styling, such as fill color, and increase the hearts-count)

<div class="card">
  <img src="..." alt="..." class="card__source-icon">
  <a href="" class="card__source-link"></a>

  <section class="card__metadata">
    <h2 class="metadata__pin-type"></h2>
    <hr>
    <p class="metadata__caption"></p>
    <span class="metadata__pins"></span>
    <span class="metadata__hearts"></span>
  </section>

  <hr>

  <section class="card__callout">
    <img src="..." alt="..." class="callout__board-preview">
    <p class="callout__msg"></p>
    <a href="..." class="callout__board-title"></a>
  </section>
</div>

These class names are semantic to the content presented, and are broken up by their atomic molecules. Those molecules become the blocks in BEM. We don’t have modifiers in the above example, but if we wanted to separate the metadata of hearts (i.e. if *only* the heart was clickable), for instance (normally I’d just use a pseudo-element for the icon), we could write it like this:

<div class="metadata__hearts">
  <a href="..." class="metadata__hearts--icon"></a>
  <p class="metadata__hearts--count"></p>
</div>

Some argue that this leads to long selectors (it does), but semantically it makes a ton of sense and really cleans up your markup by limiting the number of classes you use. And by limiting I mean, seriously, try to use only **one class per element** if you can. Frankly, I find BEM invaluable for use within teams and works really well in an object-oriented manner (read on friends!).

OOCSS

OOCSS stands for Object-Oriented CSS. From Nicole Sullivan’s OOCSS workshop:

The examples Nicole shows in her workshop use multiple classes to achieve this format, which, at this point, may leave you thinking: “Wait. Doesn’t this contradict BEM?” Nope. It doesn’t have to. We have Sassto make things right :) So it’s less OOCSS and more OOSCSS!

I like to think of the way I write my Sass as Object-Oriented. If we think of the card as an “object” which pulls in various “classes” to comprise it, we can still keep everything nested nice and neat with the use of the almighty ampersand (if you’ve read any of my previous blog posts you’ll know how much I love the ampersand.

Example time! Let’s use the metadata section for this, as it provides a good example of hidden complexity:

<section class="card__metadata">
  <h2 class="metadata__pin-type"></h2>
  <hr>
  <p class="metadata__caption"></p>
  <span class="metadata__pins"></span>
  <span class="metadata__hearts"></span>
</section>

We’ll want to be thinking modularly and in the realm of object-oriented encapsulation. Icons are a great start:

%icon {
  content: '';
  display: block;

  &--pins {
    @extend %icon;
    background-image: url('../img/pins.svg');
  }

  &--heart {
    @extend %icon;
    background-image: url('../img/heart.svg');
  }
}

Woah. What’s going on here? Well A) like I said earlier, I overuse ampersands, so make sure you’re familiar with those. B) We’re creating an invisible (aka “placeholder selector“) in Sass. This means that none of this code is processed into CSS until we @extend it. All of our icons will have some shared properties (in this case, content: ''  and display: block). Then we specify the background-image for each individual icon while *extending* the styled from its parent block. This can be done with a simple @each loop and icons can be organized within a map to make things cleaner. Nothing is being output here, but technically, this is what’s going on behind-the-scenes:

%icon,
%icon--pins,
%icon--heart {
  content: ';
  display: block;
}

%icon--pins {
  background-image: url('../img/pins.svg');
}

%icon--heart {
  background-image: url('../img/heart.svg');
}

So continuing on, let’s see what the block looks like when written in a object-oriented Sassy way. Let’s just get a grounds for some typography that we’ll instantiate in a moment when building out our component:

%font-stack--body {
  // actual Pinterest font stack (!)
  font-family: 'Helvetica Neue','Helvetica','ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ','Meiryo','MS Pゴシック',arial,sans-serif;
}

%font-stack--headers {
  @extend %font-stack--body;
  font-weight: 600; //headers are the same typeface as everything else but have a heavier weight
}

%type--base-body {
  @extend %font-stack--body; //extend the body stack
}

%type--base-h2 {
  @extend %font-stack--headers; //extend headers (which extend body stack and give them a heavier weight)
  font-size: 1.5em; //font-size adjustment
}

And now to the molecule! This is where it gets really delicious:

.metadata {
  &__pin-type {
    @extend %type--base-h2; //extend base header styling
  }

  &__caption {
    @extend %type--base-body; //extending normal body copy
  }

  &__hearts {

    &:hover {
      color: red; //unique hover color
    }

    &:after {
      @extend %icon--heart; // extending heart icon on pseudo element
    }
  }

  &__pins {

    &:hover {
      color: green; //unique hover color
    }

    &:after {
      @extend %icon--pins; // extending pins icon on pseudo element
    }
  }
}

What does that look like in CSS? Despite all of the nesting, we output one single class for everything!

.metadata__pins:after,
.metadata__hearts:after {
  content: ';
  display: block;
}
.metadata__pins:after {
  background-image: url('../img/pins.svg');
}
.metadata__hearts:after {
  background-image: url('../img/heart.svg');
}
.metadata__pin-type,
.metadata__caption {
  font-family: 'Helvetica Neue','Helvetica','ヒラギノ角ゴ Pro W3','Hiragino Kaku Gothic Pro','メイリオ','Meiryo','MS Pゴシック',arial,sans-serif;
}
.metadata__pin-type {
  font-weight: 600;
}
.metadata__pin-type {
  font-size: 1.5em;
}
.metadata__hearts:hover {
  color: red;
}
.metadata__pins:hover {
  color: green;
}

 

Atomic OOBEMITSCSS in HTML & CSS

People love naming things. And developers love acronyms. And thus here we are, finding ourselves with all of these CSS naming conventions and methodologies

Posted on 07-03-2016 

Comment:

To comment you must be logged in members.

Files with category

 
File suggestion for you
Loading...
File top downloads
Loading...
Loading...
Codetitle - library source code to share, download the file to the community
Copyright © 2018. All rights reserved. codetitle Develope by Vinagon .Ltd