meta

Source

framework/global/scss/components/_meta.scss
framework/brand/nerdworks/scss/components/_meta.scss
framework/theme/saberco/scss/components/_meta.scss
framework/theme/paratura_gaming/scss/components/_meta.scss

Block class name .meta Edit in wp-admin

Example markup

Class-name normaliser

Plan #322 substrate. class_root + class_aliases feed the S2 audit CLI + S3 normaliser. Kind drives downstream branching.

Class root Kind Composition role

✓ Pick both kind + composition role to validate alignment.

BEM elements (canonical)

Operator-locked. S3 normaliser rewrites drift like __heading → __title.

BEM modifiers (canonical)

Operator-locked.

Class aliases (drift catcher) Edit in wp-admin

Past-drift class roots this entry absorbs. S2 audit populates automatically; use wp-admin to review provenance + tune manually. The wp-admin metabox exposes the full mockup relationship UI + date picker + occurrence count.

No aliases recorded yet.

Prompt

Operator-authored guidance for the camcom-design skill — when to use this block, composition rules, brand-variation notes. Saves on blur.

The canonical metadata-row container. Sits inside a card's body slot and holds the per-entity facts: price, stock status, wishlist trigger, add-to-cart button, post date, event location. The structure is consistent — one or more `.meta__row` elements, each holding one or more `.meta__item` elements. Items class-mix with primitives like `.price`, `.icon-cta`, `.button`.

Two row alignment modifiers cover almost every production use: `--inline` (everything left, with gap), `--spaced` (justify space-between, used when a row has a clear left-vs-right split like price-vs-CTA). The item modifiers (`--price`, `--wishlist`, `--cart-button`) carry tiny presentational adjustments specific to those content types — they exist because metadata items have known content kinds, and consistent visual treatment per kind reads better than per-instance tweaking.

Use meta when a block needs a structured cluster of metadata facts. If a block only has one fact (e.g. a date pill), inline markup is fine — don't reach for meta unless there's a row-of-items shape.

## Production examples

Product-card body with two rows — price row and stock row:

```html
<div class="meta">

<div class="meta__row meta__row--spaced breathe breathe--top">
        <div class="icon-cta">
            <span class="icon icon--medium icon-cta__icon">…</span>
            <p class="icon-cta__text">Ready To Ship<br>7 - 10 days delivery</p>
        </div>
    </div>

</div>
```

Tight meta inside a sidebar product-banner (single row, price + CTA spaced):

```html
<div class="meta meta--tight">

</div>
```

Legacy fields (tier, composition role, layout pattern, repeaters)

Pre-MC-plan-#64 schema. Data preserved here for reference. Collapsed into example markup + prompt opportunistically as we walk sections.

Composition role Layout pattern

Purpose Composes with

Elements observed

Modifiers observed

States

Non-canonical elements

Notes

Two-level BEM (`__row`, `__row__item` originally; flattened in the library to `__row` + `__item`). Production CSS still carries `&__row` + `&__item` as siblings, which is the same flattened shape.
`.meta__item` is `width: fit-content` and `white-space: nowrap` by default — meta items are inline metadata facts, not paragraph copy.
On screens below 1400px, `.meta__row` flips to flex-direction:column — rows stack vertically rather than horizontally. Brand themes can override this at narrower breakpoints if needed.
`* + *` margin reset inside `.meta__row` — meta is a contained context; descendants don't inherit ambient vertical rhythm.

Source

Class-name normaliser

Prompt

AI-Assist