- 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
- Examples: layout, wrappers, containers and other structural components
- 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…
- Utilities are style heavyweights.
- Never reassign to anything that carries a leading
- 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,
- 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…
- 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 .
- 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.
- 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…
- 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…
- 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.