Do BEMIT right

[tylersticka]

@calebeby asked me a very simple question in a PR I can't be bothered to look up again right now. I'm paraphrasing, but it boiled down to this:

Why is button an object and not a component?

I thought this would be an easy answer. Pulling up Harry Roberts' namespace article, I re-read his initial description of the object and component namespaces...

• o-: Signify that something is an Object, and that it may be used in any number of unrelated contexts to the one you can currently see it in. Making modifications to these types of class could potentially have knock-on effects in a lot of other unrelated places. Tread carefully.
• c-: Signify that something is a Component. This is a concrete, implementation-specific piece of UI. All of the changes you make to its styles should be detectable in the context you’re currently looking at. Modifying these styles should be safe and have no side effects.

Based on that description, I felt confident in my decision that o-button was correctly namespaced. We use buttons in a bunch of different contexts, and you shouldn't feel 100% confident you aren't breaking something by viewing a single instance of it.

But then further down there was some elaboration:

OOCSS is fantastic in that it teaches us to abstract out the repetitive, shared, and purely structural aspects of a UI into reusable objects. This means that things like layout, wrappers and containers, the Media Object, etc. can all exist as non-cosmetic styles that handle the skeletal aspect of a lot of UI components, without ever actually looking like designed ‘things’.

Uh-oh. That doesn't sound like a button. Buttons have cosmetic styles. They look designed. And later on in that article, Harry shows a sample button class called c-btn. So the guy who invented BEMIT thinks buttons are components.

The problem I thought objects solved

When I read that initial description of objects, I was thinking they solved the Input Group problem.

Y'see, several of our design systems have included an Input Group pattern, where two or more inputs and/or buttons appear unified in a row.

The CSS for these usually looks like this:

.input-group {
  display: flex;
  /* etc. */
}

.input-group__input {
  flex: 1;
  /* etc. */
}

Because computers don't sort things the same way humans do by default, if we import all our components with a glob pattern (@import 'components/**/*.css';), input-group.css would precede input.css in our bundle. This would often cause issues where .input-group__input would not override necessary .input styles unless we manually enforced the source order.

What I thought objects were meant to do was define those low-level components (o-input) as a separate group, followed by specific implementations like (c-input-group).

The problem I think objects are meant to solve instead

Upon re-reading, I now believe objects are really meant to solve a layout problem.

Let's consider issues #474 and #493. Those conversations might yield multiple patterns… an object for everything but the visual elements, with other classes used to specify the content itself:

<div class="o-summary">
  <h3 class="o-summary__headline u-text-grow-1">
    <a class="o-summary__action" href="...">
      ...
    </a>
  </h3>
  <div class="o-summary__object c-thumbnail">
    <img class="c-thumbnail__object" src="..." alt="...">
  </div>
  <div class="o-summary__content">
    <p>
      ...
    </p>
  </div>
</div>

But maybe I have this wrong.

So what?

Currently, o-button, o-icon and the WIP o-table (#557) are all specified as objects. But I believe this is incorrect. If others agree, we should move these to the components namespace instead.

What do others think?

---

@cloudfour/design @cloudfour/dev

[spaceninja]

So the guy who invented BEMIT thinks buttons are components.

I'm satisfied. :)

FWIW, I agree with what you're saying Tyler, that most of our patterns become components.

However, I don't think we should stress ourselves out about this too much — if we get it wrong in a particular case, it's relatively trivial to do a search-and-replace for o-whatever to c-whatever

[tylersticka]

Thanks, @spaceninja! I agree.

I'm updating this issue to be actionable, with these tasks:

• [ ] Move Button and Icon source from objects to components
• [ ] Rename Button and Icon class names so they are namespaced c- instead of o-
• [ ] Update any documentation referring to these patterns as "objects"

[gerardo-rodriguez]

I'm interested in handling this card as a way to "get my feet wet". 🙂

How quickly do we want to turn this around? 🤔

[tylersticka]

@gerardo-rodriguez I've sized the task as a 1 (≤ ½ day), but do you mean how quickly in terms of a calendar date would I like to see this change made?

[gerardo-rodriguez]

but do you mean how quickly in terms of a calendar date would I like to see this change made?

@tylersticka This. 🙂

[tylersticka]

@gerardo-rodriguez That's hard to say. I'd like to see it happen soon-ish, but it's not the end of the world if a couple of patterns remain mis-named for a little while.

[gerardo-rodriguez]

Thanks, @tylersticka. I'll try to see if I can make this happen today. If I'm too bogged down I'll leave a comment saying so allowing others to pick it up. 👍