Skip to content

Semantic Structure

Explore how Bootstrap 5 semantic parents, sections, cards, and forms fit together in a real page composition.

Role-first structure

This tour uses a dedicated semantic page so you can read the hierarchy without unrelated project noise. The goal is to see the semantic parents, how they nest, and why starter blocks stay easier to edit once they emit the same roles.

What the role system buys you

A semantic page is easier to reason about because each layer carries intent. Shells hold navigation and workspace chrome, content areas hold sections, sections hold cards or grids, and specialized children like price tags or captions keep the property model focused.

Predictable parents
Content areas, sections, grids, and cards each own a specific part of the page shape.
Predictable children
Insert Child suggestions stay narrower because parents advertise the next useful components.
Starter-compatible
Blocks and hand-built pages meet in the same role vocabulary, so edits scale better.
Choose the parent role
Insert the next semantic child
Adjust the role-specific properties

App shell

The app shell is the full workspace frame. It exists to coordinate larger chrome like sidebars, headers, and the main content surface instead of acting like just another styling wrapper.

Inside the shell, the sidebar owns brand, navigation, quick status, and other persistent navigation helpers. That matters because Insert Child here can offer sidebar-specific children instead of the whole component library.

Content area

The content area is the main parent for page-level information. It is where sections, toolbars, page headers, and other work surfaces belong.

Sections and specialized children

Once you move inside the content area, the hierarchy becomes more task-oriented: banner or header first, then reusable sections, then the specialized children that describe the content inside those sections.

A page header frames the current workspace or route. It usually combines the page title with an action row or supporting metadata.

Stats banner

A stats banner is a specialized section-like surface for high-signal metrics. It gives you a reusable pattern for status-heavy dashboards without losing semantic intent.

Page section

Page sections are the main narrative or workflow blocks of a page. They create a safe parent for section headers, grids, cards, callouts, and other editorial or product content.

Section header

The section header groups the eyebrow, title, and lead paragraph into one reusable editorial pattern. That is why the Properties panel can present section-copy controls instead of generic text styling only.

Feature grid

Feature grids are section children that hold repeating feature items. They are useful when one parent idea needs multiple equal-weight supporting points.

Pricing card

Pricing cards are more specialized than a plain content card because they expect pieces like price tags, captions, benefit lists, and action rows. This is where semantic naming starts paying off in Properties.

Login form

Login form is another specialized semantic surface. Even when it arrives from a starter block, it still exposes the same role-aware identity inside Structure and Properties.

Role-specific properties

Selecting a specialized child like a price tag shows why the role system matters: the Properties panel can focus on the thing the element means, not just on raw classes.

Next steps

Now that the hierarchy is visible, the next practical step is to insert the same children through Structure so you feel how the parent-child suggestions narrow the choices.

Continue with insertion

Next, use the Structure panel to insert semantic children in sequence, then compare that editing flow with starter blocks that already arrive role-first.