Styling contract
The component-safe styling surface is the <tng-checkbox> host plus the semantic tokens that flow into the internal primitive. Use wrapper classes for layout and host-level custom properties for per-instance styling.
| Surface | Use from consumer CSS? | Purpose |
|---|---|---|
tng-checkbox host | Yes | Per-instance token overrides, layout tweaks, and wrapper spacing. |
Wrapper classes around tng-checkbox | Yes | Card layout, section spacing, helper copy, and grouped presentation. |
.tng-checkbox-root, .tng-checkbox-control | No, not from component-scoped CSS | Internal implementation details. Use headless or ownable when you need direct control. |
data-state, data-invalid, data-focus-visible | No, not from component-scoped CSS | Primitive-level hooks for DOM-owned solutions. |
| Semantic token | Default role |
|---|---|
--tng-semantic-accent-brand | Checked accent color for the checkbox control. |
--tng-semantic-accent-danger | Invalid checkbox accent and validation emphasis. |
--tng-semantic-focus-ring | Focus-visible ring color around the control. |
--tng-semantic-foreground-primary | Primary label copy color. |
--tng-semantic-foreground-secondary | Muted or readonly label tone. |
If a product design needs a fully custom checkbox box, animated indicator, or state-targeted selectors in component-scoped CSS, that is the point to switch to the headless or ownable layer instead of fighting the component wrapper.
User scenario style examples
These examples keep the checkbox API fixed and only swap the surrounding styling system.