Skip to main content
The three on-page annotation features. Up front: these have a thin customization surface; they have not been migrated to the wireframe-slot system, so there are no wireframe slots and no velt-if/velt-class/velt-data tokens for them. Customize with CSS + props (and, for Tags, a [template] input + headless hooks).

​
Components

Full examples: the per-component pages cover what is customizable in detail: Arrows parts, slots, custom button, and wireframe variables; Area wireframe variables; and Tag wireframe variables.
Tags also expose internal elements <velt-tag-pin> / <velt-tag-dialog> that accept a [template] input for custom rendering.

​
Config props

​
CSS: stateful classes

None beyond host-element theming: these features have no built-in stateful-class table. Target the tag / arrow / area host (and pin) elements directly and theme via --velt-* (override with !important because Velt’s own styles are high-specificity; see CSS). The default area color is #625DF5.

​
Wireframes: slot trees + tokens

Not wireframeable: none of Tags / Arrows / Areas have been migrated to the wireframe-slot system, so there are no slots and no velt-if/velt-class/velt-data tokens (Areas has only one internal portal stub). For Arrows a flat componentConfig.arrowPinAnnotation/user/… exists internally but is not interpolation-live, so you can’t read it in markup yet. Customize via CSS + props (+ hooks for Tags).

​
Headless hooks

​
Limitations

At a glance: what each sub-feature supports: Because there are no slots or hooks (beyond Tags), the right move when a design needs deep customization of arrows/areas is usually a headless-style approach for Tags (render from useTagAnnotations), or accept the default UI + CSS for arrows/areas. Don’t hack Velt’s internal arrow/area DOM to force a layout it doesn’t support: internal DOM can change in any release, so stick to documented classes and treat everything else as unsupported. Use CSS for what’s reachable and leave a comment for the rest.