Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

BEMIT cheatsheet


  • o-: Object
    • Objects are abstract.
    • They can be used in any number of places (places you might not have seen).
    • Avoid modifying their styles.
    • Be careful around anything with a leading o-.
    • Examples: layout, wrappers, containers and other structural components
  • c-: Component
    • Components are implementation-specific bits of UI.
    • They are quite safe to modify.
    • Anything with a leading c- is a specific thing.
    • Examples: property, user profile, gallery item…
  • u-: Utility
    • Utilities are style heavyweights.
    • Never reassign to anything that carries a leading u-.
    • They commonly have a single responsibility.
    • They commonly use !important to ensure enforcement.
    • They’re only one step away from inline styles; use them sparingly.
    • Examples: column, clearfix,
  • t-: Theme
    • Theme namespaces are very high-level.
    • They provide a context or scope for many other rules.
    • It’s useful to signal the current condition of the UI.
    • Examples: Modifiers changing font-size, colors consistently throughout the website…
  • s-: Scope
    • Scopes are pretty rare: make triple sure you need them before using them.
    • They rely entirely on nesting, so make sure people are aware of this.
    • If you don’t know where to use them, you’re probably searching for something elsegit .
  • is- & has-: State
    • States are very temporary.
    • Ensure that States are easily noticed and understood in our HTML.
    • Never write a bare State class.
    • Examples: open or closed menus, active or inactive tabs, etc.
  • _, Hack
    • Hacks are ugly. Give them ugly classes.
    • Hacks should be temporary, do not reuse or bind onto their classes.
    • Keep an eye on the number of Hacks classes in your codebase.
    • Examples: isolated pixel-perfect properties, specific heights…
  • js-: JavaScript
    • JavaScript and CSS are separate concerns. Use separate hooks for them.
    • Giving different teams/roles different hooks makes for safer collaboration.
    • “we should never have styling and behaviour bound to the same hooks”
    • Examples: Modal windows, tabs, dropdown menus…
  • qa-: QA
    • Binding automated UI tests onto style hooks is too inexplicit. Don’t do it.
    • Bind tests onto dedicated test classes.
    • Ensure that any UI refactoring doesn’t affect the QA team’s hooks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment