Semantic Structure
Explore how Bootstrap 5 semantic parents, sections, cards, and forms fit together in a real page composition.
Role-first structure
Section titled “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
Section titled “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.
App shell
Section titled “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.
Sidebar
Section titled “Sidebar”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
Section titled “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
Section titled “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.
Page header
Section titled “Page header”A page header frames the current workspace or route. It usually combines the page title with an action row or supporting metadata.
Stats banner
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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.