# RealPlus Web Components — Usage Guide > Generated from the component source. The structural facts (tags, attributes, slots) are > extracted by the Custom Elements Manifest analyzer and cannot drift from what ships; the > prose and examples are curated. See `manifest.json` for the machine-readable version. ## What this is A library of presentational `rp-*` custom elements an LLM drops into report HTML. They are dependency-free native web components: paste the small runtime + the components you use inline (see **Setup**), write the tags, and they render the polished, on-brand result. The components are pure presentation — they never fetch data or own report logic; you supply the data as **attributes and nested children** (there is no JavaScript-property API). ## Machine-readable schema Every tag, its attributes (with accepted enum values + defaults), slots, and carrier child elements are exported as a schema you can read instead of guessing — it is generated from the component source and cannot drift from what ships: - `manifest.json` — the curated, compact schema (this guide is generated from it). Start here. - `custom-elements.json` — the raw Custom Elements Manifest from the analyzer. The per-component reference under **Components** below is that same schema rendered as prose. ## Setup There are **no external scripts or stylesheets** — everything is pasted inline, so a report renders inside a previewer whose security policy blocks every external origin. You paste three things, all available under `examples/components/`: 1. The runtime prelude `rp-base.js` (once) — defines the tiny `el()`/`RpElement` runtime. 2. The components you use (`rp-card.js`, `rp-table.js`, …) — each a self-contained block ending in `customElements.define(...)`. Order among them does not matter. 3. The styles — `tokens.css` + `base.css` (once) plus each used component's `.css`. Put 1+2 in one plain ` ``` `examples/self-contained.html` is a complete worked file assembled exactly this way — open it to copy the whole pattern. `examples/components/HOW-TO.md` is the step-by-step guide. ## Theming & colors All color (and spacing, type, radius) is driven by `--rp-*` CSS custom properties defined in `tokens.css` (the design-token file you paste). **Open it to see every variable.** It has two tiers: - **Primitives** — raw color ramps (`--rp-accent-600: #1570ef`, `--rp-gray-800`, …). The paint palette; components never read these directly. - **Semantic roles** — what components actually read; they point at primitives and carry meaning: `--rp-fg-primary` (body text), `--rp-fg-brand` / `--rp-bg-brand` / `--rp-bg-brand-subtle` / `--rp-border-brand` (the accent), `--rp-bg-primary` (page), etc. Change a role once and everything using it shifts together, consistently. Two ways to recolor, broadest to most surgical: 1. **Recolor the brand for a whole report** — set the semantic brand roles on a scope (the `rp-report` is the natural place); everything beneath re-skins: ```html … ``` 2. **Override one role** — change a single purpose, e.g. the page background: ```html … ``` > Prefer overriding **semantic roles** over primitives. A semantic role declared on `:root` > resolves against `:root`, so re-pointing only a primitive at a lower scope may not flow > through — set the role you want directly. ## Composition model Two ways to configure a component, usable together: - **Nested children (slots)** — *what pieces appear and where*. Place an `rp-media`, an `rp-fields`, an `rp-chip` inside an `rp-card`. - **Attributes** — *how pieces are arranged*: density, columns, alignment, variant. Every component degrades gracefully: missing/partial/unknown input falls back to a safe default and never breaks the layout. Unknown attribute values are ignored. ## Authoring pattern: data first, then render **For reports with repeated content — several listing cards, many table rows — define the data first as plain JavaScript, then render it into `rp-*` markup in a separate step.** Do not hand-write each repeated card or row. Put a `