WebBlocks UI - Patterns

Shipped pattern families

Sidebar, topbar, and a clear application work area for admin products.

Canonical page headers, form cards, detail lists, action columns, and danger zones for admin create, edit, detail, and index screens.

Auth shell

Focused entry screens for login, registration, and lightweight onboarding.

Settings shell

Structured settings navigation with a dedicated content region.

Content shell

Readable widths and strong hierarchy for docs, guides, and editorial pages.

Breadcrumb

Semantic hierarchy paths for page headers, docs surfaces, and calmer public-site context.

Gallery

Equal-tile inline media collections with an optional shared modal viewer boundary.

Cookie Consent

Reusable public-site consent banner, floating card, and shared modal preference-center pattern.

Marketing

Public-facing landing pages, hero composition, proof sections, and calmer promotional rhythm.

Try markup before you integrate Use the Playground when you want to test HTML-only pattern fragments with the real WebBlocks CSS, icons, and JavaScript before moving them into a real project.

Pattern-first means starting from page purpose

Start from the page job If the question is "I need an admin dashboard" or "I need a docs surface," the answer should begin with a pattern. Primitive choice comes after that.

Need hierarchy?Use a page header stack

Page structure should express optional breadcrumb, required title, optional subtitle, and optional action row.

Need an application shell?Use dashboard shell

Do not compose every application page from raw cards before the frame is decided.

The pattern flow stays short

Pick a pattern familyChoose the closest real page job before thinking about individual controls.

Copy the visible structureTake shell, header rhythm, content blocks, and actions together instead of rebuilding the frame by hand.

Replace content, then trim hardKeep only the sections and primitives the real page actually needs.

Confirm primitives and rulesUse the primitives and JavaScript references only after the pattern direction is already clear.

Reusable section nav

`wb-section-nav` is the canonical local navigation pattern for settings rails, docs side navigation, and section-level page indexes. When links target real in-page anchors, runtime should own the active state.

Overview keeps the local context visible while you read.

Installation can become active from hash navigation or scroll position.

Patterns stays inactive until it becomes the current reading section.

Pattern boundary Use `wb-section-nav` for local section switching inside a page or shell. It is not the global sidebar, not breadcrumb, and not a replacement for primary application navigation.

Admin standards

What it covers

Use the standard for page-level headers, breadcrumb hierarchy, grouped form sections, field help and errors, detail pages, row actions, and bottom-of-page danger zones.

The preferred markup leans on existing wb-card, wb-field, wb-action-group, and breadcrumb primitives, then adds only the smaller admin-specific contracts that do not already exist.

Core rule Keep navigation and context actions in the page header. Keep create and save actions in the card or form footer that owns the submitted fields.

Open admin standards page See dashboard example

Example: page header stack

Hierarchy rule Product identity belongs first in the topbar. Context comes second. Inside the page header, breadcrumb is optional, title is primary, subtitle is supportive, and actions stay separate.

Breadcrumb pattern

wb-breadcrumb is the canonical semantic path pattern for hierarchy context. It keeps separators in CSS, uses ordered list semantics, and stays quiet enough for both admin and public pages.

Open breadcrumb pattern page Open playground starter

Gallery pattern

wb-gallery is the canonical inline media pattern. When the content needs immersive viewing, the same gallery expands into one shared wb-modal in a content-first mode instead of inventing a second top-layer primitive.

Open gallery pattern page

Workspace dashboard with KPI cards and analytics charts — Overview dashboard

Team collaboration session around a product planning table — Team planning

Marketing analytics chart with performance breakdowns on a laptop screen — Performance detail

Single-modal rule A gallery can have many inline items, but the viewer should use one shared modal so active item state, keyboard navigation, and focus return all stay coherent.

Cookie Consent pattern

wb-cookie-consent is the reusable consent pattern for public-site banners or floating cards paired with one shared wb-modal preference center. It stays HTML-first, stores consent only, and requires a reopen hook such as a footer Cookie settings button.

Open cookie consent pattern page

Overlay boundary

What belongs to patterns

Patterns decide where an overlay trigger belongs in the page flow: header actions, table rows, gallery items, settings help links, or editorial media blocks.

What does not

The focus-above-page shell itself is not a page pattern. Use the shipped wb-modal primitive instead of creating shell-local wrappers, whether the job is a decision dialog, form modal, or gallery viewer.

Infrastructure vs public patterns wb-overlay-root is the shared top-layer infrastructure. Public top-layer work belongs to wb-modal; gallery viewer and lightbox behavior are modal usage modes, not separate primitives.

Pattern boundaries

Patterns are not utilities

A pattern is not a spacing trick or a one-off helper class.

Patterns are not single controls

A button, input, or modal is a primitive, not a pattern.

Patterns stay readable

The goal is to make page type and hierarchy obvious before small refinements begin.