The short answer
Bricks gives you two places to put styling: directly on the element (ID styles, which affect only that one element) or on a global class (reusable: edit the class once and every element using it updates). Default to classes for anything that might repeat, and keep ID styling for true one-offs. That single habit decides whether your site is easy or miserable to change later.
Every element you click in Bricks offers you a quiet choice, and most beginners never notice they're making it. You open the style panel, change a color or some padding, and move on. But where did that style actually go? By default, onto that one element's ID. And that default, repeated a few hundred times, is how a site becomes something you dread reopening.
What's the difference, in plain terms?
Every element in Bricks has a unique ID, a name that belongs to it alone. When you style an element without selecting a class, your changes attach to that ID. ID styles are like a sticky note on one object: precise, immediate, and completely non-transferable.
A global class is the opposite: a named bundle of styles you create once in the builder and attach to as many elements as you like. Style the class, and every element wearing it updates together, today and every time you edit it in the future. Less sticky note, more uniform.
| ID styles | Global class | |
|---|---|---|
| Applies to | That one element only | Every element you add it to |
| When you edit it | One element changes | All of them change at once |
| Best for | Genuine one-off tweaks | Anything you'll want twice |
Why does everyone fall into the ID trap?
Because in the moment, ID styling is genuinely faster. No name to invent, no decision to make: click, style, done. The builder doesn't stop you, and the page looks exactly the same either way. The cost arrives later, with interest.
Picture twelve buttons styled individually across a site. The client asks for rounder corners. Now you visit twelve elements, make the same change twelve times, and (if you're like the rest of us) miss one, which a visitor will find for you. Multiply that by every repeated pattern on the site and a one-hour restyle becomes a week of archaeology. That is the whole difference: with classes, "change the buttons" is one edit; with ID styles, it's a scavenger hunt.
This isn't a character flaw, and it isn't stupidity. The interface makes ID styling the path of least resistance, so that's the path new users take. Knowing about the fork in the road is most of the fix.
When is styling the ID perfectly fine?
Here's the honest nuance most tutorials skip: one-off tweaks on a single element are fine on the ID. Nudging one image's margin because it sits awkwardly next to a headline, giving one specific section an unusual background: these will never repeat, and inventing a class name for each of them is bureaucracy, not craftsmanship.
If you'd ever want this look twice, it's a class. If you're certain you won't, the ID is fine.
The rule isn't about purity or performance; it's about future edits. Ask "will this look come back?" and put the styles where the answer says.
How should you name your classes?
Simple and role-based. card beats white-box-with-shadow, because names that describe appearance become lies the moment the design changes. That's the same reason we recommend role-based names in our design tokens guide. Name things after what they are, not what they currently look like.
When components have parts and variants, many builders use BEM-style naming, which stands for Block, Element, Modifier, written as block__element--modifier:
- Block: the component itself (
card) - Element: a part inside it (
card__title,card__image) - Modifier: a variant (
card--featured)
Don't treat this as law. The double underscores and dashes aren't magic; they're just a pattern your eyes learn to read, so that months later card__title instantly tells you what it is and where it lives. If full BEM feels heavy, plain role names applied consistently get you ninety percent of the benefit. (More terms like this are decoded in our Bricks glossary.)
What does a good beginner workflow look like?
Build a small kit of classes early, before the site grows around your habits:
- A card class for the box-with-content pattern that appears on almost every site.
- Button variants covering your main button and a secondary style, so every call to action stays consistent.
- A section-spacing class that gives sections their vertical padding, so page rhythm is one edit instead of fifty.
Then follow the repetition: the second time you catch yourself styling the same kind of thing, stop and promote it to a class. Combine this with design tokens and you have the maintainability duo: classes decide where styles apply, tokens decide which values they use. A site built on those two habits can be restyled in an afternoon.
Good to know
One way to absorb good class habits quickly: look at how professional template libraries structure their styling. They ship class-based, not ID-based, styling for exactly the reasons above. Bricksfusion's wireframe and component library generates BEM classes automatically when you copy components, so what lands in your site is already named and reusable.
Bottom line
ID styles and global classes aren't rivals; they're two tools with two jobs. Classes carry every look you'll ever want twice, IDs carry the genuine one-offs, and the moment of discipline is simply noticing which kind of styling you're about to do. Learn that reflex now, while your site is small. It's a five-second decision that saves five-hour afternoons.
FAQ
Questions about this topic
Is it bad to style an element directly on its ID?
Not at all. For genuine one-offs it is the right call. The trap is making ID styling your default for everything, because those styles cannot be reused or updated in one place. Rule of thumb: if you would ever want the same look twice, use a class.
What exactly is a global class in Bricks?
It is a reusable, named set of styles that you create right inside the builder. You can apply it to any number of elements, and when you edit the class, every element wearing it updates at once.
Do I have to use BEM naming?
No. BEM is just one widely understood convention: block__element--modifier, like card__title or card--featured. Any simple, consistent, role-based naming works; the real win is being able to read your own class names six months from now.
How many classes should I create at the start of a project?
A small kit goes a long way: a card, your button variants, and a section-spacing class cover a surprising amount of a site. Create new classes when you catch yourself styling the same thing a second time, not speculatively.