@quario/viewer 0.1.0

package/CHANGELOG.md

@@ -0,0 +1,17 @@
+# Changelog
+
+All notable changes to @quario/viewer are documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [0.1.0] - 2026-08-27
+
+### Added
+
+- **An embeddable `<quario-viewer>`.** Assign a compiled report, the targets
+  to render with, and data; it shows the HTML report on a continuous sheet,
+  with zoom, fit, and export buttons for the targets you passed. It is not a
+  target and never walks the event stream.

package/LICENSE

@@ -0,0 +1,219 @@
+# Quario License Agreement
+
+> **In short:** Quario is commercial software with visible source.
+> Evaluate it free for as long as you like. Evaluation output is
+> watermarked. Anything else needs a per-developer license, after
+> which deployment is unlimited and royalty-free. This summary is not
+> the license; the full terms below govern.
+
+Version 1.0, August 2026
+
+This agreement is between you and Webstronauts, trading as Quario,
+established in the Netherlands ("we", "us"), and governs the Software
+defined below.
+
+Quario is commercial software. Its packages ship with readable source
+code, but it is not open source. No rights are granted beyond those in
+this agreement.
+
+## 1. Definitions
+
+- The **Software** is any software we publish under the Quario name,
+  including the `quario` and `@quario/*` packages, except where a
+  product states its own terms. Each release states the edition of this
+  agreement that governs it.
+- **You** means the individual exercising rights under this agreement
+  and, where that individual acts for a company or other organization,
+  that organization. In that case the organization is the licensee, and
+  the rights and limits in this agreement apply to it as a whole.
+- An **Application** is software you create that incorporates the
+  Software and adds substantial functionality beyond it. A
+  licensee-operated service that embeds the Software and renders
+  reports for your End Users is an Application under this agreement,
+  even if it does little more than render.
+- A **Developer** is any individual (employee or contractor working on
+  your behalf) who writes or maintains code that uses the Software's
+  APIs, or who creates or maintains report definitions for use with the
+  Software. That includes people who never install or run the Software
+  themselves, when their definitions are rendered by a service that
+  embeds it.
+- A **Seat** is a paid license for one named Developer, purchased from
+  us or an authorized reseller.
+- **End Users** are people who interact with the Software only through
+  an Application: running it, viewing the reports it produces, or
+  supplying parameters or other input to existing report definitions
+  the Application provides. Creating or maintaining report definitions
+  makes someone a Developer. End Users do not purchase a license; their
+  rights come from section 5.
+
+## 2. Acceptance
+
+This file is our standing offer. Anyone who exercises the evaluation
+rights in section 3 accepts them, subject to their conditions. All
+other rights arise when Seats are purchased. Where a purchase is made
+for an organization, the person completing it confirms that they are
+authorized to accept this agreement on the organization's behalf, and
+acceptance covers the whole organization. If you do not accept this
+agreement, do not use the Software.
+
+## 3. Evaluation
+
+You may download, install, and use the Software free of charge to
+evaluate it: assessing whether it suits your purposes, and building
+prototypes or proofs of concept. Evaluation covers the full feature
+set, needs no key, and has no fixed time limit. The Software marks
+evaluation output as described in section 6.
+
+Evaluation is limited to assessment: you may not distribute any
+Application containing the Software, use the Software in live business
+operations, or expose it in services offered to third parties. The
+moment your use goes beyond evaluating the Software, it requires Seats
+under section 4.
+
+## 4. Developer licenses
+
+Any use of the Software beyond section 3 requires a Seat for every
+Developer, whether or not an Application has shipped. With those Seats
+in place:
+
+- Each licensed Developer may install and use the Software on any number
+  of machines for developing Applications.
+- Automated build, test, and CI systems do not consume Seats.
+- Seats are per named individual. They may be reassigned when a
+  Developer stops working with the Software, but not shared or pooled
+  between concurrently active Developers. Contractors' work for you is
+  covered by your Seats; work they do for other clients is not.
+
+## 5. Distribution and runtime
+
+With Seats under section 4 in place, you may deploy and operate your
+Applications yourself, and distribute the Software as an embedded part
+of them, **royalty-free**: no additional fees or per-deployment
+licenses are required for any number of servers, copies, or End Users.
+You may embed your license key in an Application and ship it at no
+charge, so section 6 does not mark that Application's output.
+
+For that purpose, we grant you the right to pass through to each End
+User, and to anyone who distributes or operates your Application on your
+behalf, a limited, non-exclusive, non-transferable right to execute the
+Software only as embedded in the Application. You must not permit them
+to extract the Software from the Application or use it to develop
+software of their own.
+
+If you operate a service that embeds the Software and renders reports
+for your End Users, that service is an Application under section 1. You
+may run it royalty-free under this section, and you may put your license
+key in it as in any Application. Calling applications that only request
+renders from it need not incorporate the Software. People who use those
+applications only as End Users under section 1 get the pass-through
+rights above.
+
+You may not:
+
+- distribute the Software on its own, or as part of a product whose
+  primary purpose is to provide report-engine, report-design, or
+  document-generation capability to third-party developers;
+- expose the Software's APIs to third parties as a development tool or
+  service that substitutes for those parties buying their own Seats. A
+  licensee-operated service that embeds the Software and renders for
+  your own End Users falls outside that ban;
+- fork, mirror, repackage, rename, or wrap the Software, or republish
+  it on any package registry or code-hosting platform, other than as
+  embedded in an Application.
+
+For as long as this agreement is in force, you may not create any tool,
+library, product, or service that competes with the Software or any
+other Quario product, whether the competition is direct or indirect;
+this restriction does not survive termination. You may not remove or
+alter copyright or license notices in the Software. If your Application
+is itself a closed development product for third-party developers (OEM
+redistribution), contact us for separate terms.
+
+## 6. License keys and output marking
+
+The Software accepts a license key that evidences your Seats under
+section 4. Key checks run offline.
+
+Without a valid key, or with a key whose validity period does not cover
+the installed version's release date, the Software runs with its full
+feature set but marks its output as unlicensed. Using a key you are not
+entitled to is a material breach of this agreement.
+
+You may not remove, disable, or circumvent the key check or the output
+marking, or distribute anything that does.
+
+## 7. Term, updates, and perpetual fallback
+
+Seats are sold as an annual subscription. While the subscription is
+active, licensed Developers receive all Software versions we release,
+and support for the Software through our issue tracker and by email. We
+provide support with commercially reasonable effort; we do not guarantee
+specific response times.
+
+If the subscription lapses, your license to the versions released during
+your subscription is **perpetual, for the number of Seats held at the
+lapse**: up to that many Developers may keep using those versions, and
+your Applications may keep shipping them, forever, at no further cost.
+Versions released after the lapse require renewal. We encode this rule
+in purchased keys: a key remains valid for every version released
+during its validity period, with no end date.
+
+## 8. Source availability
+
+The Software's packages ship with readable source code so that you can
+review and debug what you run. Readable source does not grant extra
+rights: this agreement governs all use of the source, and you may
+publish the Software (modified or not) only as part of an Application
+under section 5.
+
+## 9. Ownership, trademarks, and feedback
+
+We license the Software; we retain all intellectual property rights in
+it. Report definitions, data, and output you create with the Software
+are yours. "Quario" and the Quario logo are our trademarks; this
+agreement grants no rights to use them beyond identifying the Software.
+If you send us feedback or suggestions, we may use them without
+obligation.
+
+## 10. Warranty and liability
+
+We provide the Software as is. To the fullest extent the law allows, we
+disclaim all warranties and conditions, express or implied, including
+merchantability, fitness for a particular purpose, and non-infringement.
+
+To the fullest extent the law allows: we are not liable for indirect or
+consequential damages, loss of profits, loss of data, or business
+interruption; and our total aggregate liability under this agreement is
+limited to the greater of EUR 100 and the fees you paid us in the
+twelve months preceding the event giving rise to the claim. These
+limitations do not apply where the damage results from the intent or
+deliberate recklessness (opzet of bewuste roekeloosheid) of us or our
+management, or where mandatory law does not permit them.
+
+## 11. Termination and survival
+
+If you materially breach this agreement, we may terminate it by notice.
+If the breach can be remedied, we will first allow 30 days from that
+notice to remedy it, and termination takes effect only if the breach
+remains. On termination, the licenses granted here end.
+Perpetual-fallback rights under section 7 survive termination only if
+they arose from a lapse that predates the breach, and section 5
+survives with them to the extent needed to keep exercising them.
+Sections 8 through 12 survive any termination.
+
+## 12. General
+
+Dutch law governs this agreement. Disputes go to the competent court for
+our registered office. You may not assign this agreement without our
+consent, except to a successor of your whole business; we may assign it
+to a successor of ours. If a provision is unenforceable, the remainder
+stays in force. Failure to enforce a provision does not waive it. This
+agreement, together with your order for Seats, is the entire agreement
+about the Software, unless we agree otherwise in writing.
+
+---
+
+**Purchasing and contact:** <contact@getquario.com> ·
+<https://getquario.com>
+
+Copyright © 2026 Webstronauts. All rights reserved.

package/README.md

@@ -0,0 +1,303 @@
+# @quario/viewer
+
+**The embeddable report viewer for [quario](https://www.npmjs.com/package/quario), as a custom
+element.** Write `<quario-viewer>`, assign it a compiled report, the targets to render with, and
+data; it displays the rendered report on a white sheet in its shadow root and offers export
+downloads for the exportable targets you passed.
+
+The viewer is not a render target and compiles nothing. You pass the configured targets you want;
+the viewer displays the `"html"` target's output and wires an export button to each exportable
+target in the list (`"pdf"`, `"xlsx"`, `"csv"`). The bar always carries the zoom control; with no
+exportable target it carries nothing else.
+
+## Install
+
+```bash
+npm install quario @quario/html @quario/viewer
+```
+
+The engine is a peer; the viewer itself depends on no target package. Install the targets you want
+beside it (`@quario/pdf`, `@quario/xlsx`, `@quario/csv`) and pass them in. Its own runtime dependency
+is [Lit](https://lit.dev) (`lit` + `@lit/task`), plain ESM like everything else here. ESM-only, and
+browser-only by nature: the element needs a DOM. CSP-safe like the rest of quario. No
+string-to-code paths, chrome styled through constructed stylesheets, so your `style-src` never
+sees a style tag.
+
+## Quick start
+
+```js
+import { csv } from "@quario/csv";
+import { html } from "@quario/html";
+import { pdf } from "@quario/pdf";
+import { xlsx } from "@quario/xlsx";
+import { quario } from "quario";
+import "@quario/viewer/register";
+
+const view = document.querySelector("quario-viewer");
+view.report = quario().report(schema, funcs);
+view.targets = [html(), pdf(), xlsx(), csv()];
+view.data = data;
+view.filename = "sales";
+```
+
+with `<quario-viewer></quario-viewer>` in your markup, sized by your own CSS. The element is
+`display: block`. Importing `@quario/viewer` defines nothing: the main entry exports the
+`QuarioViewer` class and is side-effect-free, and `@quario/viewer/register` performs the one-line
+`customElements.define("quario-viewer", QuarioViewer)`. A host that wants its own tag imports the
+class and defines it itself. The repository ships this wiring as a runnable page at
+`example/viewer.js`.
+
+React 19, Vue and Svelte set properties on custom elements directly, so there is no wrapper
+package to install. See [Using with React, Vue and Svelte](#using-with-react-vue-and-svelte).
+
+## Properties
+
+| Property      | Takes                                        | Default     |
+| ------------- | -------------------------------------------- | ----------- |
+| `report`      | A compiled report from a quario instance     | -           |
+| `targets`     | Target objects; one named `"html"` required  | -           |
+| `data`        | The render document                          | `undefined` |
+| `zoom`        | `"fit"` or a percentage between 25 and 200   | `"fit"`     |
+| `page`        | Sheet geometry (the pdf target's vocabulary) | A4, 54pt    |
+| `filename`    | Export download name, without extension      | `"report"`  |
+| `colorScheme` | `"light"`, `"dark"`, or `"auto"`             | `"light"`   |
+
+Properties, not attributes: `report`, `targets`, `data` and `page` are values no attribute could
+carry. `targets` mirrors `report.render(target, data)`: the `"html"` target renders the sheet, and
+`"pdf"`/`"xlsx"`/`"csv"` targets become export buttons, in the order given. The quario instance (and
+with it the license and the registry) stays yours: the element takes the compiled report, never a
+schema.
+
+Assigning `data` (or any of the others) re-renders. Rapid successive writes render only the newest
+state: a slow render can never overwrite a newer one, and a superseded render fires no event.
+Assignments are compared by identity, so to re-render from the same object, assign a fresh one
+(`view.data = { ...data }`).
+
+`page` is the pdf target's vocabulary and defaults, and it is **purely visual**: it sizes the white
+sheet (width and padding) the browser lays the report out on. The PDF target's own geometry lives
+in the host's `pdf({ page })` configuration. Pass the same values to both so preview and export
+agree.
+
+## Events and `renderComplete`
+
+```js
+view.addEventListener("rendered", () => {});
+view.addEventListener("error", ({ detail: { error, kind } }) => {});
+await view.renderComplete; // true when the newest render reached the sheet
+```
+
+`rendered` fires each time a render reaches the sheet; `error` fires for every failure you should
+know about, with `detail.kind` naming which: `"mount-render"` until a render has ever landed,
+`"update-render"` after, `"export"` for a download that could not be produced. Both events are
+non-bubbling, like `<img>`'s. Listen on the element. (Because the event is named `error`, an
+inline `onerror` attribute on the element would fire too; `window.onerror` never sees it.)
+
+`renderComplete` awaits the newest render settling: `true` when it reached the sheet, `false` when
+it failed or there was nothing to render. It never rejects; failures arrive on the `error` event.
+Like every outcome here, it answers for the newest render only. A superseded render's failure is
+reported to no one.
+
+Your own mistakes surface on the same channel: a report that is not compiled, a missing
+`"html"` target, or a malformed option property becomes a `TypeError` naming the property, on
+the `error` event and the [error panel](#errors).
+
+## Lifecycle
+
+There is no `destroy()`. Removing the element from the DOM abandons in-flight work and releases
+its observers; an export that settles after removal downloads nothing. The properties persist, and
+re-inserting the element re-renders from them, so reparenting is safe, and discarding a viewer is
+just discarding the element. Two viewers, or a viewer beside your own components, coexist: each
+element owns its own shadow root.
+
+## Using with React, Vue and Svelte
+
+No wrapper packages: each framework sets properties on custom elements directly, so the samples
+below are the whole integration. All three were run before landing here. Import
+`@quario/viewer/register` once, anywhere before the component mounts, and size the element with
+your own CSS.
+
+### React 19
+
+React 19 assigns non-primitive props on a custom element as properties, and `on*` props attach
+listeners for the element's own events. `onrendered` and `onerror` below listen for `rendered`
+and `error`:
+
+```jsx
+import "@quario/viewer/register";
+
+function Report({ report, targets, data }) {
+  return (
+    <quario-viewer
+      report={report}
+      targets={targets}
+      data={data}
+      filename="sales"
+      onrendered={() => console.log("landed")}
+      onerror={(event) => console.error(event.detail.kind, event.detail.error)}
+    />
+  );
+}
+```
+
+Re-rendering with a new `data` prop re-renders the report; the newest write wins, as always.
+(React 18 and earlier stringify unknown props to attributes. There, hold a `ref` and assign the
+properties and listeners in an effect.)
+
+### Vue 3
+
+`:prop` bindings on a custom element land as properties whenever the element defines them, and
+`@rendered`/`@error` are plain DOM listeners:
+
+```vue
+<script setup>
+import "@quario/viewer/register";
+
+defineProps(["report", "targets", "data"]);
+const onRendered = () => console.log("landed");
+const onError = (event) => console.error(event.detail.kind, event.detail.error);
+</script>
+
+<template>
+  <quario-viewer
+    :report="report"
+    :targets="targets"
+    :data="data"
+    filename="sales"
+    @rendered="onRendered"
+    @error="onError"
+  ></quario-viewer>
+</template>
+```
+
+Tell Vue's template compiler the tag is a custom element, so it does not warn about an unresolved
+component. In Vite:
+
+```js
+vue({ template: { compilerOptions: { isCustomElement: (tag) => tag === "quario-viewer" } } });
+```
+
+### Svelte 5
+
+Svelte sets a property whenever the element defines one, and `on<name>` attributes are plain DOM
+listeners:
+
+```svelte
+<script>
+  import "@quario/viewer/register";
+
+  let { report, targets, data } = $props();
+</script>
+
+<quario-viewer
+  {report}
+  {targets}
+  {data}
+  filename="sales"
+  onrendered={() => console.log("landed")}
+  onerror={(event) => console.error(event.detail.kind, event.detail.error)}
+></quario-viewer>
+```
+
+## Zoom
+
+The bar's magnifier opens the zoom menu: **Fit sheet** on its own, then 25%, 50%, 75%, 100%, 150%
+and 200%. A check marks the current mode — Fit sheet whenever the viewer is fitting, whatever
+percentage that came out at — and the percentage on screen is what the trigger is named after
+("Zoom, 62%"), so nothing in the bar changes width as it moves. The `zoom` property picks the mode
+the viewer opens in: a percentage between 25 and 200 — continuous, not one of the menu's stops — or
+`"fit"`, the default. A percentage the menu does not offer leaves every row unchecked.
+
+Fit sizes the sheet to the viewer's width and **only ever shrinks**: given room to spare it stops at
+100%, so the report is shown at its true point size rather than blown up. It has no floor, so a
+narrow pane fits at whatever percentage that takes — below 25% the menu has no row to return to it,
+and **Fit sheet** is the only way back. A fitted viewer follows its own box, so a collapsing panel
+or a resized window re-fits on its own.
+
+The preview **scales; it never reflows.** Zooming shrinks or enlarges the rendered sheet like a
+photograph. Line breaks, column widths and point sizes stay what they are at 100%, so the sheet
+stays the document the pdf target will page. Pass the same `page` values to preview and export so
+they agree.
+
+## What the preview is
+
+On-screen layout is the browser's: one continuous sheet, no pagination. The PDF export paginates
+independently in the pdf target. The preview approximates; the exports are exact.
+
+The sheet is the html target's fragment, so a report with image items shows them through that
+target's `data:` URIs. A host page with a Content Security Policy needs `img-src data:` for them
+to display, the same deployment requirement the fragment carries anywhere else.
+
+Rendering an unlicensed evaluation, rotated watermarks sit on the sheet — one per page-sized band
+of the continuous preview — and scroll and zoom with the report, the way the PDF export marks every
+page. The wording arrives inside the html target's output, on its `.q-unlicensed` badge; the viewer
+hides that element from sight (keeping it readable by assistive technology) and draws the stamps on
+the sheet itself. A licensed render carries neither.
+
+While a render is in flight a thin indeterminate bar sits on the toolbar's bottom edge, and the
+viewer reads `aria-busy="true"`. It reports that the viewer is working, not how far along. The
+engine streams events and cannot know how many are still coming.
+
+There is no Print button, because the sheet is the wrong thing to print. Your page's stylesheets do
+not cross into the shadow root, so `@media print` rules never reach the report; and above or below
+100% the sheet is under a `transform: scale()`, so printing the page puts the viewer's chrome on
+paper at whatever zoom the reader happened to leave it. What a printer wants is the pdf target's
+document, the same bytes the PDF export hands over. A host that wants its own Print button owns
+two lines:
+
+```js
+// `pdfTarget` is the pdf() from the quick start above, and `data` whatever you
+// last rendered — so what prints is exactly what the PDF export would produce.
+const bytes = await rpt.render(pdfTarget, data);
+window.open(URL.createObjectURL(new Blob([bytes], { type: "application/pdf" })));
+```
+
+That opens the report in a tab, where the browser's own PDF viewer prints it, paginated as
+the export is, watermark and all.
+
+## Errors
+
+When a render or an export fails, the viewer says so on the **error panel**, a strip across the top
+of the sheet carrying a short label and the error's own message. It replaces rather than stacks, is
+dismissed by its own button, and is cleared by the next render that reaches the sheet. A successful
+export leaves it up, because the panel describes what you are looking at and a download says
+nothing about that.
+
+Every failure the panel draws, and every export failure, also fires the `error` event; nothing is
+rethrown to the platform behind it. Failures after the element is removed are not reported, and a
+render that a newer one has already superseded reports to no one at all.
+
+The message carries quario's **located error**, the band/item path and the offending source, as in
+`detail[0] [{{ @.amount.toFixed(2) }}]: ...`. Showing it is safe because report definitions are
+trusted configuration; report _data_ never is, and none of it appears in the path. What can carry
+data is the message itself, if your own registry functions interpolate a row into what they throw.
+That is your call, and the panel puts it on screen as text, never as markup. Compile errors are not
+part of this: `q.report(schema)` raises those before the viewer is ever handed a report.
+
+## Color scheme
+
+`colorScheme` paints the **chrome** — backdrop, bar, controls, progress strip, error
+panel — and never the sheet. `"light"` (the default) and `"dark"` pin; `"auto"` follows
+the OS via CSS `color-scheme`. The sheet stays white, watermark included.
+
+Chrome styles live on `--qv-*` custom properties under stable `qv-*` class names. A
+token set on the element (or an ancestor) always wins over the pin. The names are a
+reference seam, not a frozen vocabulary: backdrop and bar (`--qv-backdrop`, `--qv-bar`,
+`--qv-border`, `--qv-text`), controls (`--qv-icon`, `--qv-icon-active`, `--qv-hover`,
+`--qv-active`, `--qv-focus`), progress (`--qv-progress`), the error panel (`--qv-error`,
+`--qv-error-text`, `--qv-error-border`, `--qv-error-hover`), and the sheet's edge
+(`--qv-sheet-shadow`). `--qv-mark` is the watermark face and does not follow the scheme.
+
+The report itself uses the viewer's built-in `q-*` stylesheet, the screen sibling of
+`@quario/html/style.css`.
+
+## License
+
+Commercial software with readable source. Free, unlimited, watermarked evaluation; per-developer
+licenses at [getquario.com](https://getquario.com). See the bundled LICENSE.
+
+Pass your license key once, on the instance; it is verified offline:
+
+```js
+const q = quario({ license: "quario_..." });
+await q.license; // { licensed: true, licensee: "Acme BV", id: "1-ACME" }
+```

package/lib/button.js

@@ -0,0 +1,88 @@
+/**
+ * The shared `qv-button` template. Every control the viewer renders comes
+ * from here — the zoom menu's trigger, the export downloads, the error
+ * panel's dismiss — so they agree on the class, the `type` and how they are
+ * named.
+ */
+import { css, html, nothing } from "lit";
+
+export let BUTTON = css`
+  .qv-button {
+    display: inline-flex;
+    align-items: center;
+    justify-content: center;
+    width: 30px;
+    height: 28px;
+    padding: 0;
+    border: none;
+    border-radius: 5px;
+    background: transparent;
+    color: var(--_icon);
+    cursor: pointer;
+  }
+
+  .qv-button:hover {
+    background: var(--_hover);
+    color: var(--_icon-active);
+  }
+
+  .qv-button:active {
+    background: var(--_active);
+  }
+
+  .qv-button:focus-visible {
+    outline: 2px solid var(--_focus);
+    outline-offset: 1px;
+  }
+
+  /* An invoker whose popover is open reads as held down. Stated over any
+   popover rather than over one module's menu: the platform tracks the state,
+   and this is a fact about the button, not about what it opened. */
+  .qv-button:has(+ [popover]:popover-open) {
+    background: var(--_active);
+    color: var(--_icon-active);
+  }
+
+  .qv-button:disabled {
+    background: transparent;
+    color: var(--_icon);
+    opacity: 0.4;
+    cursor: default;
+  }
+`;
+
+/** @type {<T, U>(value: T, otherwise: U) => T | U} */
+let fallback = (value, otherwise) => value ?? otherwise;
+
+/**
+ * A chrome button: the class, the `type` that keeps it from submitting a form
+ * the viewer may be embedded in, and the title/label pairing every control
+ * carries. Labels and content go in as template values, never as markup, so
+ * the controls have no markup edge to escape at (hard constraint 4).
+ *
+ * @param {{ title: string, label?: string, disabled?: boolean, name?: string,
+ *   popover?: string, click?: () => void,
+ *   content?: import('lit').TemplateResult }} control
+ *   `label` is visible text for the controls that read as words; `content`
+ *   is the icon template the zoom trigger and the export buttons pass
+ *   instead. `name` marks an export button with the target it downloads, and
+ *   `popover` names the menu this button opens — the platform then owns the
+ *   opening and the invoker's own `aria-expanded`, which is why such a button
+ *   needs no click of its own.
+ * @returns {import('lit').TemplateResult}
+ */
+export let button = ({ title, label, disabled, name, popover, click, content }) => html`
+  <button
+    type="button"
+    class="qv-button"
+    title=${title}
+    aria-label=${title}
+    aria-haspopup=${popover ? "menu" : nothing}
+    popovertarget=${fallback(popover, nothing)}
+    data-export=${fallback(name, nothing)}
+    ?disabled=${disabled}
+    @click=${click}
+  >
+    ${fallback(label, content)}
+  </button>
+`;