Layout Patterns

Shared Site Chrome

Navigation bars

Use one shared nav data source for logo, links, dropdown groups, icon links, and optional CTA buttons.

nav topo json

{
  "header": { "component_type": "nav", "logo": { "image_src": "/images/logo.svg", "link": "/" } },
  "data": [
    { "title": "Docs", "link": "/docs" },
    { "title": "Components", "link": "/components", "children": [] },
    { "title": "GitHub", "link": "https://github.com", "icon_svg_path": "..." }
  ]
}

header.logo

Object

Brand image, title, subtitle, and link.

data[].title

String

Primary link label.

data[].children[]

Array

Dropdown items when needed.

data[].icon_svg_path

SVG path

Icon-only or icon-enhanced links.

section mapping text

component_type = nav
section.container = "antsand-nav antsand-topnav-dark"
data_mapping.api_data = [ ["api_data"], ["databoard", "menu", "stylesdoc_topnav"] ]

Section Header

Hero and intro banners

Most hero sections are only header data plus optional CTA and body stats/cards. The H/B/F shell already handles this.

hero topo json

{
  "header": {
    "span": ["Version 2.0"],
    "h1": "Your AI builds pages from data",
    "p": ["Readable copy goes here."],
    "cta": [{ "title": "Get Started", "link": "/docs" }]
  },
  "data": [{ "h3": "400+", "p": "utilities" }]
}

header.span[]

Array

Badges/kickers.

header.h1

String/HTML

Main headline.

header.p[]

Array

Lead paragraphs.

header.cta[]

Array

Hero buttons.

H/B/F design note text

If the visual has two separate rhythms, use two sections with shared background classes instead of forcing one giant section.

Repeated Body Data

Cards, features, stats, testimonials

A card layout is usually data[] repeated into sub-containers. Sass v2 gives the parent pattern; utilities tune spacing.

card data json

{
  "data": [
    { "icon": "⚙", "h3": "Compiler", "p": "Turns data into generated pages." },
    { "icon": "🎨", "h3": "Sass v2", "p": "Reusable visual system." }
  ]
}

data[].icon

String/SVG

Visual marker.

data[].h3

String

Card title.

data[].p

String/Array

Card text.

data[].ul / data[].ol

Array

HTML-aligned list data.

field CSS text

data.container = "antsand-grid antsand-grid-3 gap-6"
data.content_wrapper = "antsand-card antsand-card-shadow"
data.h3 = "antsand-card-title"
data.p = "antsand-card-text"

Commerce Pattern

Pricing and checkout cards

Pricing sections are card grids with price, feature lists, CTA, and optional product/store identifiers for checkout.

pricing data json

{
  "data": [
    { "h3": "Premium", "price": "$9", "ul": ["Archive", "Member posts"], "cta": { "title": "Subscribe", "link": "/membership/checkout" } }
  ]
}

data[].price

String

Rendered by pricing/card variants.

data[].ul[]

Array

Plan feature list.

data[].cta

Object

Checkout or signup action.

data[].product_id

String

Optional ecommerce binding.

pattern text

Use a normal card section first. Promote repeated checkout-specific markup into a payment/checkout template only when needed.

Application Input

Forms and application flows

Forms should reference a Form Builder configuration. The page section maps the form mount and server-owned context.

form mount json

{
  "header": { "h2": "Set your password" },
  "data": [
    { "form_hash": "...", "form_mode": "application", "context": { "email": "%%form_context.email%%" } }
  ]
}

data[].form_hash

String

Form Builder identity.

data[].form_mode

String

Generic, application, login, checkout, etc.

context.*

Object

Server-owned values like readonly email.

submit target

URL

HMVC/API endpoint.

source of truth text

The form UI defines fields. HMVC owns sensitive context. Runtime JS submits to the configured endpoint.

Structured Data

Tables and comparison grids

Use table data when rows/columns matter. Sass v2 controls variants; JS can add sorting/search/pagination.

table data json

{
  "header": { "h2": "Table variants" },
  "data": {
    "columns": ["Class", "Purpose", "Variant"],
    "rows": [["ant-table--material", "elevation", "material"]]
  }
}

data.columns[]

Array

Table headers.

data.rows[][]

Array

Table body rows.

header.table_variant

String

Material, glass, striped, corporate, etc.

data-table-module

Attribute

Opt in JS behavior.

datatable text

component_type = datatable
styles = ["antsand-v2"]
js = ["antsand-v2"]

Interactive Contracts

Tabs, accordions, dropdowns

Interactive components need exact classes and data attributes. Templates exist so agents do not invent incompatible markup.

tabs data json

{
  "data": [
    { "tab_title": "Overview", "h3": "Overview", "p": "Panel content." },
    { "tab_title": "Details", "h3": "Details", "p": "More content." }
  ]
}

data[].tab_title

String

Tab trigger.

data[].accordion_title

String

Accordion trigger.

data[].dropdown_title

String

Dropdown trigger.

data[].body

Object/String

Panel content.

contract text

Interactive components are not just CSS. The template must output the required class/data attributes for JS.

Images and Motion

Gallery, carousel, video cards

Media layouts are repeated assets with captions, links, optional lightbox/carousel behavior, and responsive image classes.

gallery data json

{
  "data": [
    { "img_src": "/images/a.jpg", "h3": "Image title", "p": "Caption", "link": "/gallery/a" }
  ],
  "header": { "gallery_layout": "masonry" }
}

data[].img_src

URL

Image asset.

data[].h3 / p

String

Caption data.

header.gallery_layout

String

Grid, masonry, carousel, collage.

data[].video_url

URL

Optional video source.

media contract text

component_type = gallery | carousel | youtube
Use Sass v2 classes for layout and JS only when interaction is needed.

Shared Reference

Footer systems

Footers should be shared references or copied from global sections, then normalized before deploy so deployment stays dumb.

footer topo json

{
  "header": { "h1": "ANTSAND", "p": "AI-readable CSS contracts." },
  "data": [
    { "h3": "Framework", "links": [{ "title": "Docs", "link": "/docs" }] }
  ],
  "footer": { "p": "Open Source CSS Framework" }
}

header.h1 / p

String

Brand block.

data[].links[]

Array

Footer link groups.

footer.p

String

_isReference

Boolean

UI/API marker before normalization.

global reference text

Resolve global references before deploy. Deployment reads expanded datalist only.

Application Shell

Dashboard, account, member pages

App pages combine shared nav, sidebar/action rail, content cards, tables, forms, and role-based HMVC actions.

dashboard page json

{
  "hmvc": { "module": "subscriber", "controller": "Dashboard", "action": "index", "acl": ["Premium", "Ultra"] },
  "sections": ["shared_nav", "dashboard_summary", "recent_activity", "shared_footer"]
}

hmvc.acl[]

Array

Role access.

data[].metric

String/Number

Summary cards.

data.rows[]

Array

Activity/table data.

actions[]

Array

Account actions and links.

page composition text

Use multiple sections: nav -> hero/summary -> table/form/content -> footer. Do not force the whole app page into one component.

Layout Patterns

header.logo

data[].title

data[].children[]

data[].icon_svg_path

header.span[]

header.h1

header.p[]

header.cta[]

data[].icon

data[].h3

data[].p

data[].ul / data[].ol

data[].price

data[].ul[]

data[].cta

data[].product_id

data[].form_hash

data[].form_mode

context.*

submit target

data.columns[]

data.rows[][]

header.table_variant

data-table-module

data[].tab_title

data[].accordion_title

data[].dropdown_title

data[].body

data[].img_src

data[].h3 / p

header.gallery_layout

data[].video_url

header.h1 / p

data[].links[]

footer.p

_isReference

hmvc.acl[]

data[].metric

data.rows[]

actions[]

ANTSAND

Framework

Integration

Ecosystem