classic298/open-webui-plugins/inline-visualizer-v2

Inline Visualizer

This is the handbook/tutorial on how to use the visualizer tool. The visualizer tool can render rich interactive visuals directly inline in chat using visualize.

How to use

you called the view_skill() tool to read the tutorial/handbook about this tool. Read the entire handbook carefully and follow the rules closely, otherwise the visualizations might end up not rendering properly or being entirely broken. This tutorial/handbook shows you how to actually use the tool and build beautiful visualizations.

1. Call visualize(title="…") - YOU MUST CALL THE TOOL, otherwise the visualization you output will not be rendered in the chat.
2. Calling the tool, an iFrame wrapper sandbox will immediately appear inside the chat (visible only to the user). This iFrame sandbox will AUTOMATICALLY paint/render everything you output within the tags after you called the tool.
3. After calling the tool, start with the opening tag @@@VIZ-START on its own line
4. Next, after the opening tag, emit the HTML/SVG content (no <!DOCTYPE>, <html>, <head>, <body>)
5. Once you are done writing the code for the visualization, immediately close with @@@VIZ-END on its own line, followed by ONE EMPTY LINE. Without the empty line, markdown in your follow-up text (bold, lists, links) is not rendered.
6. Done! The visualization is complete. Continue with any follow-up text to the user.

The raw markers + SVG source are auto-hidden from the chat — users see only the rendered iframe filling in live.

Example response structure:

""" I'll visualize the attention mechanism for you.

@@@VIZ-START <svg viewBox="0 0 680 240"> <!-- content streams here, renders live --> </svg> @@@VIZ-END

As you can see, each query token attends to all key tokens simultaneously. """

Streaming rules:

• Use the delimiters EXACTLY @@@VIZ-START and @@@VIZ-END — case-sensitive, on their own lines, with an empty line after @@@VIZ-END before any follow-up text. Do NOT put the content inside ```, ~~~, or ::: fences or any codeblock or other markdown.
• Do NOT wrap in HTML tags like <viz> or <svg data-iv> — only the text markers are detected.
• Emit exactly ONE @@@VIZ-START … @@@VIZ-END pair per tool call. For multiple visualizations, call the tool multiple times.
• Structure the content as always: <style> first → visible content → <script> last.
• Do NOT describe the HTML source in prose — users don't see it. Describe what the visualization shows.
• Requires iframe Sandbox Allow Same Origin in Open WebUI Settings → Interface. If disabled, the wrapper shows a notice — and the user won't see the visualization itself, just the notice.
• Any <script> you include runs once, after the full block has streamed in.

What's auto-injected

• Theme CSS, SVG classes, color ramps, height reporting, sendPrompt() bridge, and openLink() bridge
• Pre-styled bare-tag form elements (see below) — saves tokens on simple forms
• Consider making diagrams conversational with sendPrompt() — see the "sendPrompt bridge" section further below for patterns and examples

Pre-styled form elements

These tags get theme-aware default styling when emitted without a class or inline style attribute. Other attributes (placeholder, value, id, aria-*, min/max, etc.) are fine — they don't disable the defaults. Adding class or style is treated as an opt-out: the default is suppressed and you can style it from scratch. Useful for short forms or quick UIs where the design doesn't need to deviate.

Pre-styled elements included in the tool:

• <button> — themed button. Use it for actions.
• <input type="text|number|email|search|password|tel|url|date|time|datetime-local"> — themed text input. Use it where a user types or picks a value.
• <input type="range"> — slider. Use it for "from–to" picks, intensity dials, or any continuous value where exact precision doesn't matter.
• <input type="checkbox">, <input type="radio"> — multi-pick / single-pick. Self-explanatory.
• <textarea> — multi-line text input.
• <select> — dropdown. Use it when a list of choices is too long for radios.
• <label>, <fieldset>, <legend> — form structure. Group related inputs and label them.
• <kbd> — keyboard-key cap. Use it whenever you mention a shortcut, so the key visually pops as a key.
• Mac: <kbd>⌘</kbd><kbd>K</kbd>
• Windows / Linux: <kbd>Ctrl</kbd><kbd>K</kbd>
• <hr> — horizontal divider. Separate sections inside a card or between groups of content.
• <details> / <summary> — collapsible disclosure. Use it for progressive disclosure: hide secondary detail behind a clickable summary so the surface stays clean.
• <blockquote> — pull-quote / callout. Use it to set apart a quote, an aside, or a piece of context the reader should pause on.
• <table> (with <thead> / <tbody> / <th> / <td> / <caption>) — tabular data with multiple columns and rows. Use it when the relationship between rows and columns matters. For numeric columns add align="right" or class="num" to the cells (right-aligns + tabular-nums).
• <mark> — highlighter. Use it sparingly to draw attention to a key word or number inside a sentence.
• <dl> / <dt> / <dd> — definition lists. Far cheaper than tables for label/value layouts. Three modes:
• Bare <dl> → stacked glossary. Best when each term needs a sentence or two: definitions, FAQs, term-explained-below.
• <dl data-layout="grid"> → two-column card. The lightweight alternative to a table when you have key/value pairs and don't need row separators or hover: contact cards, metadata blocks, summary panels, settings rows.
• <dl data-layout="inline"> → pill row of label: value pairs (wrap each <dt>/<dd> in a <div>). Best for a tight strip of facts at the top of a card or near a chart: small numbers, status flags, tags. Colon separator is added automatically via CSS.

Bonus on bare elements:

• aria-invalid="true" paints a danger-colored border on input/textarea/select
• :focus-visible keyboard focus draws a clear --accent outline (mouse focus stays subtle)

Accent color palette

The default accent is purple. Switch to one of the other ramps via the data-accent attribute. The chosen color drives --accent and --accent-foreground, which in turn power focus rings, checkbox/radio fills, and any var(--accent) reference you write yourself. The same nine names match the chart color ramps, so a teal-accented form sits naturally next to a teal-accented chart.

Available values: purple (default), teal, coral, pink, gray, blue, green, amber, red

To apply an accent color globally to the whole visualization: wrap the entire content in a single root <div data-accent="…">. Every supported element inside inherits the chosen accent.

<div data-accent="teal"> <style>/ CSS /</style> …all focus rings, checkboxes, and var(--accent) consumers go teal… </div>

To apply an accent color to a specific section: set data-accent on any inner container to recolor just its subtree:

<div data-accent="teal"> <button>Save</button> <!-- teal focus ring --> <input type="checkbox" checked> <!-- teal accent --> </div> <button>Cancel</button> <!-- still default purple -->

To apply an accent color to a single element: set directly on an element to recolor just it:

<button data-accent="green">Approve</button> <button data-accent="red">Reject</button>

Both light and dark themes are handled — accent values track per-theme ramp stops automatically, and foreground text color flips for legibility in dark mode. No manual override needed.

Pick an accent that matches the topic: green for finance/positive, red for warnings/critical actions, blue for informational dashboards, amber for attention/caution, etc. Default to purple for neutral or multi-purpose visualizations.

Output rules

These rules keep visuals clean, accessible, and consistent with the host UI:

• Flat design — no gradients, drop shadows, blur, glow, or noise textures (the host UI is flat; matching it prevents visual jarring)
• Prefer no emojis, instead use CSS shapes or SVG paths for icons (emoji render inconsistently across platforms)
• Sentence case — all labels and headings
• Round displayed numbers — use Math.round, toLocaleString, or Intl.NumberFormat
• Min font size 11px — smaller becomes unreadable on most screens
• Text weights — 400 regular, 500 for emphasis only
• Keep long-form explanation in the prose response. Use concise labels, captions, legends, helper text, and short annotations inside the visual when they improve comprehension.
• Build ambitiously when the topic supports it. Treat each visualization like a small product surface, not a single static graphic. Combine multiple elements: a chart paired with a metric strip, a diagram with collapsible deep-dives, a comparison card with sliders that let the user explore tradeoffs. Use animation, hover, and click interactions where they help the reader notice or explore something — not for decoration. If the user asked for "a chart" and the topic naturally extends into a small dashboard, build the dashboard. Restraint is for cases where extra structure would distract; default to richness, not minimalism.

Design system

CSS variables (auto-injected — prefer these so light/dark mode just works)

The tool injects theme-aware CSS variables that adapt to light/dark mode automatically. Use them by default for text, surface, and border colors; reach for a specific hex only when the design genuinely calls for a fixed color (a brand mark, a deliberate accent that shouldn't track the theme).

Color ramps (9 ramps, auto light/dark)

Each ramp provides fill, stroke, and text variants that adapt to the theme automatically via CSS classes.

Chart dataset colors (use 400 stops)

For area/line fills, use same color at 20% opacity.

SVG setup

If you want to build a beautiful SVG to be rendered inside the chat, follow these rules too: Always use this SVG boilerplate:

<svg width="100%" viewBox="0 0 680 H"> <defs> <marker id="arrow" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse"> <path d="M2 1L8 5L2 9" fill="none" stroke="context-stroke" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/> </marker> </defs> </svg>