vectis-ui 0.1.0 → 0.8.0

package/dist/components/VProgressLinear/VProgressLinear.js.map

@@ -1 +1 @@
-{"version":3,"file":"VProgressLinear.js","names":[],"sources":["../../../src/components/VProgressLinear/VProgressLinear.vue"],"sourcesContent":["<script setup lang=\"ts\">\n// @core — no behavioural JS at all: value normalization and the display string.\n/**\n * A bar filling up as something progresses. The element rendered IS the track, and the\n * whole geometry follows from a single number set on it — the fraction filled, with no\n * unit. Everything is written in logical properties, so turning the bar vertical needs\n * nothing but a change of writing direction.\n *\n * There is no behavioural JavaScript: the value is clamped and a percentage is\n * formatted, and that is all.\n *\n * On naming: pass an `aria-label` saying what is progressing. The text shown inside the\n * bar cannot serve as that name — the role a progress bar carries makes its content\n * presentational, so screen readers do not announce it.\n */\nimport { useProgressValue } from '../../composables/useProgressValue'\nimport { useMessages } from '../../i18n/state'\nimport { px } from '../../utils/css'\n\ninterface ProgressLinearProps {\n  /** How far along it is. Anything outside the range is brought back into it. */\n  value?: number\n  /** What counts as finished. The other end is always zero. */\n  max?: number\n  /**\n   * Says that the progress cannot be measured: the bar animates continuously and the\n   * value is ignored. It is what to use while waiting for a server that reports no\n   * percentage.\n   */\n  indeterminate?: boolean\n  /** What the progress means, expressed as a colour. */\n  tone?: 'accent' | 'success' | 'warning' | 'danger' | 'neutral'\n  /**\n   * A colour of your own (hex, CSS name or `oklch()`), which replaces the tone. The\n   * track's own shade is derived from it against the theme, so it follows the light and\n   * the dark one.\n   */\n  color?: string\n  /**\n   * How thick the bar is, always IN PIXELS: `12` and `'12'` both give 12px. It is 4px\n   * by default — bear in mind that showing text inside a bar that thin needs an\n   * explicit thickness.\n   */\n  thickness?: number | string\n  /** Whether the ends of the bar are rounded or square. */\n  shape?: 'rounded' | 'square'\n  /**\n   * Writes the percentage inside the bar. It is ignored while the progress is\n   * unmeasurable, there being no figure to write.\n   */\n  showValue?: boolean\n  /**\n   * Where that text sits along the bar. On a vertical bar the start is the zero end,\n   * hence the bottom.\n   */\n  valuePosition?: 'start' | 'center' | 'end'\n  /** Turns the bar upright, filling from the bottom up. */\n  orientation?: 'horizontal' | 'vertical'\n}\n\nconst props = withDefaults(defineProps<ProgressLinearProps>(), {\n  value: 0,\n  max: 100,\n  indeterminate: false,\n  tone: 'accent',\n  color: undefined,\n  thickness: undefined,\n  shape: 'rounded',\n  showValue: false,\n  valuePosition: 'center',\n  orientation: 'horizontal',\n})\n\ndefineSlots<{\n  /**\n   * What to write inside the bar instead of the percentage.\n   *\n   * TRAP — it is rendered TWICE, once over the empty track and once over the filled\n   * part in a colour that contrasts with it, each copy cut at the fill's edge. So\n   * whatever it renders must be pure: anything with a side effect would happen twice.\n   */\n  default?(props: { value: number; max: number; percent: number }): unknown\n}>()\n\n/* The percent sign, and the non-breaking space French puts before it where English puts\n   nothing, are a convention of the language: they belong in the dictionary rather than\n   in this file. Any other format goes through the slot above. */\nconst m = useMessages()\n\nconst { clamped, fraction } = useProgressValue(\n  () => props.value,\n  () => props.max,\n)\n</script>\n\n<template>\n  <div\n    class=\"v-progress-linear\"\n    role=\"progressbar\"\n    :aria-label=\"m.progress.label\"\n    :data-tone=\"tone\"\n    :data-custom=\"color !== undefined ? '' : undefined\"\n    :data-shape=\"shape\"\n    :data-orientation=\"orientation === 'vertical' ? 'vertical' : undefined\"\n    :data-value-position=\"valuePosition\"\n    :data-indeterminate=\"indeterminate ? '' : undefined\"\n    :aria-valuenow=\"indeterminate ? undefined : clamped\"\n    aria-valuemin=\"0\"\n    :aria-valuemax=\"max\"\n    :style=\"{\n      '--fill-fraction': String(fraction),\n      '--custom-color': color,\n      '--progress-thickness': px(thickness),\n    }\"\n  >\n    <span class=\"v-progress-linear-fill\" />\n    <!--\n      The same text twice, each copy cut at the fill's edge so that the two complete\n      each other exactly: the first in the ordinary text colour over the empty track,\n      the second over the filled part, coloured to contrast with it. The second is\n      hidden from screen readers, being a duplicate of text already there.\n    -->\n    <template v-if=\"!indeterminate && (showValue || $slots.default)\">\n      <span class=\"v-progress-linear-text\">\n        <slot :value=\"clamped\" :max=\"max\" :percent=\"fraction * 100\">\n          {{ m.progress.percent(Math.round(fraction * 100)) }}\n        </slot>\n      </span>\n      <span class=\"v-progress-linear-text\" data-on-fill aria-hidden=\"true\">\n        <slot :value=\"clamped\" :max=\"max\" :percent=\"fraction * 100\">\n          {{ m.progress.percent(Math.round(fraction * 100)) }}\n        </slot>\n      </span>\n    </template>\n  </div>\n</template>\n\n<style>\n@layer vectis.components {\n  /*\n   * The element IS the track, and it takes the whole length available. Sizing it is the\n   * consumer's business, through the parent or through a width of their own — a\n   * consumer's style sits outside our layers and always wins.\n   */\n  .v-progress-linear {\n    --progress-thickness: var(--vectis-control-size-progress-linear-thickness);\n    position: relative;\n    display: block;\n    inline-size: 100%;\n    block-size: var(--progress-thickness);\n    border-radius: var(--vectis-radius-pill);\n    background: var(--progress-track);\n    font-family: var(--vectis-text-family);\n    font-size: var(--vectis-text-caption-size);\n    font-weight: var(--vectis-text-control-weight);\n    line-height: var(--vectis-text-control-leading);\n  }\n\n  .v-progress-linear[data-shape='square'] {\n    border-radius: 0;\n  }\n\n  .v-progress-linear-fill {\n    position: absolute;\n    inset-block: 0;\n    inset-inline-start: 0;\n    inline-size: calc(100% * var(--fill-fraction));\n    border-radius: inherit;\n    background: var(--progress-fill);\n    /*\n     * The fill is animated by changing its LENGTH, which the browser has to lay out\n     * again on every frame. Scaling it would be cheaper, but a scale is physical: it\n     * would have to be undone for the vertical orientation and again for a\n     * right-to-left page, where a logical length simply works.\n     *\n     * The duration and easing are repeated by the clip of the text over the fill, or the\n     * colour boundary would drift away from the fill's own edge for the length of the\n     * transition.\n     */\n    transition: inline-size var(--vectis-duration-base) var(--vectis-ease-default);\n  }\n\n  .v-progress-linear[data-tone='accent'] {\n    --progress-fill: var(--vectis-color-accent);\n    --progress-track: var(--vectis-color-accent-surface);\n    --tone-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  .v-progress-linear[data-tone='success'] {\n    --progress-fill: var(--vectis-color-success);\n    --progress-track: var(--vectis-color-success-surface);\n    --tone-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  .v-progress-linear[data-tone='danger'] {\n    --progress-fill: var(--vectis-color-danger);\n    --progress-track: var(--vectis-color-danger-surface);\n    --tone-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  .v-progress-linear[data-tone='warning'] {\n    --progress-fill: var(--vectis-color-warning);\n    --progress-track: var(--vectis-color-warning-surface);\n    /* White does not reach the required contrast on amber, so this tone has a text\n       colour of its own. */\n    --tone-text-fallback: var(--vectis-color-text-on-warning);\n  }\n\n  /* The neutral tone inverts text and surface rather than using a mid grey, which would\n     be unreadable in one theme or the other. */\n  .v-progress-linear[data-tone='neutral'] {\n    --progress-fill: var(--vectis-color-text);\n    --progress-track: var(--vectis-color-surface-muted);\n    --tone-text-fallback: var(--vectis-color-surface);\n  }\n\n  /* Placed after the tones on purpose: the specificity is the same, so it is the order\n     that lets a custom colour override the tone it replaces. */\n  .v-progress-linear[data-custom] {\n    --progress-fill: var(--custom-color);\n    --progress-track: color-mix(in oklab, var(--custom-color), var(--vectis-color-surface) 85%);\n    --tone-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  /* The text inside the bar, in two copies laid over the same box — the track's own,\n     which is why a cut expressed as a fraction of it lands exactly on the fill's edge.\n     Bear in mind that the default 4px thickness cannot hold text at all: showing any\n     implies asking for a thicker bar.\n\n     TRAP — the two copies are COMPLEMENTARY and never superimposed: this one is cut OUT\n     of the filled part, the other cut TO it, so every letter is painted exactly once.\n     Removing either clip raises no error and stays invisible for as long as both copies\n     resolve to the SAME colour, which is what happens wherever the adaptive colour\n     function is unsupported. Where it IS supported and the two disagree — black over an\n     accent fill against white text in the dark theme — the copy underneath shows its\n     antialiased edges all around the letters of the one on top, and the label reads as\n     a halo. */\n  .v-progress-linear-text {\n    /* The two insets of the cut: one on the edge the fill grows FROM, one on the edge it\n       grows towards. They are named after those roles rather than after physical sides,\n       so the three geometry rules further down — horizontal, right-to-left, vertical —\n       all read the same pair. This copy cuts on the start side; the one over the fill\n       swaps them. */\n    --progress-clip-start: calc(100% * var(--fill-fraction));\n    --progress-clip-end: -100vmax;\n    position: absolute;\n    inset: 0;\n    display: flex;\n    align-items: center;\n    justify-content: center;\n    padding-inline: var(--vectis-space-2);\n    color: var(--vectis-color-text);\n    /* The large negative inset on the two sides that do NOT carry the cut is what stops\n       text taller or wider than the bar from being cropped by its own clip. */\n    clip-path: inset(-100vmax var(--progress-clip-end) -100vmax var(--progress-clip-start));\n    /* The same duration and easing as the fill's own length, or the colour boundary\n       would drift away from the fill's edge for the length of the transition. */\n    transition: clip-path var(--vectis-duration-base) var(--vectis-ease-default);\n    /* The bar itself is turned on its side in vertical mode; the text is put back\n       upright here, since a label read sideways is not the point. */\n    writing-mode: horizontal-tb;\n    white-space: nowrap;\n    pointer-events: none;\n  }\n\n  .v-progress-linear[data-value-position='start'] .v-progress-linear-text {\n    justify-content: start;\n  }\n\n  .v-progress-linear[data-value-position='end'] .v-progress-linear-text {\n    justify-content: end;\n  }\n\n  .v-progress-linear-text[data-on-fill] {\n    /* The exact complement of the copy above: the cut moves to the other end of the\n       axis, so the two together cover the whole bar and overlap nowhere. */\n    --progress-clip-start: -100vmax;\n    --progress-clip-end: calc(100% * (1 - var(--fill-fraction)));\n    /* The per-tone fallback colour. The adaptive one cannot simply be written as a\n       second declaration after it: because that declaration contains a var(), a browser\n       with no support does not reject it at parse time — it would win the cascade and\n       only then turn invalid, which resets the colour to inherited and leaves the\n       fallback never applied. The block below is the way round it, being evaluated\n       before any var() substitution. */\n    color: var(--tone-text-fallback);\n  }\n\n  /* Where the adaptive colour function exists, the text picks black or white against\n     whatever colour the fill ended up with. */\n  @supports (color: contrast-color(red)) {\n    .v-progress-linear-text[data-on-fill] {\n      color: contrast-color(var(--progress-fill));\n    }\n  }\n\n  /* In a right-to-left page the fill grows from the right, so the two insets change\n     physical sides — the variables themselves keep their meaning. */\n  .v-progress-linear:dir(rtl) .v-progress-linear-text {\n    clip-path: inset(-100vmax var(--progress-clip-start) -100vmax var(--progress-clip-end));\n  }\n\n  /* Upright, the bar fills from the bottom.\n\n     Changing the writing direction on the element is enough to turn everything: the\n     axis the fill grows along becomes vertical, so the length and the thickness swap\n     places, and both the fill and the animation follow with no rule written twice.\n\n     TRAP — putting zero at the bottom is NOT done by reversing the direction, which\n     would also apply to the text of the two copies: bidirectional reordering would then\n     display \"50 %\" as \"% 50\". The fill is anchored to the far end of the axis instead.\n\n     The length comes from a token because there is nothing to inherit it from: in a\n     parent of automatic height the bar would collapse to nothing. A consumer's own\n     height overrides it, sitting outside our layers. */\n  .v-progress-linear[data-orientation='vertical'] {\n    writing-mode: vertical-lr;\n    inline-size: var(--vectis-control-size-progress-linear-length);\n  }\n\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-fill {\n    inset-inline-start: auto;\n    inset-inline-end: 0;\n  }\n\n  /* The text now stacks along the vertical axis, whose start is the zero end — the\n     bottom of the bar. */\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-text {\n    flex-direction: column-reverse;\n    padding-inline: 0;\n    padding-block: var(--vectis-space-2);\n  }\n\n  /* The cut moves to the vertical axis: the fill rises from the bottom, which is that\n     axis' start. It is therefore the same in both reading directions, which means the\n     right-to-left rule further up has to be neutralized.\n\n     TRAP — the second selector is what neutralizes it, and it is written that way on\n     purpose: it is one step MORE specific than that rule, where the first selector alone\n     would merely tie with it and win by source order — a far more fragile arrangement. */\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-text,\n  .v-progress-linear[data-orientation='vertical']:dir(rtl) .v-progress-linear-text {\n    clip-path: inset(var(--progress-clip-end) -100vmax var(--progress-clip-start) -100vmax);\n  }\n\n  /* When the progress cannot be measured, a bar of fixed size crosses the track from\n     just outside one end to just outside the other. At each extreme it is exactly flush\n     with the edge without ever pulling away from it, which is what makes the loop\n     invisible and keeps the track from ever looking empty — no second bar is needed.\n\n     The easing carries the whole impression: a gradual entry, a quick crossing, a damped\n     exit. A linear run, or an asymmetric curve, immediately reads as mechanical.\n\n     The movement is expressed in LOGICAL properties — a position and a size as\n     percentages of the track — rather than as a transform. One definition then serves\n     the horizontal, the vertical and the right-to-left cases, where a transform, being\n     physical, would need its own keyframes per axis and a flip per direction. */\n  .v-progress-linear[data-indeterminate] {\n    overflow: hidden;\n  }\n\n  .v-progress-linear[data-indeterminate] .v-progress-linear-fill {\n    /* The starting position is derived from this size, and the two must stay tied: that\n       is what has the bar begin exactly off the track rather than half on it. */\n    --progress-bar: 40%;\n    /* The anchoring is put back at the start of the axis, vertical case included — where\n       a measurable progress anchors at the far end instead. */\n    inset-inline-start: 0;\n    inset-inline-end: auto;\n    inline-size: var(--progress-bar);\n    /* The transition of a measurable progress has no place here: switching to this mode\n       would otherwise be animated as the bar growing to its new size. */\n    transition: none;\n    animation: v-progress-linear-indeterminate var(--vectis-duration-1500) var(--vectis-ease-in-out)\n      infinite;\n  }\n\n  @keyframes v-progress-linear-indeterminate {\n    from {\n      inset-inline-start: calc(-1 * var(--progress-bar));\n    }\n\n    to {\n      inset-inline-start: 100%;\n    }\n  }\n\n  /* Turned upright, the axis runs downwards, so the bar would travel from the top down —\n     the opposite of a measurable fill, which rises from the bottom. The same keyframes\n     are simply read backwards, which changes nothing else BECAUSE the easing curve is\n     symmetric; an asymmetric one would need a second set of keyframes.\n\n     Nothing is needed for a right-to-left page: the logical inset already follows the\n     reading direction. */\n  .v-progress-linear[data-orientation='vertical'][data-indeterminate] .v-progress-linear-fill {\n    animation-direction: reverse;\n  }\n\n  @media (prefers-reduced-motion: reduce) {\n    .v-progress-linear-fill,\n    .v-progress-linear-text {\n      transition: none;\n    }\n\n    /* Slowed down and not stopped: a motionless loader no longer says that anything is\n       happening, which is the one thing it exists to say. */\n    .v-progress-linear[data-indeterminate] .v-progress-linear-fill {\n      animation-duration: var(--vectis-duration-5000);\n    }\n  }\n}\n</style>\n"],"mappings":""}
+{"version":3,"file":"VProgressLinear.js","names":[],"sources":["../../../src/components/VProgressLinear/VProgressLinear.vue"],"sourcesContent":["<script setup lang=\"ts\">\n// @core — no behavioural JS at all: value normalization and the display string.\n/**\n * A bar filling up as something progresses. The element rendered IS the track, and the\n * whole geometry follows from a single number set on it — the fraction filled, with no\n * unit. Everything is written in logical properties, so turning the bar vertical needs\n * nothing but a change of writing direction.\n *\n * There is no behavioural JavaScript: the value is clamped and a percentage is\n * formatted, and that is all.\n *\n * On naming: pass a `label` saying what is progressing. The text shown inside the\n * bar cannot serve as that name — the role a progress bar carries makes its content\n * presentational, so screen readers do not announce it.\n */\nimport { useAriaLabel } from '../../composables/useAriaLabel'\nimport { useProgressValue } from '../../composables/useProgressValue'\nimport { useMessages } from '../../i18n/state'\nimport { px } from '../../utils/css'\n\n/** What the progress means, in colour. */\nexport type ProgressLinearTone = 'accent' | 'success' | 'warning' | 'danger' | 'neutral'\n\n/** How the track and the fill end. */\nexport type ProgressLinearShape = 'rounded' | 'square'\n\n/** Where the value sits along the bar. */\nexport type ProgressLinearValuePosition = 'start' | 'center' | 'end'\n\n/** Which way the bar fills. */\nexport type ProgressLinearOrientation = 'horizontal' | 'vertical'\n\ninterface ProgressLinearProps {\n  /** How far along it is. Anything outside the range is brought back into it. */\n  value?: number\n  /**\n   * What is progressing, in words, for screen readers. It draws nothing on screen, and falls\n   * back to the design system dictionary; an `aria-label` or `aria-labelledby` of your own\n   * takes precedence over it.\n   */\n  label?: string\n  /** What counts as finished. The other end is always zero. */\n  max?: number\n  /**\n   * Says that the progress cannot be measured: the bar animates continuously and the\n   * value is ignored. It is what to use while waiting for a server that reports no\n   * percentage.\n   */\n  indeterminate?: boolean\n  /** What the progress means, expressed as a colour. */\n  tone?: ProgressLinearTone\n  /**\n   * A colour of your own (hex, CSS name or `oklch()`), which replaces the tone. The\n   * track's own shade is derived from it against the theme, so it follows the light and\n   * the dark one.\n   */\n  color?: string\n  /**\n   * How thick the bar is, always IN PIXELS: `12` and `'12'` both give 12px. It is 4px\n   * by default — bear in mind that showing text inside a bar that thin needs an\n   * explicit thickness.\n   */\n  thickness?: number | string\n  /** Whether the ends of the bar are rounded or square. */\n  shape?: ProgressLinearShape\n  /**\n   * Writes the percentage inside the bar. It is ignored while the progress is\n   * unmeasurable, there being no figure to write.\n   */\n  showValue?: boolean\n  /**\n   * Where that text sits along the bar. On a vertical bar the start is the zero end,\n   * hence the bottom.\n   */\n  valuePosition?: ProgressLinearValuePosition\n  /** Turns the bar upright, filling from the bottom up. */\n  orientation?: ProgressLinearOrientation\n}\n\nconst props = withDefaults(defineProps<ProgressLinearProps>(), {\n  value: 0,\n  label: undefined,\n  max: 100,\n  indeterminate: false,\n  tone: 'accent',\n  color: undefined,\n  thickness: undefined,\n  shape: 'rounded',\n  showValue: false,\n  valuePosition: 'center',\n  orientation: 'horizontal',\n})\n\ndefineSlots<{\n  /**\n   * What to write inside the bar instead of the percentage.\n   *\n   * TRAP — it is rendered TWICE, once over the empty track and once over the filled\n   * part in a colour that contrasts with it, each copy cut at the fill's edge. So\n   * whatever it renders must be pure: anything with a side effect would happen twice.\n   */\n  default?(props: { value: number; max: number; percent: number }): unknown\n}>()\n\n/* The percent sign, and the non-breaking space French puts before it where English puts\n   nothing, are a convention of the language: they belong in the dictionary rather than\n   in this file. Any other format goes through the slot above. */\nconst m = useMessages()\n\nconst {\n  max: normalizedMax,\n  clamped,\n  fraction,\n  percent,\n  roundedPercent,\n} = useProgressValue(\n  () => props.value,\n  () => props.max,\n)\n\n// @a11y\n// The canonical cascade: a consumer's `aria-labelledby`, then their `aria-label`, then the\n// `label` prop, then the dictionary. An indicator takes no name from the text inside it, so\n// without the last step it would have none at all.\nconst ariaLabel = useAriaLabel(() => props.label ?? m.value.progress.label)\n</script>\n\n<template>\n  <div\n    class=\"v-progress-linear v-tone\"\n    role=\"progressbar\"\n    :aria-label=\"ariaLabel\"\n    :data-tone=\"tone\"\n    :data-custom=\"color !== undefined ? '' : undefined\"\n    :data-shape=\"shape\"\n    :data-orientation=\"orientation\"\n    :data-value-position=\"valuePosition\"\n    :data-indeterminate=\"indeterminate ? '' : undefined\"\n    :aria-valuenow=\"indeterminate ? undefined : clamped\"\n    aria-valuemin=\"0\"\n    :aria-valuemax=\"normalizedMax\"\n    :style=\"{\n      '--fill-fraction': String(fraction),\n      '--custom-color': color,\n      '--progress-thickness': px(thickness),\n    }\"\n  >\n    <span class=\"v-progress-linear-fill\" />\n    <!--\n      The same text twice, each copy cut at the fill's edge so that the two complete\n      each other exactly: the first in the ordinary text colour over the empty track,\n      the second over the filled part, coloured to contrast with it. The second is\n      hidden from screen readers, being a duplicate of text already there.\n    -->\n    <template v-if=\"!indeterminate && (showValue || $slots.default)\">\n      <span class=\"v-progress-linear-text\">\n        <slot :value=\"clamped\" :max=\"normalizedMax\" :percent=\"percent\">\n          {{ m.progress.percent(roundedPercent) }}\n        </slot>\n      </span>\n      <span class=\"v-progress-linear-text\" data-on-fill aria-hidden=\"true\">\n        <slot :value=\"clamped\" :max=\"normalizedMax\" :percent=\"percent\">\n          {{ m.progress.percent(roundedPercent) }}\n        </slot>\n      </span>\n    </template>\n  </div>\n</template>\n\n<style>\n@layer vectis.components {\n  /*\n   * The element IS the track, and it takes the whole length available. Sizing it is the\n   * consumer's business, through the parent or through a width of their own — a\n   * consumer's style sits outside our layers and always wins.\n   */\n  .v-progress-linear {\n    --progress-thickness: var(--vectis-control-size-progress-linear-thickness);\n    /* Fill, track and the text over the fill are the tone's solid, soft and on-solid\n       colours, read from the shared table (`.v-tone`, set in the template). */\n    --progress-fill: var(--tone-bg-solid);\n    --progress-track: var(--tone-bg-soft);\n    --progress-text-fallback: var(--tone-text-solid);\n    position: relative;\n    display: block;\n    inline-size: 100%;\n    block-size: var(--progress-thickness);\n    border-radius: var(--vectis-radius-pill);\n    background: var(--progress-track);\n    font-family: var(--vectis-text-family);\n    font-size: var(--vectis-text-caption-size);\n    font-weight: var(--vectis-text-control-weight);\n    line-height: var(--vectis-text-control-leading);\n  }\n\n  .v-progress-linear[data-shape='square'] {\n    border-radius: 0;\n  }\n\n  .v-progress-linear-fill {\n    position: absolute;\n    inset-block: 0;\n    inset-inline-start: 0;\n    inline-size: calc(100% * var(--fill-fraction));\n    border-radius: inherit;\n    background: var(--progress-fill);\n    /*\n     * The fill is animated by changing its LENGTH, which the browser has to lay out\n     * again on every frame. Scaling it would be cheaper, but a scale is physical: it\n     * would have to be undone for the vertical orientation and again for a\n     * right-to-left page, where a logical length simply works.\n     *\n     * The duration and easing are repeated by the clip of the text over the fill, or the\n     * colour boundary would drift away from the fill's own edge for the length of the\n     * transition.\n     */\n    transition: inline-size var(--vectis-duration-base) var(--vectis-ease-default);\n  }\n\n  /* A custom colour replaces the tone: at (0,2,0) it beats the base rule's mapping\n     whatever the order the two are written in. */\n  .v-progress-linear[data-custom] {\n    --progress-fill: var(--custom-color);\n    --progress-track: color-mix(in oklab, var(--custom-color), var(--vectis-color-surface) 85%);\n    --progress-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  /* The text inside the bar, in two copies laid over the same box — the track's own,\n     which is why a cut expressed as a fraction of it lands exactly on the fill's edge.\n     Bear in mind that the default 4px thickness cannot hold text at all: showing any\n     implies asking for a thicker bar.\n\n     TRAP — the two copies are COMPLEMENTARY and never superimposed: this one is cut OUT\n     of the filled part, the other cut TO it, so every letter is painted exactly once.\n     Removing either clip raises no error and stays invisible for as long as both copies\n     resolve to the SAME colour, which is what happens wherever the adaptive colour\n     function is unsupported. Where it IS supported and the two disagree — black over an\n     accent fill against white text in the dark theme — the copy underneath shows its\n     antialiased edges all around the letters of the one on top, and the label reads as\n     a halo. */\n  .v-progress-linear-text {\n    /* The two insets of the cut: one on the edge the fill grows FROM, one on the edge it\n       grows towards. They are named after those roles rather than after physical sides,\n       so the three geometry rules further down — horizontal, right-to-left, vertical —\n       all read the same pair. This copy cuts on the start side; the one over the fill\n       swaps them. */\n    --progress-clip-start: calc(100% * var(--fill-fraction));\n    --progress-clip-end: -100vmax;\n    position: absolute;\n    inset: 0;\n    display: flex;\n    align-items: center;\n    justify-content: center;\n    padding-inline: var(--vectis-space-2);\n    color: var(--vectis-color-text);\n    /* The large negative inset on the two sides that do NOT carry the cut is what stops\n       text taller or wider than the bar from being cropped by its own clip. */\n    clip-path: inset(-100vmax var(--progress-clip-end) -100vmax var(--progress-clip-start));\n    /* The same duration and easing as the fill's own length, or the colour boundary\n       would drift away from the fill's edge for the length of the transition. */\n    transition: clip-path var(--vectis-duration-base) var(--vectis-ease-default);\n    /* The bar itself is turned on its side in vertical mode; the text is put back\n       upright here, since a label read sideways is not the point. */\n    writing-mode: horizontal-tb;\n    white-space: nowrap;\n    pointer-events: none;\n  }\n\n  .v-progress-linear[data-value-position='start'] .v-progress-linear-text {\n    justify-content: start;\n  }\n\n  .v-progress-linear[data-value-position='end'] .v-progress-linear-text {\n    justify-content: end;\n  }\n\n  .v-progress-linear-text[data-on-fill] {\n    /* The exact complement of the copy above: the cut moves to the other end of the\n       axis, so the two together cover the whole bar and overlap nowhere. */\n    --progress-clip-start: -100vmax;\n    --progress-clip-end: calc(100% * (1 - var(--fill-fraction)));\n    /* The per-tone fallback colour. The adaptive one cannot simply be written as a\n       second declaration after it: because that declaration contains a var(), a browser\n       with no support does not reject it at parse time — it would win the cascade and\n       only then turn invalid, which resets the colour to inherited and leaves the\n       fallback never applied. The block below is the way round it, being evaluated\n       before any var() substitution. */\n    color: var(--progress-text-fallback);\n  }\n\n  /* Where the adaptive colour function exists, the text picks black or white against\n     whatever colour the fill ended up with. */\n  @supports (color: contrast-color(red)) {\n    .v-progress-linear-text[data-on-fill] {\n      color: contrast-color(var(--progress-fill));\n    }\n  }\n\n  /* In a right-to-left page the fill grows from the right, so the two insets change\n     physical sides — the variables themselves keep their meaning. */\n  .v-progress-linear:dir(rtl) .v-progress-linear-text {\n    clip-path: inset(-100vmax var(--progress-clip-start) -100vmax var(--progress-clip-end));\n  }\n\n  /* Upright, the bar fills from the bottom.\n\n     Changing the writing direction on the element is enough to turn everything: the\n     axis the fill grows along becomes vertical, so the length and the thickness swap\n     places, and both the fill and the animation follow with no rule written twice.\n\n     TRAP — putting zero at the bottom is NOT done by reversing the direction, which\n     would also apply to the text of the two copies: bidirectional reordering would then\n     display \"50 %\" as \"% 50\". The fill is anchored to the far end of the axis instead.\n\n     The length comes from a token because there is nothing to inherit it from: in a\n     parent of automatic height the bar would collapse to nothing. A consumer's own\n     height overrides it, sitting outside our layers. */\n  .v-progress-linear[data-orientation='vertical'] {\n    writing-mode: vertical-lr;\n    inline-size: var(--vectis-control-size-progress-linear-length);\n  }\n\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-fill {\n    inset-inline-start: auto;\n    inset-inline-end: 0;\n  }\n\n  /* The text now stacks along the vertical axis, whose start is the zero end — the\n     bottom of the bar. */\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-text {\n    flex-direction: column-reverse;\n    padding-inline: 0;\n    padding-block: var(--vectis-space-2);\n  }\n\n  /* The cut moves to the vertical axis: the fill rises from the bottom, which is that\n     axis' start. It is therefore the same in both reading directions, which means the\n     right-to-left rule further up has to be neutralized.\n\n     TRAP — the second selector is what neutralizes it, and it is written that way on\n     purpose: it is one step MORE specific than that rule, where the first selector alone\n     would merely tie with it and win by source order — a far more fragile arrangement. */\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-text,\n  .v-progress-linear[data-orientation='vertical']:dir(rtl) .v-progress-linear-text {\n    clip-path: inset(var(--progress-clip-end) -100vmax var(--progress-clip-start) -100vmax);\n  }\n\n  /* When the progress cannot be measured, a bar of fixed size crosses the track from\n     just outside one end to just outside the other. At each extreme it is exactly flush\n     with the edge without ever pulling away from it, which is what makes the loop\n     invisible and keeps the track from ever looking empty — no second bar is needed.\n\n     The easing carries the whole impression: a gradual entry, a quick crossing, a damped\n     exit. A linear run, or an asymmetric curve, immediately reads as mechanical.\n\n     The movement is expressed in LOGICAL properties — a position and a size as\n     percentages of the track — rather than as a transform. One definition then serves\n     the horizontal, the vertical and the right-to-left cases, where a transform, being\n     physical, would need its own keyframes per axis and a flip per direction. */\n  .v-progress-linear[data-indeterminate] {\n    overflow: hidden;\n  }\n\n  .v-progress-linear[data-indeterminate] .v-progress-linear-fill {\n    /* The starting position is derived from this size, and the two must stay tied: that\n       is what has the bar begin exactly off the track rather than half on it. */\n    --progress-bar: 40%;\n    /* The anchoring is put back at the start of the axis, vertical case included — where\n       a measurable progress anchors at the far end instead. */\n    inset-inline-start: 0;\n    inset-inline-end: auto;\n    inline-size: var(--progress-bar);\n    /* The transition of a measurable progress has no place here: switching to this mode\n       would otherwise be animated as the bar growing to its new size. */\n    transition: none;\n    animation: v-progress-linear-indeterminate var(--vectis-duration-1500) var(--vectis-ease-in-out)\n      infinite;\n  }\n\n  @keyframes v-progress-linear-indeterminate {\n    from {\n      inset-inline-start: calc(-1 * var(--progress-bar));\n    }\n\n    to {\n      inset-inline-start: 100%;\n    }\n  }\n\n  /* Turned upright, the axis runs downwards, so the bar would travel from the top down —\n     the opposite of a measurable fill, which rises from the bottom. The same keyframes\n     are simply read backwards, which changes nothing else BECAUSE the easing curve is\n     symmetric; an asymmetric one would need a second set of keyframes.\n\n     Nothing is needed for a right-to-left page: the logical inset already follows the\n     reading direction. */\n  .v-progress-linear[data-orientation='vertical'][data-indeterminate] .v-progress-linear-fill {\n    animation-direction: reverse;\n  }\n\n  @media (prefers-reduced-motion: reduce) {\n    .v-progress-linear-fill,\n    .v-progress-linear-text {\n      transition: none;\n    }\n\n    /* Slowed down and not stopped: a motionless loader no longer says that anything is\n       happening, which is the one thing it exists to say. */\n    .v-progress-linear[data-indeterminate] .v-progress-linear-fill {\n      animation-duration: var(--vectis-duration-5000);\n    }\n  }\n}\n</style>\n"],"mappings":""}

package/dist/components/VProgressLinear/VProgressLinear.vue_vue_type_script_setup_true_lang.js

@@ -1,9 +1,10 @@
 import { useMessages as e } from "../../i18n/state.js";
 import { px as t } from "../../utils/css.js";
-import { useProgressValue as n } from "../../composables/useProgressValue.js";
-import { Fragment as r, createCommentVNode as i, createElementBlock as a, createElementVNode as o, createTextVNode as s, defineComponent as c, normalizeStyle as l, openBlock as u, renderSlot as d, toDisplayString as f, unref as p } from "vue";
+import { useAriaLabel as n } from "../../composables/useAriaLabel.js";
+import { useProgressValue as r } from "../../composables/useProgressValue.js";
+import { Fragment as i, createCommentVNode as a, createElementBlock as o, createElementVNode as s, createTextVNode as c, defineComponent as l, normalizeStyle as u, openBlock as d, renderSlot as f, toDisplayString as p, unref as m } from "vue";
 //#region src/components/VProgressLinear/VProgressLinear.vue?vue&type=script&setup=true&lang.ts
-var m = [
+var h = [
 	"aria-label",
 	"data-tone",
 	"data-custom",
@@ -13,14 +14,15 @@ var m = [
 	"data-indeterminate",
 	"aria-valuenow",
 	"aria-valuemax"
-], h = { class: "v-progress-linear-text" }, g = {
+], g = { class: "v-progress-linear-text" }, _ = {
 	class: "v-progress-linear-text",
 	"data-on-fill": "",
 	"aria-hidden": "true"
-}, _ = /*@__PURE__*/ c({
+}, v = /*@__PURE__*/ l({
 	__name: "VProgressLinear",
 	props: {
 		value: { default: 0 },
+		label: { default: void 0 },
 		max: { default: 100 },
 		indeterminate: {
 			type: Boolean,
@@ -37,38 +39,38 @@ var m = [
 		valuePosition: { default: "center" },
 		orientation: { default: "horizontal" }
 	},
-	setup(c) {
-		let _ = c, v = e(), { clamped: y, fraction: b } = n(() => _.value, () => _.max);
-		return (e, n) => (u(), a("div", {
-			class: "v-progress-linear",
+	setup(l) {
+		let v = l, y = e(), { max: b, clamped: x, fraction: S, percent: C, roundedPercent: w } = r(() => v.value, () => v.max), T = n(() => v.label ?? y.value.progress.label);
+		return (e, n) => (d(), o("div", {
+			class: "v-progress-linear v-tone",
 			role: "progressbar",
-			"aria-label": p(v).progress.label,
-			"data-tone": c.tone,
-			"data-custom": c.color === void 0 ? void 0 : "",
-			"data-shape": c.shape,
-			"data-orientation": c.orientation === "vertical" ? "vertical" : void 0,
-			"data-value-position": c.valuePosition,
-			"data-indeterminate": c.indeterminate ? "" : void 0,
-			"aria-valuenow": c.indeterminate ? void 0 : p(y),
+			"aria-label": m(T),
+			"data-tone": l.tone,
+			"data-custom": l.color === void 0 ? void 0 : "",
+			"data-shape": l.shape,
+			"data-orientation": l.orientation,
+			"data-value-position": l.valuePosition,
+			"data-indeterminate": l.indeterminate ? "" : void 0,
+			"aria-valuenow": l.indeterminate ? void 0 : m(x),
 			"aria-valuemin": "0",
-			"aria-valuemax": c.max,
-			style: l({
-				"--fill-fraction": String(p(b)),
-				"--custom-color": c.color,
-				"--progress-thickness": p(t)(c.thickness)
+			"aria-valuemax": m(b),
+			style: u({
+				"--fill-fraction": String(m(S)),
+				"--custom-color": l.color,
+				"--progress-thickness": m(t)(l.thickness)
 			})
-		}, [n[0] ||= o("span", { class: "v-progress-linear-fill" }, null, -1), !c.indeterminate && (c.showValue || e.$slots.default) ? (u(), a(r, { key: 0 }, [o("span", h, [d(e.$slots, "default", {
-			value: p(y),
-			max: c.max,
-			percent: p(b) * 100
-		}, () => [s(f(p(v).progress.percent(Math.round(p(b) * 100))), 1)])]), o("span", g, [d(e.$slots, "default", {
-			value: p(y),
-			max: c.max,
-			percent: p(b) * 100
-		}, () => [s(f(p(v).progress.percent(Math.round(p(b) * 100))), 1)])])], 64)) : i("", !0)], 12, m));
+		}, [n[0] ||= s("span", { class: "v-progress-linear-fill" }, null, -1), !l.indeterminate && (l.showValue || e.$slots.default) ? (d(), o(i, { key: 0 }, [s("span", g, [f(e.$slots, "default", {
+			value: m(x),
+			max: m(b),
+			percent: m(C)
+		}, () => [c(p(m(y).progress.percent(m(w))), 1)])]), s("span", _, [f(e.$slots, "default", {
+			value: m(x),
+			max: m(b),
+			percent: m(C)
+		}, () => [c(p(m(y).progress.percent(m(w))), 1)])])], 64)) : a("", !0)], 12, h));
 	}
 });
 //#endregion
-export { _ as default };
+export { v as default };
 
 //# sourceMappingURL=VProgressLinear.vue_vue_type_script_setup_true_lang.js.map

package/dist/components/VProgressLinear/VProgressLinear.vue_vue_type_script_setup_true_lang.js.map

@@ -1 +1 @@
-{"version":3,"file":"VProgressLinear.vue_vue_type_script_setup_true_lang.js","names":["$slots"],"sources":["../../../src/components/VProgressLinear/VProgressLinear.vue"],"sourcesContent":["<script setup lang=\"ts\">\n// @core — no behavioural JS at all: value normalization and the display string.\n/**\n * A bar filling up as something progresses. The element rendered IS the track, and the\n * whole geometry follows from a single number set on it — the fraction filled, with no\n * unit. Everything is written in logical properties, so turning the bar vertical needs\n * nothing but a change of writing direction.\n *\n * There is no behavioural JavaScript: the value is clamped and a percentage is\n * formatted, and that is all.\n *\n * On naming: pass an `aria-label` saying what is progressing. The text shown inside the\n * bar cannot serve as that name — the role a progress bar carries makes its content\n * presentational, so screen readers do not announce it.\n */\nimport { useProgressValue } from '../../composables/useProgressValue'\nimport { useMessages } from '../../i18n/state'\nimport { px } from '../../utils/css'\n\ninterface ProgressLinearProps {\n  /** How far along it is. Anything outside the range is brought back into it. */\n  value?: number\n  /** What counts as finished. The other end is always zero. */\n  max?: number\n  /**\n   * Says that the progress cannot be measured: the bar animates continuously and the\n   * value is ignored. It is what to use while waiting for a server that reports no\n   * percentage.\n   */\n  indeterminate?: boolean\n  /** What the progress means, expressed as a colour. */\n  tone?: 'accent' | 'success' | 'warning' | 'danger' | 'neutral'\n  /**\n   * A colour of your own (hex, CSS name or `oklch()`), which replaces the tone. The\n   * track's own shade is derived from it against the theme, so it follows the light and\n   * the dark one.\n   */\n  color?: string\n  /**\n   * How thick the bar is, always IN PIXELS: `12` and `'12'` both give 12px. It is 4px\n   * by default — bear in mind that showing text inside a bar that thin needs an\n   * explicit thickness.\n   */\n  thickness?: number | string\n  /** Whether the ends of the bar are rounded or square. */\n  shape?: 'rounded' | 'square'\n  /**\n   * Writes the percentage inside the bar. It is ignored while the progress is\n   * unmeasurable, there being no figure to write.\n   */\n  showValue?: boolean\n  /**\n   * Where that text sits along the bar. On a vertical bar the start is the zero end,\n   * hence the bottom.\n   */\n  valuePosition?: 'start' | 'center' | 'end'\n  /** Turns the bar upright, filling from the bottom up. */\n  orientation?: 'horizontal' | 'vertical'\n}\n\nconst props = withDefaults(defineProps<ProgressLinearProps>(), {\n  value: 0,\n  max: 100,\n  indeterminate: false,\n  tone: 'accent',\n  color: undefined,\n  thickness: undefined,\n  shape: 'rounded',\n  showValue: false,\n  valuePosition: 'center',\n  orientation: 'horizontal',\n})\n\ndefineSlots<{\n  /**\n   * What to write inside the bar instead of the percentage.\n   *\n   * TRAP — it is rendered TWICE, once over the empty track and once over the filled\n   * part in a colour that contrasts with it, each copy cut at the fill's edge. So\n   * whatever it renders must be pure: anything with a side effect would happen twice.\n   */\n  default?(props: { value: number; max: number; percent: number }): unknown\n}>()\n\n/* The percent sign, and the non-breaking space French puts before it where English puts\n   nothing, are a convention of the language: they belong in the dictionary rather than\n   in this file. Any other format goes through the slot above. */\nconst m = useMessages()\n\nconst { clamped, fraction } = useProgressValue(\n  () => props.value,\n  () => props.max,\n)\n</script>\n\n<template>\n  <div\n    class=\"v-progress-linear\"\n    role=\"progressbar\"\n    :aria-label=\"m.progress.label\"\n    :data-tone=\"tone\"\n    :data-custom=\"color !== undefined ? '' : undefined\"\n    :data-shape=\"shape\"\n    :data-orientation=\"orientation === 'vertical' ? 'vertical' : undefined\"\n    :data-value-position=\"valuePosition\"\n    :data-indeterminate=\"indeterminate ? '' : undefined\"\n    :aria-valuenow=\"indeterminate ? undefined : clamped\"\n    aria-valuemin=\"0\"\n    :aria-valuemax=\"max\"\n    :style=\"{\n      '--fill-fraction': String(fraction),\n      '--custom-color': color,\n      '--progress-thickness': px(thickness),\n    }\"\n  >\n    <span class=\"v-progress-linear-fill\" />\n    <!--\n      The same text twice, each copy cut at the fill's edge so that the two complete\n      each other exactly: the first in the ordinary text colour over the empty track,\n      the second over the filled part, coloured to contrast with it. The second is\n      hidden from screen readers, being a duplicate of text already there.\n    -->\n    <template v-if=\"!indeterminate && (showValue || $slots.default)\">\n      <span class=\"v-progress-linear-text\">\n        <slot :value=\"clamped\" :max=\"max\" :percent=\"fraction * 100\">\n          {{ m.progress.percent(Math.round(fraction * 100)) }}\n        </slot>\n      </span>\n      <span class=\"v-progress-linear-text\" data-on-fill aria-hidden=\"true\">\n        <slot :value=\"clamped\" :max=\"max\" :percent=\"fraction * 100\">\n          {{ m.progress.percent(Math.round(fraction * 100)) }}\n        </slot>\n      </span>\n    </template>\n  </div>\n</template>\n\n<style>\n@layer vectis.components {\n  /*\n   * The element IS the track, and it takes the whole length available. Sizing it is the\n   * consumer's business, through the parent or through a width of their own — a\n   * consumer's style sits outside our layers and always wins.\n   */\n  .v-progress-linear {\n    --progress-thickness: var(--vectis-control-size-progress-linear-thickness);\n    position: relative;\n    display: block;\n    inline-size: 100%;\n    block-size: var(--progress-thickness);\n    border-radius: var(--vectis-radius-pill);\n    background: var(--progress-track);\n    font-family: var(--vectis-text-family);\n    font-size: var(--vectis-text-caption-size);\n    font-weight: var(--vectis-text-control-weight);\n    line-height: var(--vectis-text-control-leading);\n  }\n\n  .v-progress-linear[data-shape='square'] {\n    border-radius: 0;\n  }\n\n  .v-progress-linear-fill {\n    position: absolute;\n    inset-block: 0;\n    inset-inline-start: 0;\n    inline-size: calc(100% * var(--fill-fraction));\n    border-radius: inherit;\n    background: var(--progress-fill);\n    /*\n     * The fill is animated by changing its LENGTH, which the browser has to lay out\n     * again on every frame. Scaling it would be cheaper, but a scale is physical: it\n     * would have to be undone for the vertical orientation and again for a\n     * right-to-left page, where a logical length simply works.\n     *\n     * The duration and easing are repeated by the clip of the text over the fill, or the\n     * colour boundary would drift away from the fill's own edge for the length of the\n     * transition.\n     */\n    transition: inline-size var(--vectis-duration-base) var(--vectis-ease-default);\n  }\n\n  .v-progress-linear[data-tone='accent'] {\n    --progress-fill: var(--vectis-color-accent);\n    --progress-track: var(--vectis-color-accent-surface);\n    --tone-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  .v-progress-linear[data-tone='success'] {\n    --progress-fill: var(--vectis-color-success);\n    --progress-track: var(--vectis-color-success-surface);\n    --tone-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  .v-progress-linear[data-tone='danger'] {\n    --progress-fill: var(--vectis-color-danger);\n    --progress-track: var(--vectis-color-danger-surface);\n    --tone-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  .v-progress-linear[data-tone='warning'] {\n    --progress-fill: var(--vectis-color-warning);\n    --progress-track: var(--vectis-color-warning-surface);\n    /* White does not reach the required contrast on amber, so this tone has a text\n       colour of its own. */\n    --tone-text-fallback: var(--vectis-color-text-on-warning);\n  }\n\n  /* The neutral tone inverts text and surface rather than using a mid grey, which would\n     be unreadable in one theme or the other. */\n  .v-progress-linear[data-tone='neutral'] {\n    --progress-fill: var(--vectis-color-text);\n    --progress-track: var(--vectis-color-surface-muted);\n    --tone-text-fallback: var(--vectis-color-surface);\n  }\n\n  /* Placed after the tones on purpose: the specificity is the same, so it is the order\n     that lets a custom colour override the tone it replaces. */\n  .v-progress-linear[data-custom] {\n    --progress-fill: var(--custom-color);\n    --progress-track: color-mix(in oklab, var(--custom-color), var(--vectis-color-surface) 85%);\n    --tone-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  /* The text inside the bar, in two copies laid over the same box — the track's own,\n     which is why a cut expressed as a fraction of it lands exactly on the fill's edge.\n     Bear in mind that the default 4px thickness cannot hold text at all: showing any\n     implies asking for a thicker bar.\n\n     TRAP — the two copies are COMPLEMENTARY and never superimposed: this one is cut OUT\n     of the filled part, the other cut TO it, so every letter is painted exactly once.\n     Removing either clip raises no error and stays invisible for as long as both copies\n     resolve to the SAME colour, which is what happens wherever the adaptive colour\n     function is unsupported. Where it IS supported and the two disagree — black over an\n     accent fill against white text in the dark theme — the copy underneath shows its\n     antialiased edges all around the letters of the one on top, and the label reads as\n     a halo. */\n  .v-progress-linear-text {\n    /* The two insets of the cut: one on the edge the fill grows FROM, one on the edge it\n       grows towards. They are named after those roles rather than after physical sides,\n       so the three geometry rules further down — horizontal, right-to-left, vertical —\n       all read the same pair. This copy cuts on the start side; the one over the fill\n       swaps them. */\n    --progress-clip-start: calc(100% * var(--fill-fraction));\n    --progress-clip-end: -100vmax;\n    position: absolute;\n    inset: 0;\n    display: flex;\n    align-items: center;\n    justify-content: center;\n    padding-inline: var(--vectis-space-2);\n    color: var(--vectis-color-text);\n    /* The large negative inset on the two sides that do NOT carry the cut is what stops\n       text taller or wider than the bar from being cropped by its own clip. */\n    clip-path: inset(-100vmax var(--progress-clip-end) -100vmax var(--progress-clip-start));\n    /* The same duration and easing as the fill's own length, or the colour boundary\n       would drift away from the fill's edge for the length of the transition. */\n    transition: clip-path var(--vectis-duration-base) var(--vectis-ease-default);\n    /* The bar itself is turned on its side in vertical mode; the text is put back\n       upright here, since a label read sideways is not the point. */\n    writing-mode: horizontal-tb;\n    white-space: nowrap;\n    pointer-events: none;\n  }\n\n  .v-progress-linear[data-value-position='start'] .v-progress-linear-text {\n    justify-content: start;\n  }\n\n  .v-progress-linear[data-value-position='end'] .v-progress-linear-text {\n    justify-content: end;\n  }\n\n  .v-progress-linear-text[data-on-fill] {\n    /* The exact complement of the copy above: the cut moves to the other end of the\n       axis, so the two together cover the whole bar and overlap nowhere. */\n    --progress-clip-start: -100vmax;\n    --progress-clip-end: calc(100% * (1 - var(--fill-fraction)));\n    /* The per-tone fallback colour. The adaptive one cannot simply be written as a\n       second declaration after it: because that declaration contains a var(), a browser\n       with no support does not reject it at parse time — it would win the cascade and\n       only then turn invalid, which resets the colour to inherited and leaves the\n       fallback never applied. The block below is the way round it, being evaluated\n       before any var() substitution. */\n    color: var(--tone-text-fallback);\n  }\n\n  /* Where the adaptive colour function exists, the text picks black or white against\n     whatever colour the fill ended up with. */\n  @supports (color: contrast-color(red)) {\n    .v-progress-linear-text[data-on-fill] {\n      color: contrast-color(var(--progress-fill));\n    }\n  }\n\n  /* In a right-to-left page the fill grows from the right, so the two insets change\n     physical sides — the variables themselves keep their meaning. */\n  .v-progress-linear:dir(rtl) .v-progress-linear-text {\n    clip-path: inset(-100vmax var(--progress-clip-start) -100vmax var(--progress-clip-end));\n  }\n\n  /* Upright, the bar fills from the bottom.\n\n     Changing the writing direction on the element is enough to turn everything: the\n     axis the fill grows along becomes vertical, so the length and the thickness swap\n     places, and both the fill and the animation follow with no rule written twice.\n\n     TRAP — putting zero at the bottom is NOT done by reversing the direction, which\n     would also apply to the text of the two copies: bidirectional reordering would then\n     display \"50 %\" as \"% 50\". The fill is anchored to the far end of the axis instead.\n\n     The length comes from a token because there is nothing to inherit it from: in a\n     parent of automatic height the bar would collapse to nothing. A consumer's own\n     height overrides it, sitting outside our layers. */\n  .v-progress-linear[data-orientation='vertical'] {\n    writing-mode: vertical-lr;\n    inline-size: var(--vectis-control-size-progress-linear-length);\n  }\n\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-fill {\n    inset-inline-start: auto;\n    inset-inline-end: 0;\n  }\n\n  /* The text now stacks along the vertical axis, whose start is the zero end — the\n     bottom of the bar. */\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-text {\n    flex-direction: column-reverse;\n    padding-inline: 0;\n    padding-block: var(--vectis-space-2);\n  }\n\n  /* The cut moves to the vertical axis: the fill rises from the bottom, which is that\n     axis' start. It is therefore the same in both reading directions, which means the\n     right-to-left rule further up has to be neutralized.\n\n     TRAP — the second selector is what neutralizes it, and it is written that way on\n     purpose: it is one step MORE specific than that rule, where the first selector alone\n     would merely tie with it and win by source order — a far more fragile arrangement. */\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-text,\n  .v-progress-linear[data-orientation='vertical']:dir(rtl) .v-progress-linear-text {\n    clip-path: inset(var(--progress-clip-end) -100vmax var(--progress-clip-start) -100vmax);\n  }\n\n  /* When the progress cannot be measured, a bar of fixed size crosses the track from\n     just outside one end to just outside the other. At each extreme it is exactly flush\n     with the edge without ever pulling away from it, which is what makes the loop\n     invisible and keeps the track from ever looking empty — no second bar is needed.\n\n     The easing carries the whole impression: a gradual entry, a quick crossing, a damped\n     exit. A linear run, or an asymmetric curve, immediately reads as mechanical.\n\n     The movement is expressed in LOGICAL properties — a position and a size as\n     percentages of the track — rather than as a transform. One definition then serves\n     the horizontal, the vertical and the right-to-left cases, where a transform, being\n     physical, would need its own keyframes per axis and a flip per direction. */\n  .v-progress-linear[data-indeterminate] {\n    overflow: hidden;\n  }\n\n  .v-progress-linear[data-indeterminate] .v-progress-linear-fill {\n    /* The starting position is derived from this size, and the two must stay tied: that\n       is what has the bar begin exactly off the track rather than half on it. */\n    --progress-bar: 40%;\n    /* The anchoring is put back at the start of the axis, vertical case included — where\n       a measurable progress anchors at the far end instead. */\n    inset-inline-start: 0;\n    inset-inline-end: auto;\n    inline-size: var(--progress-bar);\n    /* The transition of a measurable progress has no place here: switching to this mode\n       would otherwise be animated as the bar growing to its new size. */\n    transition: none;\n    animation: v-progress-linear-indeterminate var(--vectis-duration-1500) var(--vectis-ease-in-out)\n      infinite;\n  }\n\n  @keyframes v-progress-linear-indeterminate {\n    from {\n      inset-inline-start: calc(-1 * var(--progress-bar));\n    }\n\n    to {\n      inset-inline-start: 100%;\n    }\n  }\n\n  /* Turned upright, the axis runs downwards, so the bar would travel from the top down —\n     the opposite of a measurable fill, which rises from the bottom. The same keyframes\n     are simply read backwards, which changes nothing else BECAUSE the easing curve is\n     symmetric; an asymmetric one would need a second set of keyframes.\n\n     Nothing is needed for a right-to-left page: the logical inset already follows the\n     reading direction. */\n  .v-progress-linear[data-orientation='vertical'][data-indeterminate] .v-progress-linear-fill {\n    animation-direction: reverse;\n  }\n\n  @media (prefers-reduced-motion: reduce) {\n    .v-progress-linear-fill,\n    .v-progress-linear-text {\n      transition: none;\n    }\n\n    /* Slowed down and not stopped: a motionless loader no longer says that anything is\n       happening, which is the one thing it exists to say. */\n    .v-progress-linear[data-indeterminate] .v-progress-linear-fill {\n      animation-duration: var(--vectis-duration-5000);\n    }\n  }\n}\n</style>\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA4DA,IAAM,IAAQ,GA2BR,IAAI,EAAY,GAEhB,EAAE,YAAS,gBAAa,QACtB,EAAM,aACN,EAAM,GACd;yBAIE,EAsCM,OAAA;GArCJ,OAAM;GACN,MAAK;GACJ,cAAY,EAAA,CAAA,CAAC,CAAC,SAAS;GACvB,aAAW,EAAA;GACX,eAAa,EAAA,UAAU,KAAA,IAAiB,KAAA,IAAR;GAChC,cAAY,EAAA;GACZ,oBAAkB,EAAA,gBAAW,aAAA,aAA+B,KAAA;GAC5D,uBAAqB,EAAA;GACrB,sBAAoB,EAAA,gBAAa,KAAQ,KAAA;GACzC,iBAAe,EAAA,gBAAgB,KAAA,IAAY,EAAA,CAAA;GAC5C,iBAAc;GACb,iBAAe,EAAA;GACf,OAAK,EAAA;uBAA6B,OAAO,EAAA,CAAA,CAAQ;sBAA2B,EAAA;4BAAqC,EAAA,CAAA,CAAE,CAAC,EAAA,SAAS;;eAM9H,EAAuC,QAAA,EAAjC,OAAM,yBAAwB,GAAA,MAAA,EAAA,GAAA,CAOnB,EAAA,kBAAkB,EAAA,aAAaA,EAAAA,OAAO,YAAA,EAAA,GAAvD,EAWW,GAAA,EAAA,KAAA,EAAA,GAAA,CAVT,EAIO,QAJP,GAIO,CAHL,EAEO,EAAA,QAAA,WAAA;GAFA,OAAO,EAAA,CAAA;GAAU,KAAK,EAAA;GAAM,SAAS,EAAA,CAAA,IAAQ;WAE7C,CAAA,EAAA,EADF,EAAA,CAAA,CAAC,CAAC,SAAS,QAAQ,KAAK,MAAM,EAAA,CAAA,IAAQ,GAAA,CAAA,CAAA,GAAA,CAAA,CAAA,CAAA,CAAA,CAAA,GAG7C,EAIO,QAJP,GAIO,CAHL,EAEO,EAAA,QAAA,WAAA;GAFA,OAAO,EAAA,CAAA;GAAU,KAAK,EAAA;GAAM,SAAS,EAAA,CAAA,IAAQ;WAE7C,CAAA,EAAA,EADF,EAAA,CAAA,CAAC,CAAC,SAAS,QAAQ,KAAK,MAAM,EAAA,CAAA,IAAQ,GAAA,CAAA,CAAA,GAAA,CAAA,CAAA,CAAA,CAAA,CAAA,CAAA,GAAA,EAAA,KAAA,EAAA,IAAA,EAAA,CAAA,GAAA,IAAA,CAAA"}
+{"version":3,"file":"VProgressLinear.vue_vue_type_script_setup_true_lang.js","names":["$slots"],"sources":["../../../src/components/VProgressLinear/VProgressLinear.vue"],"sourcesContent":["<script setup lang=\"ts\">\n// @core — no behavioural JS at all: value normalization and the display string.\n/**\n * A bar filling up as something progresses. The element rendered IS the track, and the\n * whole geometry follows from a single number set on it — the fraction filled, with no\n * unit. Everything is written in logical properties, so turning the bar vertical needs\n * nothing but a change of writing direction.\n *\n * There is no behavioural JavaScript: the value is clamped and a percentage is\n * formatted, and that is all.\n *\n * On naming: pass a `label` saying what is progressing. The text shown inside the\n * bar cannot serve as that name — the role a progress bar carries makes its content\n * presentational, so screen readers do not announce it.\n */\nimport { useAriaLabel } from '../../composables/useAriaLabel'\nimport { useProgressValue } from '../../composables/useProgressValue'\nimport { useMessages } from '../../i18n/state'\nimport { px } from '../../utils/css'\n\n/** What the progress means, in colour. */\nexport type ProgressLinearTone = 'accent' | 'success' | 'warning' | 'danger' | 'neutral'\n\n/** How the track and the fill end. */\nexport type ProgressLinearShape = 'rounded' | 'square'\n\n/** Where the value sits along the bar. */\nexport type ProgressLinearValuePosition = 'start' | 'center' | 'end'\n\n/** Which way the bar fills. */\nexport type ProgressLinearOrientation = 'horizontal' | 'vertical'\n\ninterface ProgressLinearProps {\n  /** How far along it is. Anything outside the range is brought back into it. */\n  value?: number\n  /**\n   * What is progressing, in words, for screen readers. It draws nothing on screen, and falls\n   * back to the design system dictionary; an `aria-label` or `aria-labelledby` of your own\n   * takes precedence over it.\n   */\n  label?: string\n  /** What counts as finished. The other end is always zero. */\n  max?: number\n  /**\n   * Says that the progress cannot be measured: the bar animates continuously and the\n   * value is ignored. It is what to use while waiting for a server that reports no\n   * percentage.\n   */\n  indeterminate?: boolean\n  /** What the progress means, expressed as a colour. */\n  tone?: ProgressLinearTone\n  /**\n   * A colour of your own (hex, CSS name or `oklch()`), which replaces the tone. The\n   * track's own shade is derived from it against the theme, so it follows the light and\n   * the dark one.\n   */\n  color?: string\n  /**\n   * How thick the bar is, always IN PIXELS: `12` and `'12'` both give 12px. It is 4px\n   * by default — bear in mind that showing text inside a bar that thin needs an\n   * explicit thickness.\n   */\n  thickness?: number | string\n  /** Whether the ends of the bar are rounded or square. */\n  shape?: ProgressLinearShape\n  /**\n   * Writes the percentage inside the bar. It is ignored while the progress is\n   * unmeasurable, there being no figure to write.\n   */\n  showValue?: boolean\n  /**\n   * Where that text sits along the bar. On a vertical bar the start is the zero end,\n   * hence the bottom.\n   */\n  valuePosition?: ProgressLinearValuePosition\n  /** Turns the bar upright, filling from the bottom up. */\n  orientation?: ProgressLinearOrientation\n}\n\nconst props = withDefaults(defineProps<ProgressLinearProps>(), {\n  value: 0,\n  label: undefined,\n  max: 100,\n  indeterminate: false,\n  tone: 'accent',\n  color: undefined,\n  thickness: undefined,\n  shape: 'rounded',\n  showValue: false,\n  valuePosition: 'center',\n  orientation: 'horizontal',\n})\n\ndefineSlots<{\n  /**\n   * What to write inside the bar instead of the percentage.\n   *\n   * TRAP — it is rendered TWICE, once over the empty track and once over the filled\n   * part in a colour that contrasts with it, each copy cut at the fill's edge. So\n   * whatever it renders must be pure: anything with a side effect would happen twice.\n   */\n  default?(props: { value: number; max: number; percent: number }): unknown\n}>()\n\n/* The percent sign, and the non-breaking space French puts before it where English puts\n   nothing, are a convention of the language: they belong in the dictionary rather than\n   in this file. Any other format goes through the slot above. */\nconst m = useMessages()\n\nconst {\n  max: normalizedMax,\n  clamped,\n  fraction,\n  percent,\n  roundedPercent,\n} = useProgressValue(\n  () => props.value,\n  () => props.max,\n)\n\n// @a11y\n// The canonical cascade: a consumer's `aria-labelledby`, then their `aria-label`, then the\n// `label` prop, then the dictionary. An indicator takes no name from the text inside it, so\n// without the last step it would have none at all.\nconst ariaLabel = useAriaLabel(() => props.label ?? m.value.progress.label)\n</script>\n\n<template>\n  <div\n    class=\"v-progress-linear v-tone\"\n    role=\"progressbar\"\n    :aria-label=\"ariaLabel\"\n    :data-tone=\"tone\"\n    :data-custom=\"color !== undefined ? '' : undefined\"\n    :data-shape=\"shape\"\n    :data-orientation=\"orientation\"\n    :data-value-position=\"valuePosition\"\n    :data-indeterminate=\"indeterminate ? '' : undefined\"\n    :aria-valuenow=\"indeterminate ? undefined : clamped\"\n    aria-valuemin=\"0\"\n    :aria-valuemax=\"normalizedMax\"\n    :style=\"{\n      '--fill-fraction': String(fraction),\n      '--custom-color': color,\n      '--progress-thickness': px(thickness),\n    }\"\n  >\n    <span class=\"v-progress-linear-fill\" />\n    <!--\n      The same text twice, each copy cut at the fill's edge so that the two complete\n      each other exactly: the first in the ordinary text colour over the empty track,\n      the second over the filled part, coloured to contrast with it. The second is\n      hidden from screen readers, being a duplicate of text already there.\n    -->\n    <template v-if=\"!indeterminate && (showValue || $slots.default)\">\n      <span class=\"v-progress-linear-text\">\n        <slot :value=\"clamped\" :max=\"normalizedMax\" :percent=\"percent\">\n          {{ m.progress.percent(roundedPercent) }}\n        </slot>\n      </span>\n      <span class=\"v-progress-linear-text\" data-on-fill aria-hidden=\"true\">\n        <slot :value=\"clamped\" :max=\"normalizedMax\" :percent=\"percent\">\n          {{ m.progress.percent(roundedPercent) }}\n        </slot>\n      </span>\n    </template>\n  </div>\n</template>\n\n<style>\n@layer vectis.components {\n  /*\n   * The element IS the track, and it takes the whole length available. Sizing it is the\n   * consumer's business, through the parent or through a width of their own — a\n   * consumer's style sits outside our layers and always wins.\n   */\n  .v-progress-linear {\n    --progress-thickness: var(--vectis-control-size-progress-linear-thickness);\n    /* Fill, track and the text over the fill are the tone's solid, soft and on-solid\n       colours, read from the shared table (`.v-tone`, set in the template). */\n    --progress-fill: var(--tone-bg-solid);\n    --progress-track: var(--tone-bg-soft);\n    --progress-text-fallback: var(--tone-text-solid);\n    position: relative;\n    display: block;\n    inline-size: 100%;\n    block-size: var(--progress-thickness);\n    border-radius: var(--vectis-radius-pill);\n    background: var(--progress-track);\n    font-family: var(--vectis-text-family);\n    font-size: var(--vectis-text-caption-size);\n    font-weight: var(--vectis-text-control-weight);\n    line-height: var(--vectis-text-control-leading);\n  }\n\n  .v-progress-linear[data-shape='square'] {\n    border-radius: 0;\n  }\n\n  .v-progress-linear-fill {\n    position: absolute;\n    inset-block: 0;\n    inset-inline-start: 0;\n    inline-size: calc(100% * var(--fill-fraction));\n    border-radius: inherit;\n    background: var(--progress-fill);\n    /*\n     * The fill is animated by changing its LENGTH, which the browser has to lay out\n     * again on every frame. Scaling it would be cheaper, but a scale is physical: it\n     * would have to be undone for the vertical orientation and again for a\n     * right-to-left page, where a logical length simply works.\n     *\n     * The duration and easing are repeated by the clip of the text over the fill, or the\n     * colour boundary would drift away from the fill's own edge for the length of the\n     * transition.\n     */\n    transition: inline-size var(--vectis-duration-base) var(--vectis-ease-default);\n  }\n\n  /* A custom colour replaces the tone: at (0,2,0) it beats the base rule's mapping\n     whatever the order the two are written in. */\n  .v-progress-linear[data-custom] {\n    --progress-fill: var(--custom-color);\n    --progress-track: color-mix(in oklab, var(--custom-color), var(--vectis-color-surface) 85%);\n    --progress-text-fallback: var(--vectis-color-text-on-accent);\n  }\n\n  /* The text inside the bar, in two copies laid over the same box — the track's own,\n     which is why a cut expressed as a fraction of it lands exactly on the fill's edge.\n     Bear in mind that the default 4px thickness cannot hold text at all: showing any\n     implies asking for a thicker bar.\n\n     TRAP — the two copies are COMPLEMENTARY and never superimposed: this one is cut OUT\n     of the filled part, the other cut TO it, so every letter is painted exactly once.\n     Removing either clip raises no error and stays invisible for as long as both copies\n     resolve to the SAME colour, which is what happens wherever the adaptive colour\n     function is unsupported. Where it IS supported and the two disagree — black over an\n     accent fill against white text in the dark theme — the copy underneath shows its\n     antialiased edges all around the letters of the one on top, and the label reads as\n     a halo. */\n  .v-progress-linear-text {\n    /* The two insets of the cut: one on the edge the fill grows FROM, one on the edge it\n       grows towards. They are named after those roles rather than after physical sides,\n       so the three geometry rules further down — horizontal, right-to-left, vertical —\n       all read the same pair. This copy cuts on the start side; the one over the fill\n       swaps them. */\n    --progress-clip-start: calc(100% * var(--fill-fraction));\n    --progress-clip-end: -100vmax;\n    position: absolute;\n    inset: 0;\n    display: flex;\n    align-items: center;\n    justify-content: center;\n    padding-inline: var(--vectis-space-2);\n    color: var(--vectis-color-text);\n    /* The large negative inset on the two sides that do NOT carry the cut is what stops\n       text taller or wider than the bar from being cropped by its own clip. */\n    clip-path: inset(-100vmax var(--progress-clip-end) -100vmax var(--progress-clip-start));\n    /* The same duration and easing as the fill's own length, or the colour boundary\n       would drift away from the fill's edge for the length of the transition. */\n    transition: clip-path var(--vectis-duration-base) var(--vectis-ease-default);\n    /* The bar itself is turned on its side in vertical mode; the text is put back\n       upright here, since a label read sideways is not the point. */\n    writing-mode: horizontal-tb;\n    white-space: nowrap;\n    pointer-events: none;\n  }\n\n  .v-progress-linear[data-value-position='start'] .v-progress-linear-text {\n    justify-content: start;\n  }\n\n  .v-progress-linear[data-value-position='end'] .v-progress-linear-text {\n    justify-content: end;\n  }\n\n  .v-progress-linear-text[data-on-fill] {\n    /* The exact complement of the copy above: the cut moves to the other end of the\n       axis, so the two together cover the whole bar and overlap nowhere. */\n    --progress-clip-start: -100vmax;\n    --progress-clip-end: calc(100% * (1 - var(--fill-fraction)));\n    /* The per-tone fallback colour. The adaptive one cannot simply be written as a\n       second declaration after it: because that declaration contains a var(), a browser\n       with no support does not reject it at parse time — it would win the cascade and\n       only then turn invalid, which resets the colour to inherited and leaves the\n       fallback never applied. The block below is the way round it, being evaluated\n       before any var() substitution. */\n    color: var(--progress-text-fallback);\n  }\n\n  /* Where the adaptive colour function exists, the text picks black or white against\n     whatever colour the fill ended up with. */\n  @supports (color: contrast-color(red)) {\n    .v-progress-linear-text[data-on-fill] {\n      color: contrast-color(var(--progress-fill));\n    }\n  }\n\n  /* In a right-to-left page the fill grows from the right, so the two insets change\n     physical sides — the variables themselves keep their meaning. */\n  .v-progress-linear:dir(rtl) .v-progress-linear-text {\n    clip-path: inset(-100vmax var(--progress-clip-start) -100vmax var(--progress-clip-end));\n  }\n\n  /* Upright, the bar fills from the bottom.\n\n     Changing the writing direction on the element is enough to turn everything: the\n     axis the fill grows along becomes vertical, so the length and the thickness swap\n     places, and both the fill and the animation follow with no rule written twice.\n\n     TRAP — putting zero at the bottom is NOT done by reversing the direction, which\n     would also apply to the text of the two copies: bidirectional reordering would then\n     display \"50 %\" as \"% 50\". The fill is anchored to the far end of the axis instead.\n\n     The length comes from a token because there is nothing to inherit it from: in a\n     parent of automatic height the bar would collapse to nothing. A consumer's own\n     height overrides it, sitting outside our layers. */\n  .v-progress-linear[data-orientation='vertical'] {\n    writing-mode: vertical-lr;\n    inline-size: var(--vectis-control-size-progress-linear-length);\n  }\n\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-fill {\n    inset-inline-start: auto;\n    inset-inline-end: 0;\n  }\n\n  /* The text now stacks along the vertical axis, whose start is the zero end — the\n     bottom of the bar. */\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-text {\n    flex-direction: column-reverse;\n    padding-inline: 0;\n    padding-block: var(--vectis-space-2);\n  }\n\n  /* The cut moves to the vertical axis: the fill rises from the bottom, which is that\n     axis' start. It is therefore the same in both reading directions, which means the\n     right-to-left rule further up has to be neutralized.\n\n     TRAP — the second selector is what neutralizes it, and it is written that way on\n     purpose: it is one step MORE specific than that rule, where the first selector alone\n     would merely tie with it and win by source order — a far more fragile arrangement. */\n  .v-progress-linear[data-orientation='vertical'] .v-progress-linear-text,\n  .v-progress-linear[data-orientation='vertical']:dir(rtl) .v-progress-linear-text {\n    clip-path: inset(var(--progress-clip-end) -100vmax var(--progress-clip-start) -100vmax);\n  }\n\n  /* When the progress cannot be measured, a bar of fixed size crosses the track from\n     just outside one end to just outside the other. At each extreme it is exactly flush\n     with the edge without ever pulling away from it, which is what makes the loop\n     invisible and keeps the track from ever looking empty — no second bar is needed.\n\n     The easing carries the whole impression: a gradual entry, a quick crossing, a damped\n     exit. A linear run, or an asymmetric curve, immediately reads as mechanical.\n\n     The movement is expressed in LOGICAL properties — a position and a size as\n     percentages of the track — rather than as a transform. One definition then serves\n     the horizontal, the vertical and the right-to-left cases, where a transform, being\n     physical, would need its own keyframes per axis and a flip per direction. */\n  .v-progress-linear[data-indeterminate] {\n    overflow: hidden;\n  }\n\n  .v-progress-linear[data-indeterminate] .v-progress-linear-fill {\n    /* The starting position is derived from this size, and the two must stay tied: that\n       is what has the bar begin exactly off the track rather than half on it. */\n    --progress-bar: 40%;\n    /* The anchoring is put back at the start of the axis, vertical case included — where\n       a measurable progress anchors at the far end instead. */\n    inset-inline-start: 0;\n    inset-inline-end: auto;\n    inline-size: var(--progress-bar);\n    /* The transition of a measurable progress has no place here: switching to this mode\n       would otherwise be animated as the bar growing to its new size. */\n    transition: none;\n    animation: v-progress-linear-indeterminate var(--vectis-duration-1500) var(--vectis-ease-in-out)\n      infinite;\n  }\n\n  @keyframes v-progress-linear-indeterminate {\n    from {\n      inset-inline-start: calc(-1 * var(--progress-bar));\n    }\n\n    to {\n      inset-inline-start: 100%;\n    }\n  }\n\n  /* Turned upright, the axis runs downwards, so the bar would travel from the top down —\n     the opposite of a measurable fill, which rises from the bottom. The same keyframes\n     are simply read backwards, which changes nothing else BECAUSE the easing curve is\n     symmetric; an asymmetric one would need a second set of keyframes.\n\n     Nothing is needed for a right-to-left page: the logical inset already follows the\n     reading direction. */\n  .v-progress-linear[data-orientation='vertical'][data-indeterminate] .v-progress-linear-fill {\n    animation-direction: reverse;\n  }\n\n  @media (prefers-reduced-motion: reduce) {\n    .v-progress-linear-fill,\n    .v-progress-linear-text {\n      transition: none;\n    }\n\n    /* Slowed down and not stopped: a motionless loader no longer says that anything is\n       happening, which is the one thing it exists to say. */\n    .v-progress-linear[data-indeterminate] .v-progress-linear-fill {\n      animation-duration: var(--vectis-duration-5000);\n    }\n  }\n}\n</style>\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA+EA,IAAM,IAAQ,GA4BR,IAAI,EAAY,GAEhB,EACJ,KAAK,GACL,YACA,aACA,YACA,sBACE,QACI,EAAM,aACN,EAAM,GACd,GAMM,IAAY,QAAmB,EAAM,SAAS,EAAE,MAAM,SAAS,KAAK;yBAIxE,EAsCM,OAAA;GArCJ,OAAM;GACN,MAAK;GACJ,cAAY,EAAA,CAAA;GACZ,aAAW,EAAA;GACX,eAAa,EAAA,UAAU,KAAA,IAAiB,KAAA,IAAR;GAChC,cAAY,EAAA;GACZ,oBAAkB,EAAA;GAClB,uBAAqB,EAAA;GACrB,sBAAoB,EAAA,gBAAa,KAAQ,KAAA;GACzC,iBAAe,EAAA,gBAAgB,KAAA,IAAY,EAAA,CAAA;GAC5C,iBAAc;GACb,iBAAe,EAAA,CAAA;GACf,OAAK,EAAA;uBAA6B,OAAO,EAAA,CAAA,CAAQ;sBAA2B,EAAA;4BAAqC,EAAA,CAAA,CAAE,CAAC,EAAA,SAAS;;eAM9H,EAAuC,QAAA,EAAjC,OAAM,yBAAwB,GAAA,MAAA,EAAA,GAAA,CAOnB,EAAA,kBAAkB,EAAA,aAAaA,EAAAA,OAAO,YAAA,EAAA,GAAvD,EAWW,GAAA,EAAA,KAAA,EAAA,GAAA,CAVT,EAIO,QAJP,GAIO,CAHL,EAEO,EAAA,QAAA,WAAA;GAFA,OAAO,EAAA,CAAA;GAAU,KAAK,EAAA,CAAA;GAAgB,SAAS,EAAA,CAAA;WAE/C,CAAA,EAAA,EADF,EAAA,CAAA,CAAC,CAAC,SAAS,QAAQ,EAAA,CAAA,CAAc,CAAA,GAAA,CAAA,CAAA,CAAA,CAAA,CAAA,GAGxC,EAIO,QAJP,GAIO,CAHL,EAEO,EAAA,QAAA,WAAA;GAFA,OAAO,EAAA,CAAA;GAAU,KAAK,EAAA,CAAA;GAAgB,SAAS,EAAA,CAAA;WAE/C,CAAA,EAAA,EADF,EAAA,CAAA,CAAC,CAAC,SAAS,QAAQ,EAAA,CAAA,CAAc,CAAA,GAAA,CAAA,CAAA,CAAA,CAAA,CAAA,CAAA,GAAA,EAAA,KAAA,EAAA,IAAA,EAAA,CAAA,GAAA,IAAA,CAAA"}

package/dist/components/VRadio/VRadio.css

@@ -1,2 +1,2 @@
 @layer vectis.reset, vectis.tokens, vectis.components, vectis.utilities;
-@layer vectis.components{.v-radio{align-items:center;gap:var(--vectis-space-2);font-family:var(--vectis-text-family);font-size:var(--vectis-text-label-size);color:var(--vectis-color-text);cursor:pointer;display:inline-flex}.v-radio[data-label-position=start]{flex-direction:row-reverse}.v-radio[data-spread]{justify-content:space-between;display:flex}.v-radio-input{opacity:0;pointer-events:none;width:1px;height:1px;margin:0;position:absolute}.v-radio-dot{width:var(--vectis-control-size-check);height:var(--vectis-control-size-check);background:var(--vectis-color-surface);border:var(--vectis-control-border-width) solid var(--vectis-color-border-strong);border-radius:var(--vectis-radius-full);color:var(--vectis-color-text-on-accent);transition:background-color var(--vectis-duration-fast) var(--vectis-ease-default), border-color var(--vectis-duration-fast) var(--vectis-ease-default);flex:none;place-items:center;display:inline-grid}.v-radio-dot:before{content:"";width:var(--vectis-control-size-check-dot);height:var(--vectis-control-size-check-dot);border-radius:var(--vectis-radius-full);opacity:0;transition:opacity var(--vectis-duration-fast) var(--vectis-ease-default);background:currentColor}.v-radio:hover .v-radio-input:not(:disabled,:checked)+.v-radio-dot{border-color:color-mix(in oklab, var(--vectis-color-border-strong), var(--vectis-color-text) 15%)}.v-radio-input:checked+.v-radio-dot{background:var(--vectis-color-accent);border-color:var(--vectis-color-accent)}.v-radio-input:checked+.v-radio-dot:before{opacity:1}.v-radio:hover .v-radio-input:not(:disabled):checked+.v-radio-dot{background:var(--vectis-color-accent-hover);border-color:var(--vectis-color-accent-hover)}.v-radio-input:focus-visible+.v-radio-dot{outline:var(--vectis-focus-ring-width) solid var(--vectis-focus-ring-color);outline-offset:var(--vectis-focus-ring-offset)}:is(.v-radio-input:user-invalid+.v-radio-dot,.v-radio-input[aria-invalid=true]+.v-radio-dot){border-color:var(--vectis-color-danger)}.v-radio:has(.v-radio-input:disabled){color:var(--vectis-color-text-subtle);cursor:not-allowed}.v-radio-input:disabled+.v-radio-dot{background:var(--vectis-color-surface-muted);border-color:var(--vectis-color-border);color:var(--vectis-color-text-subtle)}@media (prefers-reduced-motion:reduce){.v-radio-dot,.v-radio-dot:before{transition:none}}}
+@layer vectis.components{.v-radio-dot{width:var(--vectis-control-size-check);height:var(--vectis-control-size-check);border:var(--vectis-control-border-width) solid var(--vectis-color-border-strong);border-radius:var(--vectis-radius-pill);color:var(--vectis-color-text-on-accent);transition:background-color var(--vectis-duration-fast) var(--vectis-ease-default), border-color var(--vectis-duration-fast) var(--vectis-ease-default);background:0 0;place-items:center;display:inline-grid}.v-radio-dot:before{content:"";width:var(--vectis-control-size-check-dot);height:var(--vectis-control-size-check-dot);border-radius:var(--vectis-radius-pill);opacity:0;transition:opacity var(--vectis-duration-fast) var(--vectis-ease-default);background:currentColor}.v-radio-input:checked+.v-radio-dot:before{opacity:1}.v-radio:not([data-readonly]) .v-choice-row:hover .v-radio-input:not(:disabled,:checked)+.v-radio-dot{border-color:color-mix(in oklab, var(--vectis-color-border-strong), var(--vectis-color-text) 15%)}.v-radio-input:checked+.v-radio-dot{background:var(--vectis-color-accent);border-color:var(--vectis-color-accent)}.v-radio:not([data-readonly]) .v-choice-row:hover .v-radio-input:not(:disabled):checked+.v-radio-dot{background:var(--vectis-color-accent-hover);border-color:var(--vectis-color-accent-hover)}:where(.v-radio[data-readonly]) .v-radio-input+.v-radio-dot{background:var(--vectis-color-surface-sunken);border-color:var(--vectis-color-border)}:where(.v-radio[data-readonly]) .v-radio-input:checked+.v-radio-dot{background:var(--vectis-color-text-muted);border-color:var(--vectis-color-text-muted);color:var(--vectis-color-surface)}:is(.v-radio-input:user-invalid+.v-radio-dot,.v-radio-input[aria-invalid=true]+.v-radio-dot){border-color:var(--vectis-color-danger)}.v-radio-input:disabled+.v-radio-dot{background:var(--vectis-color-surface-muted);border-color:var(--vectis-color-border);color:var(--vectis-color-text-subtle)}@media (prefers-reduced-motion:reduce){.v-radio-dot,.v-radio-dot:before{transition:none}}}

package/dist/components/VRadio/VRadio.d.ts

@@ -1,21 +1,21 @@
-/**
- * A radio button whose dot is drawn by the design system, on the same principle as
- * VCheckbox: the real `<input type="radio">` stays in place and only its own drawing
- * is hidden.
- *
- * The group is native as well. Several VRadio sharing the same `name` and the same
- * v-model form one choice, and it is the browser that then makes the arrow keys move
- * between them, that lets only one be selected, and that gives the group a single
- * stop in the tab order. There is no JavaScript here for any of it.
- */
+import { ItemValue } from '../../types.js';
+/** Which side of the dot the label sits on. */
+export type RadioLabelPosition = 'start' | 'end';
 interface RadioProps {
     /**
      * What choosing this button means. The group's v-model holds the value of the
      * selected button, so this is what it becomes when this one is picked.
      */
-    value: string;
+    value: ItemValue;
+    /** The text beside the dot, which names it. The default slot replaces it. */
+    label?: string;
+    /**
+     * A line of help under the label. It is tied to the radio button for assistive
+     * technology, so it is read out after the label rather than as part of it.
+     */
+    hint?: string;
     /** Which side of the dot the label sits on. */
-    labelPosition?: 'start' | 'end';
+    labelPosition?: RadioLabelPosition;
     /**
      * Pushes the label and the dot to opposite ends of the line, the row taking the
      * full width available.
@@ -28,24 +28,42 @@ interface RadioProps {
     invalid?: boolean;
     /** Makes this choice unusable, greyed out through the colour tokens. */
     disabled?: boolean;
+    /**
+     * Shows the selection without allowing it to be changed. The button can still be
+     * focused and is still submitted with its form; a click or an arrow key simply selects
+     * nothing. Set it on every button of the group.
+     */
+    readonly?: boolean;
 }
 type __VLS_Props = RadioProps;
 type __VLS_Slots = {
-    /** The label. It is clickable, the whole component being wrapped in a `<label>`. */
+    /** The label, when it needs more than the `label` prop's text. It is clickable. */
     default?(): unknown;
 };
 type __VLS_ModelProps = {
-    modelValue?: string;
+    /**
+     * The value selected in the group, shared by every radio carrying the same `name`. It is
+     * empty until one is chosen, and a radio is selected when it matches its own `value`.
+     */
+    modelValue?: ItemValue;
 };
 type __VLS_PublicProps = __VLS_Props & __VLS_ModelProps;
-declare const __VLS_base: import('vue').DefineComponent<__VLS_PublicProps, {}, {}, {}, {}, import('vue').ComponentOptionsMixin, import('vue').ComponentOptionsMixin, {
-    "update:modelValue": (value: string) => any;
+declare const __VLS_base: import('vue').DefineComponent<__VLS_PublicProps, {
+    /** Moves the focus to the real radio button. */
+    focus: (options?: FocusOptions) => void | undefined;
+    /** The real `<input type="radio">`, for what `focus` does not cover. */
+    el: import('vue').Ref<HTMLInputElement | null, HTMLInputElement | null>;
+}, {}, {}, {}, import('vue').ComponentOptionsMixin, import('vue').ComponentOptionsMixin, {
+    "update:modelValue": (value: ItemValue) => any;
 }, string, import('vue').PublicProps, Readonly<__VLS_PublicProps> & Readonly<{
-    "onUpdate:modelValue"?: ((value: string) => any) | undefined;
+    "onUpdate:modelValue"?: ((value: ItemValue) => any) | undefined;
 }>, {
+    label: string;
     disabled: boolean;
     invalid: boolean;
-    labelPosition: "start" | "end";
+    hint: string;
+    readonly: boolean;
+    labelPosition: RadioLabelPosition;
     spread: boolean;
 }, {}, {}, {}, string, import('vue').ComponentProvideOptions, false, {}, any>;
 declare const __VLS_export: __VLS_WithSlots<typeof __VLS_base, __VLS_Slots>;

package/dist/components/VRadio/VRadio.js.map

@@ -1 +1 @@
-{"version":3,"file":"VRadio.js","names":[],"sources":["../../../src/components/VRadio/VRadio.vue"],"sourcesContent":["<script setup lang=\"ts\">\n/**\n * A radio button whose dot is drawn by the design system, on the same principle as\n * VCheckbox: the real `<input type=\"radio\">` stays in place and only its own drawing\n * is hidden.\n *\n * The group is native as well. Several VRadio sharing the same `name` and the same\n * v-model form one choice, and it is the browser that then makes the arrow keys move\n * between them, that lets only one be selected, and that gives the group a single\n * stop in the tab order. There is no JavaScript here for any of it.\n */\ninterface RadioProps {\n  /**\n   * What choosing this button means. The group's v-model holds the value of the\n   * selected button, so this is what it becomes when this one is picked.\n   */\n  value: string\n  /** Which side of the dot the label sits on. */\n  labelPosition?: 'start' | 'end'\n  /**\n   * Pushes the label and the dot to opposite ends of the line, the row taking the\n   * full width available.\n   */\n  spread?: boolean\n  /**\n   * Marks the field as invalid, which colours the dot and tells assistive technology\n   * so. It is for a rule the browser cannot check by itself.\n   */\n  invalid?: boolean\n  /** Makes this choice unusable, greyed out through the colour tokens. */\n  disabled?: boolean\n}\n\nwithDefaults(defineProps<RadioProps>(), {\n  labelPosition: 'end',\n  spread: false,\n  invalid: false,\n  disabled: false,\n})\n\n// @a11y — the component's ONLY behavioural decision, and it buys the whole keyboard.\n// Moving between the buttons of a group is the browser's job, but it only groups\n// inputs that share a `name` — so redirecting the attributes is what makes the arrow\n// keys work at all. The root being the <label>, `name` left on it would reach\n// nothing.\ndefineOptions({ inheritAttrs: false })\n\nconst model = defineModel<string>({ default: '' })\n\ndefineSlots<{\n  /** The label. It is clickable, the whole component being wrapped in a `<label>`. */\n  default?(): unknown\n}>()\n</script>\n\n<template>\n  <label class=\"v-radio\" :data-label-position=\"labelPosition\" :data-spread=\"spread || undefined\">\n    <input\n      v-model=\"model\"\n      type=\"radio\"\n      class=\"v-radio-input\"\n      v-bind=\"$attrs\"\n      :value=\"value\"\n      :disabled=\"disabled\"\n      :aria-invalid=\"invalid || undefined\"\n    />\n    <span class=\"v-radio-dot\" aria-hidden=\"true\" />\n    <span v-if=\"$slots.default\" class=\"v-radio-label\"><slot /></span>\n  </label>\n</template>\n\n<style>\n@layer vectis.components {\n  .v-radio {\n    display: inline-flex;\n    align-items: center;\n    gap: var(--vectis-space-2);\n    font-family: var(--vectis-text-family);\n    font-size: var(--vectis-text-label-size);\n    color: var(--vectis-color-text);\n    cursor: pointer;\n  }\n\n  /* The input is taken out of the flow by its absolute position, so reversing the\n     row only ever swaps the dot and the label. */\n  .v-radio[data-label-position='start'] {\n    flex-direction: row-reverse;\n  }\n\n  .v-radio[data-spread] {\n    display: flex;\n    justify-content: space-between;\n  }\n\n  /* Hidden with `opacity` and never with `display: none`, which would take the input\n     out of the tab order, out of the form and out of its own group. */\n  .v-radio-input {\n    position: absolute;\n    opacity: 0;\n    width: 1px;\n    height: 1px;\n    margin: 0;\n    pointer-events: none;\n  }\n\n  /* The dot works exactly like VCheckbox's box — the accent colour fills it once the\n     input is checked — with the small inner disc drawn as a pseudo-element in\n     currentcolor, so it follows whatever colour the ring takes. */\n  .v-radio-dot {\n    display: inline-grid;\n    place-items: center;\n    width: var(--vectis-control-size-check);\n    height: var(--vectis-control-size-check);\n    flex: none;\n    background: var(--vectis-color-surface);\n    border: var(--vectis-control-border-width) solid var(--vectis-color-border-strong);\n    border-radius: var(--vectis-radius-full);\n    color: var(--vectis-color-text-on-accent);\n    transition:\n      background-color var(--vectis-duration-fast) var(--vectis-ease-default),\n      border-color var(--vectis-duration-fast) var(--vectis-ease-default);\n  }\n\n  .v-radio-dot::before {\n    content: '';\n    width: var(--vectis-control-size-check-dot);\n    height: var(--vectis-control-size-check-dot);\n    border-radius: var(--vectis-radius-full);\n    background: currentcolor;\n    opacity: 0;\n    transition: opacity var(--vectis-duration-fast) var(--vectis-ease-default);\n  }\n\n  .v-radio:hover .v-radio-input:not(:disabled, :checked) + .v-radio-dot {\n    border-color: color-mix(\n      in oklab,\n      var(--vectis-color-border-strong),\n      var(--vectis-color-text) 15%\n    );\n  }\n\n  .v-radio-input:checked + .v-radio-dot {\n    background: var(--vectis-color-accent);\n    border-color: var(--vectis-color-accent);\n  }\n\n  .v-radio-input:checked + .v-radio-dot::before {\n    opacity: 1;\n  }\n\n  .v-radio:hover .v-radio-input:not(:disabled):checked + .v-radio-dot {\n    background: var(--vectis-color-accent-hover);\n    border-color: var(--vectis-color-accent-hover);\n  }\n\n  .v-radio-input:focus-visible + .v-radio-dot {\n    outline: var(--vectis-focus-ring-width) solid var(--vectis-focus-ring-color);\n    outline-offset: var(--vectis-focus-ring-offset);\n  }\n\n  .v-radio-input:user-invalid + .v-radio-dot,\n  .v-radio-input[aria-invalid='true'] + .v-radio-dot {\n    border-color: var(--vectis-color-danger);\n  }\n\n  /* A disabled radio greys out through the colour tokens, the same ones VButton\n     uses, and never through opacity. */\n  .v-radio:has(.v-radio-input:disabled) {\n    color: var(--vectis-color-text-subtle);\n    cursor: not-allowed;\n  }\n\n  .v-radio-input:disabled + .v-radio-dot {\n    background: var(--vectis-color-surface-muted);\n    border-color: var(--vectis-color-border);\n    color: var(--vectis-color-text-subtle);\n  }\n\n  @media (prefers-reduced-motion: reduce) {\n    .v-radio-dot,\n    .v-radio-dot::before {\n      transition: none;\n    }\n  }\n}\n</style>\n"],"mappings":""}
+{"version":3,"file":"VRadio.js","names":[],"sources":["../../../src/components/VRadio/VRadio.vue"],"sourcesContent":["<script setup lang=\"ts\">\n/**\n * A radio button whose dot is drawn by the design system, on the same principle as\n * VCheckbox: the real `<input type=\"radio\">` stays in place and only its own drawing\n * is hidden.\n *\n * The group is native as well. Several VRadio sharing the same `name` and the same\n * v-model form one choice, and it is the browser that then makes the arrow keys move\n * between them, that lets only one be selected, and that gives the group a single\n * stop in the tab order. There is no JavaScript here for any of it; the only piece this\n * component writes is the refusal `readonly` asks for, which a radio has no native form of.\n */\n\nimport { ref } from 'vue'\n\nimport { useFieldIds } from '../../composables/useFieldIds'\nimport { useRootAttrs } from '../../composables/useRootAttrs'\nimport type { ItemValue } from '../../types'\n\n/** Which side of the dot the label sits on. */\nexport type RadioLabelPosition = 'start' | 'end'\n\ninterface RadioProps {\n  /**\n   * What choosing this button means. The group's v-model holds the value of the\n   * selected button, so this is what it becomes when this one is picked.\n   */\n  value: ItemValue\n  /** The text beside the dot, which names it. The default slot replaces it. */\n  label?: string\n  /**\n   * A line of help under the label. It is tied to the radio button for assistive\n   * technology, so it is read out after the label rather than as part of it.\n   */\n  hint?: string\n  /** Which side of the dot the label sits on. */\n  labelPosition?: RadioLabelPosition\n  /**\n   * Pushes the label and the dot to opposite ends of the line, the row taking the\n   * full width available.\n   */\n  spread?: boolean\n  /**\n   * Marks the field as invalid, which colours the dot and tells assistive technology\n   * so. It is for a rule the browser cannot check by itself.\n   */\n  invalid?: boolean\n  /** Makes this choice unusable, greyed out through the colour tokens. */\n  disabled?: boolean\n  /**\n   * Shows the selection without allowing it to be changed. The button can still be\n   * focused and is still submitted with its form; a click or an arrow key simply selects\n   * nothing. Set it on every button of the group.\n   */\n  readonly?: boolean\n}\n\nconst props = withDefaults(defineProps<RadioProps>(), {\n  label: undefined,\n  hint: undefined,\n  labelPosition: 'end',\n  spread: false,\n  invalid: false,\n  disabled: false,\n  readonly: false,\n})\n\n// @a11y — the redirection buys the whole keyboard. Moving between the buttons of a group is\n// the browser's job, but it only groups inputs that share a `name` — so redirecting the\n// attributes is what makes the arrow keys work at all. The root being a layout box, `name`\n// left on it would reach nothing.\ndefineOptions({ inheritAttrs: false })\nconst { attrs, rootClass, rootStyle, forwardedAttrs } = useRootAttrs()\nconst { hintId, describedBy } = useFieldIds(attrs, () => !!props.hint)\n\n/**\n * The value selected in the group, shared by every radio carrying the same `name`. It is\n * empty until one is chosen, and a radio is selected when it matches its own `value`.\n */\nconst model = defineModel<ItemValue>({ default: '' })\n\ndefineSlots<{\n  /** The label, when it needs more than the `label` prop's text. It is clickable. */\n  default?(): unknown\n}>()\n\nconst inputEl = ref<HTMLInputElement | null>(null)\n\n// @core\n// The native `readonly` attribute does nothing on a radio button. Cancelling the click is\n// what refuses the selection: the browser puts the group's previous selection back and fires\n// no `change`. It covers the arrow keys too, which select the next button of the group\n// through a click the browser dispatches on it — so the focus still moves, the selection\n// does not.\n//\n// No `aria-readonly` goes with it, unlike VCheckbox and VSwitch: ARIA allows it on a\n// `radiogroup` and not on a `radio`, and axe fails the page for it.\nfunction refuseWhenReadonly(event: MouseEvent) {\n  if (props.readonly) event.preventDefault()\n}\n\n// The root is a wrapper, so a template ref on the component reaches the layout box and not\n// the control: these two are the way to the real radio button.\ndefineExpose({\n  /** Moves the focus to the real radio button. */\n  focus: (options?: FocusOptions) => inputEl.value?.focus(options),\n  /** The real `<input type=\"radio\">`, for what `focus` does not cover. */\n  el: inputEl,\n})\n</script>\n\n<template>\n  <span\n    class=\"v-radio v-choice\"\n    :class=\"rootClass\"\n    :style=\"rootStyle\"\n    :data-label-position=\"labelPosition\"\n    :data-spread=\"spread ? '' : undefined\"\n    :data-readonly=\"readonly ? '' : undefined\"\n  >\n    <label class=\"v-choice-row\">\n      <input\n        ref=\"inputEl\"\n        v-model=\"model\"\n        type=\"radio\"\n        class=\"v-radio-input v-hidden-input\"\n        v-bind=\"forwardedAttrs\"\n        :value=\"value\"\n        :disabled=\"disabled\"\n        :aria-invalid=\"invalid || undefined\"\n        :aria-describedby=\"describedBy\"\n        @click=\"refuseWhenReadonly\"\n      />\n      <span class=\"v-radio-dot\" aria-hidden=\"true\" />\n      <span v-if=\"$slots.default || label\" class=\"v-radio-label v-choice-label\">\n        <slot>{{ label }}</slot>\n      </span>\n    </label>\n    <span v-if=\"hint\" :id=\"hintId\" class=\"v-radio-hint v-choice-hint\">{{ hint }}</span>\n  </span>\n</template>\n\n<style>\n@layer vectis.components {\n  /* The dot works exactly like VCheckbox's box, the accent filling it once the input is\n     checked, with the small inner disc drawn as a pseudo-element in currentcolor so it\n     follows whatever colour the state gives the ring's content. */\n  .v-radio-dot {\n    display: inline-grid;\n    place-items: center;\n    width: var(--vectis-control-size-check);\n    height: var(--vectis-control-size-check);\n    background: transparent;\n    border: var(--vectis-control-border-width) solid var(--vectis-color-border-strong);\n    border-radius: var(--vectis-radius-pill);\n    color: var(--vectis-color-text-on-accent);\n    transition:\n      background-color var(--vectis-duration-fast) var(--vectis-ease-default),\n      border-color var(--vectis-duration-fast) var(--vectis-ease-default);\n  }\n\n  .v-radio-dot::before {\n    content: '';\n    width: var(--vectis-control-size-check-dot);\n    height: var(--vectis-control-size-check-dot);\n    border-radius: var(--vectis-radius-pill);\n    background: currentcolor;\n    opacity: 0;\n    transition: opacity var(--vectis-duration-fast) var(--vectis-ease-default);\n  }\n\n  .v-radio-input:checked + .v-radio-dot::before {\n    opacity: 1;\n  }\n\n  /* The state painting, rule for rule the same as VCheckbox's with its own classes: keep the\n     two ALIGNED. Every state below but the hovers weighs (0,3,0), so their ORDER arbitrates\n     them: checked, read-only, invalid, then disabled last. The two hovers exclude every state\n     they must not repaint, so no order argument reaches them. */\n  .v-radio:not([data-readonly])\n    .v-choice-row:hover\n    .v-radio-input:not(:disabled, :checked)\n    + .v-radio-dot {\n    border-color: color-mix(\n      in oklab,\n      var(--vectis-color-border-strong),\n      var(--vectis-color-text) 15%\n    );\n  }\n\n  .v-radio-input:checked + .v-radio-dot {\n    background: var(--vectis-color-accent);\n    border-color: var(--vectis-color-accent);\n  }\n\n  .v-radio:not([data-readonly])\n    .v-choice-row:hover\n    .v-radio-input:not(:disabled):is(:checked)\n    + .v-radio-dot {\n    background: var(--vectis-color-accent-hover);\n    border-color: var(--vectis-color-accent-hover);\n  }\n\n  /* Read-only sinks like a read-only field, and a selected control trades the accent for the\n     muted text colour: still plainly on, no longer inviting a click. The mark takes the\n     surface colour, which contrasts with that fill in both themes, where white would vanish\n     against the light grey of the dark theme. `:where()` keeps both rules at the weight of\n     the states they sit between. */\n  :where(.v-radio[data-readonly]) .v-radio-input + .v-radio-dot {\n    background: var(--vectis-color-surface-sunken);\n    border-color: var(--vectis-color-border);\n  }\n\n  :where(.v-radio[data-readonly]) .v-radio-input:checked + .v-radio-dot {\n    background: var(--vectis-color-text-muted);\n    border-color: var(--vectis-color-text-muted);\n    color: var(--vectis-color-surface);\n  }\n\n  .v-radio-input:user-invalid + .v-radio-dot,\n  .v-radio-input[aria-invalid='true'] + .v-radio-dot {\n    border-color: var(--vectis-color-danger);\n  }\n\n  .v-radio-input:disabled + .v-radio-dot {\n    background: var(--vectis-color-surface-muted);\n    border-color: var(--vectis-color-border);\n    color: var(--vectis-color-text-subtle);\n  }\n\n  @media (prefers-reduced-motion: reduce) {\n    .v-radio-dot,\n    .v-radio-dot::before {\n      transition: none;\n    }\n  }\n}\n</style>\n"],"mappings":""}

package/dist/components/VRadio/VRadio.vue_vue_type_script_setup_true_lang.js

@@ -1,17 +1,26 @@
-import { createCommentVNode as e, createElementBlock as t, createElementVNode as n, defineComponent as r, mergeModels as i, mergeProps as a, openBlock as o, renderSlot as s, useModel as c, vModelRadio as l, withDirectives as u } from "vue";
+import { useRootAttrs as e } from "../../composables/useRootAttrs.js";
+import { useFieldIds as t } from "../../composables/useFieldIds.js";
+import { createCommentVNode as n, createElementBlock as r, createElementVNode as i, createTextVNode as a, defineComponent as o, mergeModels as s, mergeProps as c, normalizeClass as l, normalizeStyle as u, openBlock as d, ref as f, renderSlot as p, toDisplayString as m, unref as h, useModel as g, vModelRadio as _, withDirectives as v } from "vue";
 //#region src/components/VRadio/VRadio.vue?vue&type=script&setup=true&lang.ts
-var d = ["data-label-position", "data-spread"], f = [
+var y = [
+	"data-label-position",
+	"data-spread",
+	"data-readonly"
+], b = { class: "v-choice-row" }, x = [
 	"value",
 	"disabled",
-	"aria-invalid"
-], p = {
+	"aria-invalid",
+	"aria-describedby"
+], S = {
 	key: 0,
-	class: "v-radio-label"
-}, m = /*@__PURE__*/ r({
+	class: "v-radio-label v-choice-label"
+}, C = ["id"], w = /*@__PURE__*/ o({
 	inheritAttrs: !1,
 	__name: "VRadio",
-	props: /*@__PURE__*/ i({
+	props: /*@__PURE__*/ s({
 		value: {},
+		label: { default: void 0 },
+		hint: { default: void 0 },
 		labelPosition: { default: "end" },
 		spread: {
 			type: Boolean,
@@ -24,37 +33,57 @@ var d = ["data-label-position", "data-spread"], f = [
 		disabled: {
 			type: Boolean,
 			default: !1
+		},
+		readonly: {
+			type: Boolean,
+			default: !1
 		}
 	}, {
 		modelValue: { default: "" },
 		modelModifiers: {}
 	}),
 	emits: ["update:modelValue"],
-	setup(r) {
-		let i = c(r, "modelValue");
-		return (c, m) => (o(), t("label", {
-			class: "v-radio",
-			"data-label-position": r.labelPosition,
-			"data-spread": r.spread || void 0
-		}, [
-			u(n("input", a({
-				"onUpdate:modelValue": m[0] ||= (e) => i.value = e,
+	setup(o, { expose: s }) {
+		let w = o, { attrs: T, rootClass: E, rootStyle: D, forwardedAttrs: O } = e(), { hintId: k, describedBy: A } = t(T, () => !!w.hint), j = g(o, "modelValue"), M = f(null);
+		function N(e) {
+			w.readonly && e.preventDefault();
+		}
+		return s({
+			focus: (e) => M.value?.focus(e),
+			el: M
+		}), (e, t) => (d(), r("span", {
+			class: l(["v-radio v-choice", h(E)]),
+			style: u(h(D)),
+			"data-label-position": o.labelPosition,
+			"data-spread": o.spread ? "" : void 0,
+			"data-readonly": o.readonly ? "" : void 0
+		}, [i("label", b, [
+			v(i("input", c({
+				ref_key: "inputEl",
+				ref: M,
+				"onUpdate:modelValue": t[0] ||= (e) => j.value = e,
 				type: "radio",
-				class: "v-radio-input"
-			}, c.$attrs, {
-				value: r.value,
-				disabled: r.disabled,
-				"aria-invalid": r.invalid || void 0
-			}), null, 16, f), [[l, i.value]]),
-			m[1] ||= n("span", {
+				class: "v-radio-input v-hidden-input"
+			}, h(O), {
+				value: o.value,
+				disabled: o.disabled,
+				"aria-invalid": o.invalid || void 0,
+				"aria-describedby": h(A),
+				onClick: N
+			}), null, 16, x), [[_, j.value]]),
+			t[1] ||= i("span", {
 				class: "v-radio-dot",
 				"aria-hidden": "true"
 			}, null, -1),
-			c.$slots.default ? (o(), t("span", p, [s(c.$slots, "default")])) : e("", !0)
-		], 8, d));
+			e.$slots.default || o.label ? (d(), r("span", S, [p(e.$slots, "default", {}, () => [a(m(o.label), 1)])])) : n("", !0)
+		]), o.hint ? (d(), r("span", {
+			key: 0,
+			id: h(k),
+			class: "v-radio-hint v-choice-hint"
+		}, m(o.hint), 9, C)) : n("", !0)], 14, y));
 	}
 });
 //#endregion
-export { m as default };
+export { w as default };
 
 //# sourceMappingURL=VRadio.vue_vue_type_script_setup_true_lang.js.map

package/dist/components/VRadio/VRadio.vue_vue_type_script_setup_true_lang.js.map

@@ -1 +1 @@
-{"version":3,"file":"VRadio.vue_vue_type_script_setup_true_lang.js","names":["$attrs","$slots"],"sources":["../../../src/components/VRadio/VRadio.vue"],"sourcesContent":["<script setup lang=\"ts\">\n/**\n * A radio button whose dot is drawn by the design system, on the same principle as\n * VCheckbox: the real `<input type=\"radio\">` stays in place and only its own drawing\n * is hidden.\n *\n * The group is native as well. Several VRadio sharing the same `name` and the same\n * v-model form one choice, and it is the browser that then makes the arrow keys move\n * between them, that lets only one be selected, and that gives the group a single\n * stop in the tab order. There is no JavaScript here for any of it.\n */\ninterface RadioProps {\n  /**\n   * What choosing this button means. The group's v-model holds the value of the\n   * selected button, so this is what it becomes when this one is picked.\n   */\n  value: string\n  /** Which side of the dot the label sits on. */\n  labelPosition?: 'start' | 'end'\n  /**\n   * Pushes the label and the dot to opposite ends of the line, the row taking the\n   * full width available.\n   */\n  spread?: boolean\n  /**\n   * Marks the field as invalid, which colours the dot and tells assistive technology\n   * so. It is for a rule the browser cannot check by itself.\n   */\n  invalid?: boolean\n  /** Makes this choice unusable, greyed out through the colour tokens. */\n  disabled?: boolean\n}\n\nwithDefaults(defineProps<RadioProps>(), {\n  labelPosition: 'end',\n  spread: false,\n  invalid: false,\n  disabled: false,\n})\n\n// @a11y — the component's ONLY behavioural decision, and it buys the whole keyboard.\n// Moving between the buttons of a group is the browser's job, but it only groups\n// inputs that share a `name` — so redirecting the attributes is what makes the arrow\n// keys work at all. The root being the <label>, `name` left on it would reach\n// nothing.\ndefineOptions({ inheritAttrs: false })\n\nconst model = defineModel<string>({ default: '' })\n\ndefineSlots<{\n  /** The label. It is clickable, the whole component being wrapped in a `<label>`. */\n  default?(): unknown\n}>()\n</script>\n\n<template>\n  <label class=\"v-radio\" :data-label-position=\"labelPosition\" :data-spread=\"spread || undefined\">\n    <input\n      v-model=\"model\"\n      type=\"radio\"\n      class=\"v-radio-input\"\n      v-bind=\"$attrs\"\n      :value=\"value\"\n      :disabled=\"disabled\"\n      :aria-invalid=\"invalid || undefined\"\n    />\n    <span class=\"v-radio-dot\" aria-hidden=\"true\" />\n    <span v-if=\"$slots.default\" class=\"v-radio-label\"><slot /></span>\n  </label>\n</template>\n\n<style>\n@layer vectis.components {\n  .v-radio {\n    display: inline-flex;\n    align-items: center;\n    gap: var(--vectis-space-2);\n    font-family: var(--vectis-text-family);\n    font-size: var(--vectis-text-label-size);\n    color: var(--vectis-color-text);\n    cursor: pointer;\n  }\n\n  /* The input is taken out of the flow by its absolute position, so reversing the\n     row only ever swaps the dot and the label. */\n  .v-radio[data-label-position='start'] {\n    flex-direction: row-reverse;\n  }\n\n  .v-radio[data-spread] {\n    display: flex;\n    justify-content: space-between;\n  }\n\n  /* Hidden with `opacity` and never with `display: none`, which would take the input\n     out of the tab order, out of the form and out of its own group. */\n  .v-radio-input {\n    position: absolute;\n    opacity: 0;\n    width: 1px;\n    height: 1px;\n    margin: 0;\n    pointer-events: none;\n  }\n\n  /* The dot works exactly like VCheckbox's box — the accent colour fills it once the\n     input is checked — with the small inner disc drawn as a pseudo-element in\n     currentcolor, so it follows whatever colour the ring takes. */\n  .v-radio-dot {\n    display: inline-grid;\n    place-items: center;\n    width: var(--vectis-control-size-check);\n    height: var(--vectis-control-size-check);\n    flex: none;\n    background: var(--vectis-color-surface);\n    border: var(--vectis-control-border-width) solid var(--vectis-color-border-strong);\n    border-radius: var(--vectis-radius-full);\n    color: var(--vectis-color-text-on-accent);\n    transition:\n      background-color var(--vectis-duration-fast) var(--vectis-ease-default),\n      border-color var(--vectis-duration-fast) var(--vectis-ease-default);\n  }\n\n  .v-radio-dot::before {\n    content: '';\n    width: var(--vectis-control-size-check-dot);\n    height: var(--vectis-control-size-check-dot);\n    border-radius: var(--vectis-radius-full);\n    background: currentcolor;\n    opacity: 0;\n    transition: opacity var(--vectis-duration-fast) var(--vectis-ease-default);\n  }\n\n  .v-radio:hover .v-radio-input:not(:disabled, :checked) + .v-radio-dot {\n    border-color: color-mix(\n      in oklab,\n      var(--vectis-color-border-strong),\n      var(--vectis-color-text) 15%\n    );\n  }\n\n  .v-radio-input:checked + .v-radio-dot {\n    background: var(--vectis-color-accent);\n    border-color: var(--vectis-color-accent);\n  }\n\n  .v-radio-input:checked + .v-radio-dot::before {\n    opacity: 1;\n  }\n\n  .v-radio:hover .v-radio-input:not(:disabled):checked + .v-radio-dot {\n    background: var(--vectis-color-accent-hover);\n    border-color: var(--vectis-color-accent-hover);\n  }\n\n  .v-radio-input:focus-visible + .v-radio-dot {\n    outline: var(--vectis-focus-ring-width) solid var(--vectis-focus-ring-color);\n    outline-offset: var(--vectis-focus-ring-offset);\n  }\n\n  .v-radio-input:user-invalid + .v-radio-dot,\n  .v-radio-input[aria-invalid='true'] + .v-radio-dot {\n    border-color: var(--vectis-color-danger);\n  }\n\n  /* A disabled radio greys out through the colour tokens, the same ones VButton\n     uses, and never through opacity. */\n  .v-radio:has(.v-radio-input:disabled) {\n    color: var(--vectis-color-text-subtle);\n    cursor: not-allowed;\n  }\n\n  .v-radio-input:disabled + .v-radio-dot {\n    background: var(--vectis-color-surface-muted);\n    border-color: var(--vectis-color-border);\n    color: var(--vectis-color-text-subtle);\n  }\n\n  @media (prefers-reduced-motion: reduce) {\n    .v-radio-dot,\n    .v-radio-dot::before {\n      transition: none;\n    }\n  }\n}\n</style>\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA+CA,IAAM,IAAQ,EAAmB,GAAA,YAAgB;yBAS/C,EAYQ,SAAA;GAZD,OAAM;GAAW,uBAAqB,EAAA;GAAgB,eAAa,EAAA,UAAU,KAAA;;KAClF,EAQE,SARF,EAQE;6CAPc,QAAA;IACd,MAAK;IACL,OAAM;MACEA,EAAAA,QAAM;IACb,OAAO,EAAA;IACP,UAAU,EAAA;IACV,gBAAc,EAAA,WAAW,KAAA;0BANjB,EAAA,KAAK,CAAA,CAAA;YAQhB,EAA+C,QAAA;IAAzC,OAAM;IAAc,eAAY;;GAC1BC,EAAAA,OAAO,WAAA,EAAA,GAAnB,EAAiE,QAAjE,GAAiE,CAAf,EAAQ,EAAA,QAAA,SAAA,CAAA,CAAA,KAAA,EAAA,IAAA,EAAA"}
+{"version":3,"file":"VRadio.vue_vue_type_script_setup_true_lang.js","names":["$slots"],"sources":["../../../src/components/VRadio/VRadio.vue"],"sourcesContent":["<script setup lang=\"ts\">\n/**\n * A radio button whose dot is drawn by the design system, on the same principle as\n * VCheckbox: the real `<input type=\"radio\">` stays in place and only its own drawing\n * is hidden.\n *\n * The group is native as well. Several VRadio sharing the same `name` and the same\n * v-model form one choice, and it is the browser that then makes the arrow keys move\n * between them, that lets only one be selected, and that gives the group a single\n * stop in the tab order. There is no JavaScript here for any of it; the only piece this\n * component writes is the refusal `readonly` asks for, which a radio has no native form of.\n */\n\nimport { ref } from 'vue'\n\nimport { useFieldIds } from '../../composables/useFieldIds'\nimport { useRootAttrs } from '../../composables/useRootAttrs'\nimport type { ItemValue } from '../../types'\n\n/** Which side of the dot the label sits on. */\nexport type RadioLabelPosition = 'start' | 'end'\n\ninterface RadioProps {\n  /**\n   * What choosing this button means. The group's v-model holds the value of the\n   * selected button, so this is what it becomes when this one is picked.\n   */\n  value: ItemValue\n  /** The text beside the dot, which names it. The default slot replaces it. */\n  label?: string\n  /**\n   * A line of help under the label. It is tied to the radio button for assistive\n   * technology, so it is read out after the label rather than as part of it.\n   */\n  hint?: string\n  /** Which side of the dot the label sits on. */\n  labelPosition?: RadioLabelPosition\n  /**\n   * Pushes the label and the dot to opposite ends of the line, the row taking the\n   * full width available.\n   */\n  spread?: boolean\n  /**\n   * Marks the field as invalid, which colours the dot and tells assistive technology\n   * so. It is for a rule the browser cannot check by itself.\n   */\n  invalid?: boolean\n  /** Makes this choice unusable, greyed out through the colour tokens. */\n  disabled?: boolean\n  /**\n   * Shows the selection without allowing it to be changed. The button can still be\n   * focused and is still submitted with its form; a click or an arrow key simply selects\n   * nothing. Set it on every button of the group.\n   */\n  readonly?: boolean\n}\n\nconst props = withDefaults(defineProps<RadioProps>(), {\n  label: undefined,\n  hint: undefined,\n  labelPosition: 'end',\n  spread: false,\n  invalid: false,\n  disabled: false,\n  readonly: false,\n})\n\n// @a11y — the redirection buys the whole keyboard. Moving between the buttons of a group is\n// the browser's job, but it only groups inputs that share a `name` — so redirecting the\n// attributes is what makes the arrow keys work at all. The root being a layout box, `name`\n// left on it would reach nothing.\ndefineOptions({ inheritAttrs: false })\nconst { attrs, rootClass, rootStyle, forwardedAttrs } = useRootAttrs()\nconst { hintId, describedBy } = useFieldIds(attrs, () => !!props.hint)\n\n/**\n * The value selected in the group, shared by every radio carrying the same `name`. It is\n * empty until one is chosen, and a radio is selected when it matches its own `value`.\n */\nconst model = defineModel<ItemValue>({ default: '' })\n\ndefineSlots<{\n  /** The label, when it needs more than the `label` prop's text. It is clickable. */\n  default?(): unknown\n}>()\n\nconst inputEl = ref<HTMLInputElement | null>(null)\n\n// @core\n// The native `readonly` attribute does nothing on a radio button. Cancelling the click is\n// what refuses the selection: the browser puts the group's previous selection back and fires\n// no `change`. It covers the arrow keys too, which select the next button of the group\n// through a click the browser dispatches on it — so the focus still moves, the selection\n// does not.\n//\n// No `aria-readonly` goes with it, unlike VCheckbox and VSwitch: ARIA allows it on a\n// `radiogroup` and not on a `radio`, and axe fails the page for it.\nfunction refuseWhenReadonly(event: MouseEvent) {\n  if (props.readonly) event.preventDefault()\n}\n\n// The root is a wrapper, so a template ref on the component reaches the layout box and not\n// the control: these two are the way to the real radio button.\ndefineExpose({\n  /** Moves the focus to the real radio button. */\n  focus: (options?: FocusOptions) => inputEl.value?.focus(options),\n  /** The real `<input type=\"radio\">`, for what `focus` does not cover. */\n  el: inputEl,\n})\n</script>\n\n<template>\n  <span\n    class=\"v-radio v-choice\"\n    :class=\"rootClass\"\n    :style=\"rootStyle\"\n    :data-label-position=\"labelPosition\"\n    :data-spread=\"spread ? '' : undefined\"\n    :data-readonly=\"readonly ? '' : undefined\"\n  >\n    <label class=\"v-choice-row\">\n      <input\n        ref=\"inputEl\"\n        v-model=\"model\"\n        type=\"radio\"\n        class=\"v-radio-input v-hidden-input\"\n        v-bind=\"forwardedAttrs\"\n        :value=\"value\"\n        :disabled=\"disabled\"\n        :aria-invalid=\"invalid || undefined\"\n        :aria-describedby=\"describedBy\"\n        @click=\"refuseWhenReadonly\"\n      />\n      <span class=\"v-radio-dot\" aria-hidden=\"true\" />\n      <span v-if=\"$slots.default || label\" class=\"v-radio-label v-choice-label\">\n        <slot>{{ label }}</slot>\n      </span>\n    </label>\n    <span v-if=\"hint\" :id=\"hintId\" class=\"v-radio-hint v-choice-hint\">{{ hint }}</span>\n  </span>\n</template>\n\n<style>\n@layer vectis.components {\n  /* The dot works exactly like VCheckbox's box, the accent filling it once the input is\n     checked, with the small inner disc drawn as a pseudo-element in currentcolor so it\n     follows whatever colour the state gives the ring's content. */\n  .v-radio-dot {\n    display: inline-grid;\n    place-items: center;\n    width: var(--vectis-control-size-check);\n    height: var(--vectis-control-size-check);\n    background: transparent;\n    border: var(--vectis-control-border-width) solid var(--vectis-color-border-strong);\n    border-radius: var(--vectis-radius-pill);\n    color: var(--vectis-color-text-on-accent);\n    transition:\n      background-color var(--vectis-duration-fast) var(--vectis-ease-default),\n      border-color var(--vectis-duration-fast) var(--vectis-ease-default);\n  }\n\n  .v-radio-dot::before {\n    content: '';\n    width: var(--vectis-control-size-check-dot);\n    height: var(--vectis-control-size-check-dot);\n    border-radius: var(--vectis-radius-pill);\n    background: currentcolor;\n    opacity: 0;\n    transition: opacity var(--vectis-duration-fast) var(--vectis-ease-default);\n  }\n\n  .v-radio-input:checked + .v-radio-dot::before {\n    opacity: 1;\n  }\n\n  /* The state painting, rule for rule the same as VCheckbox's with its own classes: keep the\n     two ALIGNED. Every state below but the hovers weighs (0,3,0), so their ORDER arbitrates\n     them: checked, read-only, invalid, then disabled last. The two hovers exclude every state\n     they must not repaint, so no order argument reaches them. */\n  .v-radio:not([data-readonly])\n    .v-choice-row:hover\n    .v-radio-input:not(:disabled, :checked)\n    + .v-radio-dot {\n    border-color: color-mix(\n      in oklab,\n      var(--vectis-color-border-strong),\n      var(--vectis-color-text) 15%\n    );\n  }\n\n  .v-radio-input:checked + .v-radio-dot {\n    background: var(--vectis-color-accent);\n    border-color: var(--vectis-color-accent);\n  }\n\n  .v-radio:not([data-readonly])\n    .v-choice-row:hover\n    .v-radio-input:not(:disabled):is(:checked)\n    + .v-radio-dot {\n    background: var(--vectis-color-accent-hover);\n    border-color: var(--vectis-color-accent-hover);\n  }\n\n  /* Read-only sinks like a read-only field, and a selected control trades the accent for the\n     muted text colour: still plainly on, no longer inviting a click. The mark takes the\n     surface colour, which contrasts with that fill in both themes, where white would vanish\n     against the light grey of the dark theme. `:where()` keeps both rules at the weight of\n     the states they sit between. */\n  :where(.v-radio[data-readonly]) .v-radio-input + .v-radio-dot {\n    background: var(--vectis-color-surface-sunken);\n    border-color: var(--vectis-color-border);\n  }\n\n  :where(.v-radio[data-readonly]) .v-radio-input:checked + .v-radio-dot {\n    background: var(--vectis-color-text-muted);\n    border-color: var(--vectis-color-text-muted);\n    color: var(--vectis-color-surface);\n  }\n\n  .v-radio-input:user-invalid + .v-radio-dot,\n  .v-radio-input[aria-invalid='true'] + .v-radio-dot {\n    border-color: var(--vectis-color-danger);\n  }\n\n  .v-radio-input:disabled + .v-radio-dot {\n    background: var(--vectis-color-surface-muted);\n    border-color: var(--vectis-color-border);\n    color: var(--vectis-color-text-subtle);\n  }\n\n  @media (prefers-reduced-motion: reduce) {\n    .v-radio-dot,\n    .v-radio-dot::before {\n      transition: none;\n    }\n  }\n}\n</style>\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAyDA,IAAM,IAAQ,GAeR,EAAE,UAAO,cAAW,cAAW,sBAAmB,EAAa,GAC/D,EAAE,WAAQ,mBAAgB,EAAY,SAAa,CAAC,CAAC,EAAM,IAAI,GAM/D,IAAQ,EAAsB,GAAA,YAAgB,GAO9C,IAAU,EAA6B,IAAI;EAWjD,SAAS,EAAmB,GAAmB;GAC7C,AAAI,EAAM,YAAU,EAAM,eAAe;EAC3C;SAIA,EAAa;GAEX,QAAQ,MAA2B,EAAQ,OAAO,MAAM,CAAO;GAE/D,IAAI;EACN,CAAC,mBAIC,EA2BO,QAAA;GA1BL,OAAK,EAAA,CAAC,oBACE,EAAA,CAAA,CAAS,CAAA;GAChB,OAAK,EAAE,EAAA,CAAA,CAAS;GAChB,uBAAqB,EAAA;GACrB,eAAa,EAAA,SAAM,KAAQ,KAAA;GAC3B,iBAAe,EAAA,WAAQ,KAAQ,KAAA;MAEhC,EAiBQ,SAjBR,GAiBQ;KAhBN,EAWE,SAXF,EAWE;aAVI;IAAJ,KAAI;6CACU,QAAA;IACd,MAAK;IACL,OAAM;MACE,EAAA,CAAA,GAAc;IACrB,OAAO,EAAA;IACP,UAAU,EAAA;IACV,gBAAc,EAAA,WAAW,KAAA;IACzB,oBAAkB,EAAA,CAAA;IAClB,SAAO;0BARC,EAAA,KAAK,CAAA,CAAA;YAUhB,EAA+C,QAAA;IAAzC,OAAM;IAAc,eAAY;;GAC1BA,EAAAA,OAAO,WAAW,EAAA,SAAA,EAAA,GAA9B,EAEO,QAFP,GAEO,CADL,EAAwB,EAAA,QAAA,WAAA,CAAA,SAAA,CAAA,EAAA,EAAf,EAAA,KAAK,GAAA,CAAA,CAAA,CAAA,CAAA,CAAA,KAAA,EAAA,IAAA,EAAA;MAGN,EAAA,QAAA,EAAA,GAAZ,EAAmF,QAAA;;GAAhE,IAAI,EAAA,CAAA;GAAQ,OAAM;OAAgC,EAAA,IAAI,GAAA,GAAA,CAAA,KAAA,EAAA,IAAA,EAAA,CAAA,GAAA,IAAA,CAAA"}