@repobit/dex-system-design 0.25.11 → 0.26.0

package/src/components/shared/form-field.css.js

@@ -0,0 +1,206 @@
+import { css } from "lit";
+
+/**
+ * The shared chrome for a form field: its label, the control itself, its three
+ * sizes, its states and its help text.
+ *
+ * bd-custom-input, bd-custom-dropdown and bd-custom-input-clipboard are one
+ * field with three kinds of control in the middle. They used to be three
+ * stylesheets of about 160 lines each, roughly 130 of them identical, and they
+ * had drifted: the select set its labels and help text at line-height normal
+ * where the other two used tight, and its `md` size declared 8px of vertical
+ * padding while the height formula on the line below assumed 12. Every fix had
+ * to be applied three times and demonstrably had not been.
+ *
+ * This is the same arrangement radio.css.js already uses across bd-radio and
+ * bd-toggle-radio. A component imports this first and then its own sheet:
+ *
+ *   static styles = [formFieldCSS, dropdownCSS];
+ *
+ * Values come from the --form-input-* and --form-label-* component tokens
+ * rather than from the palette, which is what bd-textarea was already doing
+ * and what lets a single token change reach all four controls.
+ */
+export const formFieldCSS = css`
+  /* No width. This used to be 90%, an arbitrary fraction that made every field
+     narrower than whatever contained it and left the last tenth unexplained.
+     A field is display:block and fills its container; deciding how wide that
+     container is belongs to the page. */
+  :host {
+    display: block;
+  }
+
+  .input-container {
+    display: flex;
+    flex-direction: column;
+  }
+
+  /* ---- label ------------------------------------------------------------
+     Driven by --form-label-*, the same tokens bd-label reads, so the field's
+     built-in label and the standalone atom render identically. They did not
+     before: these rules hardcoded bold where the token says medium, which is
+     200 units apart on the same line of the same form. */
+  .form-label {
+    display: block;
+    font-family: var(--form-label-default-fontFamily);
+    color: var(--form-label-default-color);
+    letter-spacing: var(--form-label-default-letterSpacing);
+  }
+
+  .label-sm {
+    font-size: var(--form-label-small-fontSize);
+    font-weight: var(--form-label-small-fontWeight);
+    line-height: var(--form-label-small-lineHeight);
+    letter-spacing: var(--form-label-small-letterSpacing);
+    margin-bottom: var(--form-label-small-marginBottom);
+  }
+
+  .label-md {
+    font-size: var(--form-label-default-fontSize);
+    font-weight: var(--form-label-default-fontWeight);
+    line-height: var(--form-label-default-lineHeight);
+    margin-bottom: var(--form-label-default-marginBottom);
+  }
+
+  .label-lg {
+    font-size: var(--form-label-large-fontSize);
+    font-weight: var(--form-label-large-fontWeight);
+    line-height: var(--form-label-large-lineHeight);
+    margin-bottom: var(--form-label-large-marginBottom);
+  }
+
+  .form-label__required {
+    color: var(--form-label-required-color);
+    margin-left: var(--form-label-required-marginLeft);
+  }
+
+  /* ---- the control ------------------------------------------------------
+     line-height is tight here and only here. The height below is derived from
+     padding, type step and line-height, and bd-button derives its own from the
+     same three, which is what keeps a field and a button of the same size the
+     same height. At normal (1.5) the line box also stood taller than the
+     content box the fixed height leaves, and the select clipped the descenders
+     of its own option text. */
+  .form-input-bd {
+    width: 100%;
+    box-sizing: border-box;
+    font-family: var(--form-input-default-fontFamily);
+    /* no role: tight is load-bearing here rather than chosen -- the comment
+       above this rule has the argument. The height is DERIVED from padding,
+       type step and this leading, so a role's leading would change the
+       control's height; and an <input> renders one line, so CLAUDE.md's
+       "anything that can wrap needs at least tight" floor is met and its
+       concern does not arise. Overridden for the textarea, which does wrap:
+       see textarea.css.js. */
+    line-height: var(--typography-lineHeight-tight);
+    border: var(--form-input-default-borderWidth) solid var(--form-input-default-borderColor);
+    background-color: var(--form-input-default-backgroundColor);
+    color: var(--form-input-default-color);
+    outline: none;
+    transition: border-color var(--transition-duration-slow) var(--transition-easing-smooth),
+      background-color var(--transition-duration-slow) var(--transition-easing-smooth),
+      box-shadow var(--transition-duration-slow) var(--transition-easing-smooth);
+  }
+
+  /* :focus-visible, not :focus. On a text field the two agree — a browser
+     shows the indicator for a pointer click there too, because typing is
+     expected — but the select is a control you click and walk away from, and
+     it was drawing the full ring on every mouse press where bd-button drew
+     nothing. .focused is the component's own prop, not a user interaction, so
+     it stays unconditional. */
+  .form-input-bd:focus-visible,
+  .form-input-bd.focused {
+    border-color: var(--form-input-focus-borderColor);
+    box-shadow: var(--focus-outline-primary);
+  }
+
+  /* ---- sizes ------------------------------------------------------------
+     Four reads of the size's own token, no arithmetic. The height calc used to
+     live here in triplicate; it lives in --form-input-*-height now, where the
+     value it produces is also the value the package publishes. */
+  .input-sm {
+    padding: var(--form-input-small-padding);
+    font-size: var(--form-input-small-fontSize);
+    height: var(--form-input-small-height);
+    border-radius: var(--form-input-small-borderRadius);
+  }
+
+  .input-md {
+    padding: var(--form-input-medium-padding);
+    font-size: var(--form-input-medium-fontSize);
+    height: var(--form-input-medium-height);
+    border-radius: var(--form-input-medium-borderRadius);
+  }
+
+  .input-lg {
+    padding: var(--form-input-large-padding);
+    font-size: var(--form-input-large-fontSize);
+    height: var(--form-input-large-height);
+    border-radius: var(--form-input-large-borderRadius);
+  }
+
+  ::placeholder {
+    color: var(--color-text-subtle);
+    opacity: 1;
+  }
+
+  /* On a tinted field the placeholder takes the next step up. text-subtle on
+     the error tint measured 4.22:1 and on the success tint 4.43 -- under 4.5,
+     and an empty required field in error is exactly when the placeholder is
+     showing. text-muted gives 5.95 and 6.25. The plain field keeps
+     text-subtle (4.81). */
+  .form-input--error::placeholder,
+  .form-input--success::placeholder {
+    color: var(--color-text-muted);
+  }
+
+  /* ---- states ----------------------------------------------------------- */
+  .form-input--error {
+    background-color: var(--form-input-error-backgroundColor);
+    border-color: var(--form-input-error-borderColor);
+  }
+
+  .form-input--success {
+    background-color: var(--form-input-success-backgroundColor);
+    border-color: var(--form-input-success-borderColor);
+  }
+
+  .form-input--disabled {
+    background-color: var(--form-input-disabled-backgroundColor);
+    border-color: var(--form-input-disabled-borderColor);
+    color: var(--form-input-disabled-color);
+    cursor: not-allowed;
+  }
+
+  /* ---- help text --------------------------------------------------------
+     The same roles bd-help-text renders, so a field's built-in message and the
+     standalone atom agree on colour and measure. */
+  .form-help-text {
+    font-family: var(--form-help-text-default-fontFamily);
+    font-size: var(--form-help-text-default-fontSize);
+    font-weight: var(--form-help-text-default-fontWeight);
+    line-height: var(--form-help-text-default-lineHeight);
+    letter-spacing: var(--form-help-text-default-letterSpacing);
+    margin-top: var(--form-help-text-default-marginTop);
+  }
+
+  .form-help-text--default {
+    color: var(--form-help-text-default-color);
+  }
+
+  .form-help-text--error {
+    color: var(--form-help-text-error-color);
+  }
+
+  .form-help-text--success {
+    color: var(--form-help-text-success-color);
+  }
+
+  @media (prefers-reduced-motion: reduce) {
+    .form-input-bd {
+      transition: none;
+    }
+  }
+`;
+
+export default formFieldCSS;

package/src/components/shared/prop-vocabulary.js

@@ -0,0 +1,48 @@
+/**
+ * The words a component prop is allowed to use, and the ones it used to.
+ *
+ * Three axes, three names, and each name means one thing everywhere:
+ *
+ *   size     how big            sm · md · lg
+ *   variant  how it looks       primary, bullet, shade — per component
+ *   tone     what it means      neutral · brand · success · warning · error · info
+ *
+ * Before this there were three size vocabularies and `kind` meant four
+ * unrelated things: the visual variant on bd-button and bd-link, the size on
+ * the three form fields, the type step on bd-p and the marker on bd-li. An
+ * author could not carry anything learned on one atom to the next.
+ *
+ * Every old name still resolves. bd-button already did this for the kind
+ * values it retired, and that is the pattern the rest now follow — renaming a
+ * prop is not worth breaking a consumer's markup over.
+ */
+
+/** The one size scale. */
+export const SIZES = ['sm', 'md', 'lg'];
+
+/**
+ * Size names from before there was one vocabulary. `default` is the
+ * interesting one: it named a position rather than a size, so a reader had to
+ * know the set to know whether it was smaller or larger than the alternative.
+ */
+export const LEGACY_SIZES = {
+  small  : 'sm',
+  medium : 'md',
+  default: 'md',
+  large  : 'lg'
+};
+
+/**
+ * Resolves a prop value against its closed set, mapping any legacy spelling
+ * first and falling back when the value is not in the set at all. Returning
+ * the fallback rather than the raw value is what stops a typo rendering an
+ * unstyled component.
+ */
+export function resolveEnum(value, { allowed, legacy = {}, fallback }) {
+  const mapped = Object.hasOwn(legacy, value) ? legacy[value] : value;
+  return allowed.includes(mapped) ? mapped : fallback;
+}
+
+/** The common case: a size prop, with the old spellings still accepted. */
+export const resolveSize = (value, fallback = 'md') =>
+  resolveEnum(value, { allowed: SIZES, legacy: LEGACY_SIZES, fallback });

package/src/components/shared/token-scales.js

@@ -0,0 +1,306 @@
+/**
+ * The closed sets a component prop may draw from, and the only place that
+ * turns a prop value into CSS.
+ *
+ * See CLAUDE.md, "The foundation rule". Every prop-facing function here
+ * returns either a token reference or the empty string, so a literal cannot
+ * come out of a component prop no matter what a caller passes. An
+ * unrecognised value is dropped and the component keeps its own styling.
+ *
+ * The breakpoint helpers at the foot of this file are the one exception, and
+ * they throw rather than returning empty. The reason is who calls them: every
+ * scale above is fed a value a *consumer* passed as an attribute, where
+ * dropping a bad value degrades gracefully. A breakpoint name is written by
+ * the component author inside a stylesheet, and an empty string there yields
+ * `@media  { ... }` — a malformed query the browser discards silently, taking
+ * the whole block with it. A typo has to fail loudly at the point it is made.
+ */
+
+export const SPACING_STEPS = [
+  '0', '1', '2', '4', '6', '8', '10', '12', '14', '16', '18', '20', '22', '24',
+  '28', '32', '36', '40', '44', '48', '52', '56', '64', '80', '96', '112', '128'
+];
+
+export const FONT_SIZE_STEPS = [
+  'xxs', 'xs', 'sm', 'base', 'lg', 'xl',
+  '2xl', '3xl', '4xl', '5xl', '6xl', '7xl', '8xl', '9xl'
+];
+
+export const FONT_WEIGHT_STEPS = ['light', 'normal', 'medium', 'semibold', 'bold'];
+
+/** The two faces the system ships. There is no third, and no escape hatch. */
+export const FONT_FAMILY_STEPS = ['sans', 'mono'];
+
+export const LETTER_SPACING_STEPS = ['tighter', 'tight', 'normal', 'wide', 'wider', 'widest'];
+
+/**
+ * The t-shirt vocabulary bd-grid's gap and padding props take, mapped onto the
+ * live pixel scale. It used to be a second CSS scale, --space-*, which existed
+ * mainly so the component could build a token name from a prop — thirteen
+ * tokens duplicating --spacing-* under other names. A prop vocabulary belongs
+ * here, with the other closed sets, rather than in the token file.
+ */
+export const SPACE_STEPS = {
+  none : '0', '4xs': '2', '3xs': '4', '2xs': '8', xs   : '12', sm   : '16',
+  md   : '24', lg   : '32', xl   : '40', '2xl': '48', '3xl': '64', '4xl': '96', '5xl': '128'
+};
+
+/** Icon sizes. The scale stops at 3xl (64px); there is no step above it. */
+export const ICON_SIZE_STEPS = ['xs', 'sm', 'md', 'lg', 'xl', '2xl', '3xl'];
+
+export const RADIUS_STEPS = ['none', 'sm', 'md', 'lg', 'xl', '2xl', '3xl', 'full'];
+
+/**
+ * Semantic colour roles a component's `color` prop may name.
+ *
+ * These resolve through the --color-text-* roles rather than reaching past
+ * them into the palette, which is what the semantic colour block in
+ * src/tokens/tokens.js says they should do. Spelled as palette steps, this
+ * map was the reason a page could retint --color-text-muted and watch every
+ * bd-h with color="muted" ignore it: the values matched, so nothing looked
+ * wrong until someone tried to change one.
+ *
+ * The prop vocabulary and the token vocabulary are deliberately not the same
+ * words. `strong` and `primary` read better on a component than
+ * `text-primary` and `text-brand` do, and renaming the prop would break
+ * consumers' markup for no gain. The mapping is the seam, and it lives here.
+ *
+ * Every role clears 4.5:1 on white, which is what the docstring here always
+ * claimed and what `subtle` did not do: it named neutral-400, which measures
+ * 3.23:1 and fails 1.4.3 for text. It now resolves to --color-text-subtle
+ * (neutral-500, 4.67:1). Nothing in this repository passed color="subtle",
+ * so the fix costs nothing today — note that neutral-400 is the step the
+ * token layer calls `disabled`, and disabled text is exempt under 1.4.3,
+ * which is presumably how the two got crossed.
+ */
+export const COLOR_ROLES = {
+  primary: '--color-text-brand',
+  strong : '--color-text-primary',
+  muted  : '--color-text-muted',
+  subtle : '--color-text-subtle',
+  inverse: '--color-text-inverse',
+  success: '--color-text-success',
+  warning: '--color-text-warning',
+  error  : '--color-text-error'
+};
+
+export const COLOR_ROLE_NAMES = Object.keys(COLOR_ROLES);
+
+/**
+ * The hairline vocabulary.
+ *
+ * A divider is a border, and until now the only colour prop it had resolved
+ * through COLOR_ROLES above -- the *ink* vocabulary. That is the category
+ * error CLAUDE.md names ("Never use a token from the wrong category"), and
+ * this file already carried a milder version of it: bd-divider-horizontal's
+ * constructor records that its default used to say `subtle`, a text role that
+ * matched the right value by coincidence.
+ *
+ * The cost was not theoretical. bd-quick-answer needs a hairline in
+ * --status-brand-border, because its rule sits on a brand tint and a neutral
+ * line reads as dirt there. No text role expresses that, so the component drew
+ * its own `border-top` instead of composing the atom -- which is exactly the
+ * "dividers are not borders" confusion the same document warns about, arrived
+ * at from the other direction: the divider could not say what the component
+ * meant, so the component stopped using the divider.
+ *
+ * `brand-subtle` is the one entry that reaches outside the --color-border-*
+ * family, and it is here because it has a consumer today. The rest of the
+ * status hairlines are deliberately absent until one does.
+ *
+ * `inverse` is deliberately NOT here. It would resolve to
+ * --color-border-container-inverse, which is white at 12%, where the text
+ * role it resolves to today is solid white -- and each divider then multiplies
+ * that by its own `opacity` prop (0.25 by default on the horizontal, 1.00 on
+ * the vertical). The dividers that pass color="inverse" would drop from solid
+ * white to 12%, or from 25% to 3%, and effectively vanish. It keeps falling
+ * through to the legacy text role below, and that is recorded rather than
+ * fixed: whether a hairline on a dark surface should be a 12% border role at
+ * full opacity, or a solid one dimmed by the prop, is a real design question
+ * and not this change's to answer.
+ */
+export const BORDER_ROLES = {
+  default       : '--color-border-default',
+  subtle        : '--color-border-subtle',
+  strong        : '--color-border-strong',
+  container     : '--color-border-container',
+  brand         : '--color-border-brand',
+  disabled      : '--color-border-disabled',
+  'brand-subtle': '--status-brand-border'
+};
+
+export const BORDER_ROLE_NAMES = Object.keys(BORDER_ROLES);
+
+const onScale = (steps, prefix) => value =>
+  steps.includes(String(value)) ? `var(${prefix}${value})` : '';
+
+export const spacing    = onScale(SPACING_STEPS, '--spacing-');
+export const fontSize   = onScale(FONT_SIZE_STEPS, '--typography-fontSize-');
+export const fontWeight = onScale(FONT_WEIGHT_STEPS, '--typography-fontWeight-');
+export const fontFamily = onScale(FONT_FAMILY_STEPS, '--typography-fontFamily-');
+export const letterSpacing = onScale(LETTER_SPACING_STEPS, '--typography-letterSpacing-');
+export const radius     = onScale(RADIUS_STEPS, '--radius-');
+
+export const space = name =>
+  (Object.hasOwn(SPACE_STEPS, name) ? `var(--spacing-${SPACE_STEPS[name]})` : '');
+
+/** --icon-*-size wraps its step, so it needs a suffix onScale cannot express. */
+export const iconSize = value =>
+  (ICON_SIZE_STEPS.includes(String(value)) ? `var(--icon-${value}-size)` : '');
+
+export const color = role =>
+  Object.hasOwn(COLOR_ROLES, role) ? `var(${COLOR_ROLES[role]})` : '';
+
+/**
+ * A hairline's colour: border roles first, then the ink vocabulary as legacy.
+ *
+ * Border-first is the point -- `subtle` on a divider means
+ * --color-border-subtle, not --color-text-subtle. The fallback exists so the
+ * names already in use keep working (`inverse`, and `strong`, which resolves
+ * to neutral-900 either way), and it is a migration path, not a second
+ * vocabulary: a new divider should be spelled with a border role.
+ */
+export const borderColor = role =>
+  (Object.hasOwn(BORDER_ROLES, role)
+    ? `var(${BORDER_ROLES[role]})`
+    : color(role));
+
+/**
+ * A one-to-four-value spacing shorthand written as steps, e.g. "10 0" gives
+ * `var(--spacing-10) var(--spacing-0)`. All parts must be on the scale, or
+ * the whole value is dropped — a half-valid shorthand is worse than none.
+ */
+export const spacingShorthand = value => {
+  const parts = String(value ?? '').trim()
+    .split(/\s+/)
+    .filter(Boolean);
+  if (parts.length < 1 || parts.length > 4) return '';
+  const refs = parts.map(spacing);
+  return refs.every(Boolean) ? refs.join(' ') : '';
+};
+
+/* ================================================================
+     BREAKPOINTS
+   ================================================================
+   The six viewport widths, and the only place a media condition is built
+   from them.
+
+   This lives in JS rather than in the token file because a media condition
+   cannot read a custom property — `@media (max-width: var(--breakpoint-md))`
+   is not valid CSS — so the six values have to be interpolated into the
+   stylesheet at author time. `--breakpoint-*` in src/tokens/tokens.js stays
+   the published record of the scale; this is how a component consumes it.
+
+   `above` and `below` return a media *condition*, not a whole `@media` rule,
+   so they compose:
+
+       @media ${below('md')}                  { ... }
+       @media ${above('sm')} and ${below('lg')} { ... }
+
+   ---
+
+   WHY THE HELPER OWNS THE COMPLEMENT.
+
+   A breakpoint is one number, but it has two spellings, and writing the
+   second one by hand is how the boundary drifts. `min-width: 768px` and
+   `max-width: 768px` are both true at exactly 768px, so a component that
+   spells its mobile rule the obvious way applies both its mobile and its
+   desktop styling at that one width. pricing-card.css.js has the collision
+   today — `@media (max-width: 768px)` at one rule and
+   `@media (min-width: 768px) and (max-width: 1024px)` at another — and
+   thirteen more files use the same `max-width: 768px` form.
+
+   The complement is derived here so that number is never typed. Do not write
+   767px, 991px or 1199px anywhere; write `below('md')`, `below('lg')`,
+   `below('xl')`.
+
+   ---
+
+   WHY 0.02 AND NOT 1.
+
+   A viewport is not always a whole number of pixels: browser zoom, some
+   Android densities and fractional device-pixel-ratios all produce widths
+   like 767.5px. Measured in Chrome at that width, `min-width: 768px` is
+   false and `max-width: 767px` is *also* false — an element between the two
+   rules falls back to its unqueried state, briefly neither mobile nor
+   desktop. Subtracting 0.02 rather than 1 removes that band: across
+   575.98, 576, 767, 767.5, 767.98, 767.99, 768 and 768.5 every width matches
+   exactly one of `above('md')` and `below('md')`, and none matches both.
+
+   0.02 rather than 0.01 is the long-standing convention, from Safari having
+   rounded a hundredth away.
+
+   The five subtractions are exact in IEEE 754 — 575.98, 767.98, 991.98,
+   1199.98 and 1399.98 all round-trip — so no rounding is needed here. If a
+   value is ever added to the scale whose complement does not, this is where
+   the rounding belongs. */
+
+export const BREAKPOINTS = {
+  xs : 0,
+  sm : 576,
+  md : 768,
+  lg : 992,
+  xl : 1200,
+  xxl: 1400
+};
+
+export const BREAKPOINT_NAMES = Object.keys(BREAKPOINTS);
+
+/** Throws rather than returning empty — see the note in the file header. */
+const step = name => {
+  if (!Object.hasOwn(BREAKPOINTS, name)) {
+    throw new Error(`Unknown breakpoint: ${name}. Expected one of ${BREAKPOINT_NAMES.join(', ')}.`);
+  }
+  return BREAKPOINTS[name];
+};
+
+/**
+ * "This breakpoint and wider."
+ *
+ *   above('md')  →  (min-width: 768px)
+ *
+ * `above('xs')` is `(min-width: 0px)`, which is always true. That is a
+ * harmless no-op rather than an error, because it is the honest answer for
+ * the bottom of the scale — but a rule that needs no condition should have
+ * no media query.
+ */
+export const above = name => `(min-width: ${step(name)}px)`;
+
+/**
+ * "Narrower than this breakpoint" — the exact complement of `above`.
+ *
+ *   below('md')  →  (max-width: 767.98px)
+ *
+ * `below('xs')` throws: xs is 0, and no viewport is narrower than that, so
+ * the query could only ever be dead CSS.
+ */
+export const below = name => {
+  const value = step(name);
+  if (value === 0) {
+    throw new Error(`below('${name}') has no meaning: no viewport is narrower than ${value}px. Did you mean above('${name}')?`);
+  }
+  return `(max-width: ${value - 0.02}px)`;
+};
+
+/**
+ * The JS side of `below`, for the viewport logic CSS genuinely cannot express
+ * — choosing which markup to render rather than how to style it.
+ *
+ *   matchesBelow('md')  →  true when the viewport is narrower than md
+ *
+ * It reads the same scale as the stylesheet, so the two cannot disagree. That
+ * is the failure this replaces: bd-footer switched at 767 in CSS and at 767
+ * in JS while bd-footer-lp, sharing the same stylesheet, switched at 768.
+ *
+ * Prefer CSS. Reach for this only when the component's *behaviour* changes,
+ * and re-read it on `resize` — the value is a snapshot, not a subscription.
+ *
+ * Outside a browser (SSR, a bare Node import) there is no viewport to be
+ * narrower than, so this reports false. The name is still validated first, so
+ * a typo throws in every environment rather than only in the browser.
+ */
+export const matchesBelow = name => {
+  const condition = below(name);
+  if (typeof window === 'undefined' || typeof window.matchMedia !== 'function') return false;
+  return window.matchMedia(condition).matches;
+};

package/src/components/skeleton/skeleton.css.js

@@ -0,0 +1,34 @@
+import { css } from 'lit';
+
+/** Styled entirely from design tokens — see npm run lint:tokens. */
+export const skeletonCSS = css`
+  :host { display: block; }
+
+  .bone {
+    background: var(--color-surface-muted);
+    border-radius: var(--radius-sm);
+    height: var(--spacing-16);
+    animation: bd-shimmer var(--transition-duration-slower) var(--transition-easing-smooth) infinite alternate;
+  }
+
+  .bone + .bone { margin-top: var(--spacing-8); }
+
+  :host([shape='circle']) .bone {
+    width: var(--dimension-40);
+    height: var(--dimension-40);
+    border-radius: var(--radius-full);
+  }
+
+  :host([shape='title']) .bone { height: var(--spacing-24); }
+
+  /* --opacity-pulse, not 0.45. The dim end of a "this is busy" pulse is the
+     same intent here, in bd-button and in bd-spinner; it was spelled three
+     times and two of the three said 0.4. The role now says it once. */
+  @keyframes bd-shimmer { to { opacity: var(--opacity-pulse); } }
+
+  @media (prefers-reduced-motion: reduce) {
+    .bone { animation: none; }
+  }
+`;
+
+export default skeletonCSS;

package/src/components/skeleton/skeleton.js

@@ -0,0 +1,32 @@
+import { LitElement, html, nothing } from 'lit';
+// Installs the design tokens into document scope; see src/tokens/tokens.js
+import '../../tokens/tokens.js';
+import { skeletonCSS } from './skeleton.css.js';
+
+export class BdSkeleton extends LitElement {
+  static styles = [skeletonCSS];
+
+  static properties = {
+    lines: { type: Number },
+    shape: { type: String, reflect: true }
+  };
+
+  constructor() {
+    super();
+    this.lines = 1;
+    this.shape = 'line';
+  }
+
+  render() {
+    return html`
+      <span aria-hidden="true">
+        ${Array.from({ length: this.lines }, (_unused, i) => html`<div
+          class="bone"
+          style=${i === this.lines - 1 && this.lines > 1 ? 'width: 60%' : nothing}
+        ></div>`)}
+      </span>
+    `;
+  }
+}
+
+customElements.define('bd-skeleton', BdSkeleton);