# Block

A block is a skeletal component or organisational structure. To compare it to common user interface elements: it is a card element or a button element.

A block is skeletal because by the time you get to the block-level in CUBE CSS, most of the work has already been done by the global CSS, composition and utility layers.

This means that a block’s role is less like BEM, where everything is styled inside a block, but instead, it is a mechanism of running against the grain of the global CSS, composition and utility layers. This creates a light, but specific group of rules that only apply in that context.

# No formal element syntax

In BEM, an element contains a double underscore, like this: .my-block__my-element. In CUBE CSS, this doesn’t have to apply, if you don’t want it to.

This is because again, by the time you get to the block-level in CUBE CSS, most of the work has already been done by the global CSS, composition and utility layers, so formal element declaration is mostly redundant.

Inside a block, you can do whatever you want because you have the safety net of the parent block class (.my-block) which adds one extra specificity point for you (opens new window).

With all of this in mind, you could have selectors that look like this:

.my-block {
}

.my-block .image {
}

.my-block .content {
}

You could even target HTML elements:

.my-block {
}

.my-block img {
}

.my-block article {
}

The important thing is consistency. How you achieve that consistency is up to you and your team.

# Composition within blocks

It is advised that you approach the internals of your block with a composition layer. Let’s use a card as an example.

A card element with an image, heading and paragraph

A standard edition card element.

Inside this card’s content area, we have a heading and some content. Using a flow utility, we create a block-level composition layer, which means that any content should be supported in this element.

A card element with an image, list and then another image

Thanks to composition, any content will work fine.

This all ties-back to hinting the browser with flexible rules, rather than micro-managing it. This mantra is why CUBE CSS helps to create really scalable front-ends.

# What should a block do?

  1. Extend the work already done by the global CSS, composition and utility layers
  2. Apply a collection of design tokens within a concise group
  3. Create a namespace or specificity boost to control a specific context

# What shouldn’t a block do?

  1. Grow to anything larger than a handful of CSS rules (max 80-100 lines)
  2. Solve more than one contextual problem. For example: styling a card and a button in one file