GlassCard

When to use

Reach for GlassCard when a chat or focused-flow surface needs to ask the user one thing — name a workspace, confirm a jurisdiction, sign off on a defaulted value — with a clear visual hierarchy of mark → eyebrow → title → body → CTA. The card composes Glass as its outer surface and adds three opinionated slots that match the recipe seen across Matter's "single-question" cards.

Don't use GlassCard for read-only content blocks — use Card instead. Don't use it for long-running provisioning displays — use StagesCard, which is purpose-built for that case.

Anatomy

Three named slots, all optional except Head.title and Foot.action:

• <GlassCard.Head> — mark (32px tile), eyebrow (uppercase 10.5px label), title (14.5px), optional status slot for a pill.
• <GlassCard.Section> — body paragraph or input. tone="muted" renders against a muted paper tint for nested guidance.
• <GlassCard.Foot> — hint (left), action (right — typically a Button).

Props

States

GlassCard itself has no states. Interactive children (inputs, buttons) carry their own contracts.

Tokens consumed

No tokens match.

Background composes from --paper-* ramps via Glass. Hairlines read --ink-5. Title reads --fg. Eyebrow + hint read --fg-soft. The mark tile reads --paper-70 + --ink-5.

Accessibility

• Keyboard interactions. Composed — the inner Button in Foot handles Enter; inner inputs in Section handle their own typing.
• ARIA roles and properties. Generic container. If the card carries a heading, wrap the title in an <h2> at the consumer layer and use aria-labelledby on the outer card.
• Focus order. Head → Section → Foot in DOM order. Tab moves through interactive children only.
• Screen-reader expectations. Eyebrow, title, status, sections, hint, and action are read in order.
• Reduced motion. N/A.
• Forced colors. Hairlines and mark border map to ButtonBorder; backgrounds to Canvas.