The Style System
Purpose: Deliver visual variants of components through policies and CSS classes instead of code forks.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Frontend engineers | Variant mechanics |
| All engineers | Governance of visual variety |
How it works
A component's template policy defines named styles, each mapping to CSS class(es). Authors pick styles in the editor (brush icon); AEM adds the classes to the component's decoration element. Your CSS does the rest.
Policy "PHI plan card":
Style group "Appearance" (single-select):
"Standard" → (no class)
"Featured" → cmp-plancard--featured
"Compact" → cmp-plancard--compact
Style group "Badges" (multi-select):
"Gold trim" → cmp-plancard--goldWhy this beats alternatives
| Alternative | Problem |
|---|---|
| Dialog dropdown "variant" field | Logic leaks into HTL; authors can't preview; not policy-governed |
| Separate components per variant | N components to maintain for CSS-only differences |
| Authors adding free-form classes | Ungoverned, breaks on refactor |
Style System keeps variants CSS-only, named, governed per template — designers define the menu, authors choose, code stays single.
Engineering rules
- BEM-style modifier classes (
cmp-plancard--featured) owned by the component's CSS in ui.frontend. - Style names are author-facing vocabulary — "Featured", not "mod-v2-alt".
- If a "style" needs different markup or data, it is not a style — it's a selector variant or another component.
- Document available styles per component (a styles page in your living style guide) so template editors configure policies consistently.