@deriv-com/dds-marketing 0.1.0 → 1.0.0

package/dist/components/core/text-input/text-input-impl.css

@@ -0,0 +1,36 @@
+/*
+ * Scoped to this package, like the generated sheet beside it.
+ *
+ * `:where([data-dds-context="marketing"])` confines these rules without contributing
+ * specificity, so the one override below still ties or beats exactly what it did before.
+ */
+
+/*
+ * The status glyph's box is one line of the message tall.
+ *
+ * The contract binds the font size and the line height on this part, which is what makes it
+ * one line — but a line's height is those two multiplied, and a binding carries one token,
+ * not an expression over two. So the multiplication happens here, over the same variables the
+ * contract bound: no measure is declared, and retuning either token moves this with it.
+ *
+ * Why a height at all, when the part could simply hold the glyph: aligned to the start of the
+ * block axis, a glyph is as tall as itself — 16px against a 21px line — so its middle sits
+ * above the first line's and the words beside it read as pushed down. A box one line tall with
+ * the glyph centred in it puts the two middles on each other.
+ *
+ * Centred geometrically rather than on the inline baseline. `vertical-align: middle` is the
+ * usual recipe and it is not the same thing: it puts a glyph's middle on the baseline plus half
+ * an x-height, which lands a pixel or so below the middle of a line of capitals and leaves the
+ * glyph hanging under the baseline where the type has its descender.
+ *
+ * One rule rather than one per size, because the message is font.body.sm at every step — it is
+ * the small print under a field whatever size it is, and the field's own sizes do not reach it. The day
+ * that stops being true this needs a second rule, and naming the role rather than a measure is
+ * what will make that obvious.
+ *
+ * The same problem InlineAlert solved first, and the same answer; the argument in full is in
+ * inline-alert-impl.css.
+ */
+:where([data-dds-context="marketing"]) .dds-textinput__message-icon {
+  block-size: calc(var(--font-body-sm-size) * var(--font-body-sm-line-height));
+}

package/dist/components/core/tooltip/Tooltip.css

@@ -0,0 +1,101 @@
+/* GENERATED from tooltip.contract.json. Do not edit. */
+
+:where([data-dds-context="marketing"]) .dds-tooltip {
+  transition-property: opacity, scale;
+  align-items: center;
+  display: flex;
+  pointer-events: none;
+  width: max-content;
+  font-family: var(--font-body-sm-family);
+  font-size: var(--font-body-sm-size);
+  font-weight: var(--font-body-sm-weight);
+  line-height: var(--font-body-sm-line-height);
+  transition-duration: var(--motion-duration-fast);
+  transition-timing-function: var(--motion-easing-enter);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip .dds-tooltip__caret {
+  box-sizing: content-box;
+  color: var(--color-bg-strong);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip .dds-tooltip__body {
+  box-sizing: border-box;
+  overflow-wrap: break-word;
+  text-wrap: balance;
+  background-color: var(--color-bg-strong);
+  border-radius: var(--radius-subtle);
+  box-shadow: var(--elevation-surface-floating);
+  color: var(--color-fg-on-strong);
+  max-inline-size: var(--size-tooltip-max);
+  padding-block: var(--space-inset-sm);
+  padding-inline: var(--space-inset-md);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-placement="bottom"] {
+  flex-direction: column;
+  transform-origin: top;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-placement="left"] {
+  flex-direction: row-reverse;
+  transform-origin: right;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-placement="right"] {
+  flex-direction: row;
+  transform-origin: left;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-placement="top"] {
+  flex-direction: column-reverse;
+  transform-origin: bottom;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-alignment="center"] .dds-tooltip__caret {
+  align-self: center;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-alignment="end"] .dds-tooltip__caret {
+  align-self: flex-end;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-alignment="start"] .dds-tooltip__caret {
+  align-self: flex-start;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-hidden="true"] {
+  opacity: var(--opacity-hidden);
+  scale: var(--motion-scale-enter);
+  transition-duration: var(--motion-duration-instant);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-placement="bottom"] .dds-tooltip__caret {
+  height: var(--space-gap-xs);
+  padding-inline: var(--space-inset-sm);
+  width: var(--space-gap-sm);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-placement="left"] .dds-tooltip__caret {
+  height: var(--space-gap-sm);
+  padding-block: var(--space-inset-sm);
+  width: var(--space-gap-xs);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-placement="right"] .dds-tooltip__caret {
+  height: var(--space-gap-sm);
+  padding-block: var(--space-inset-sm);
+  width: var(--space-gap-xs);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip[data-placement="top"] .dds-tooltip__caret {
+  height: var(--space-gap-xs);
+  padding-inline: var(--space-inset-sm);
+  width: var(--space-gap-sm);
+}
+
+@media (prefers-reduced-motion: reduce) {
+  :where([data-dds-context="marketing"]) .dds-tooltip,
+  :where([data-dds-context="marketing"]) .dds-tooltip * { transition: none !important; }
+}
+

package/dist/components/core/tooltip/Tooltip.d.ts

@@ -0,0 +1,51 @@
+import './Tooltip.css';
+import './tooltip-impl.css';
+import { type TooltipProps } from './Tooltip.types.js';
+export type { TooltipProps };
+/**
+ * The chip only. When it appears, and where, is the anchor's decision — this
+ * component has neither a timer nor a position of its own. Both ship beside it, as
+ * `useTooltip` and `TooltipAnchor`, so that a consumer with a trigger this cannot
+ * wrap still has the parts to assemble one.
+ *
+ * `placement` names where the tooltip sits relative to its anchor — `top` is above
+ * it — and the caret is drawn on the opposite edge so it points back at what it
+ * describes. Naming the placement rather than the caret's own edge is what lets the
+ * wrapper pass one value straight through to two readers: the stylesheet that moves
+ * the chip, and this file that picks which triangle to draw. Neither has to remember
+ * to invert it. Nothing here moves the tooltip, so a `placement` that disagrees with
+ * where the chip actually sits is still the consumer's mistake to avoid.
+ *
+ * `role="tooltip"` carries no behaviour of its own; it is what makes the
+ * `aria-describedby` on the anchor announce as a description rather than as a
+ * second, unrelated run of text. Which is why the contract's second `a11y`
+ * requirement has no executable `check`: the association lives on the anchor,
+ * and nothing in this component's own DOM can prove it was made.
+ *
+ * `id` is not a declared prop — it arrives through `HTMLAttributes`, and the
+ * anchor needs it to point here at all. That is the reason this contract has an
+ * `api.extends` where Card deliberately does not.
+ *
+ * `showCaret` decides whether the caret is rendered at all, rather than rendered and
+ * hidden. That is a contract decision and not this file's: the anatomy declares the
+ * part `presentWhen: "showCaret"`, which is how a conditional part is described here
+ * and how the generated stylesheet and behaviour test both come to know about it.
+ * The alternative it replaced — one `placement` value meaning "nowhere", drawing a
+ * caret and then hiding it with `display: none` — spent a whole axis of the variant
+ * matrix on a chip that had no position to point from.
+ *
+ * DOM order is fixed: caret first, always. `flex-direction` carries the side —
+ * `column` and `column-reverse`, `row` and `row-reverse` — so which end of the
+ * chip the caret sits at is decided by the stylesheet from the contract, and this
+ * file never branches on placement.
+ *
+ * `hidden` shadows the native attribute of the same name and does not mean what it
+ * means: native `hidden` is `display: none`, and a tooltip that leaves the layout
+ * has nothing to fade from and no box to fade in. This one is a bound opacity, so
+ * the chip stays where it is, stays measurable, and stays pointed at by the anchor's
+ * `aria-describedby` — the description is still announced with the control it
+ * explains, which is the whole reason that association exists. Shadowing a native
+ * attribute is Input's precedent, where `size` means the control's scale rather than
+ * a character count.
+ */
+export declare function Tooltip({ placement, alignment, showCaret, hidden, children, ...rest }: TooltipProps): import("react").JSX.Element;

package/dist/components/core/tooltip/Tooltip.js

@@ -0,0 +1,87 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import './Tooltip.css';
+import './tooltip-impl.css';
+import { tooltipDefaults, tooltipParts } from './Tooltip.types.js';
+/**
+ * The caret, once per side the tooltip can sit on.
+ *
+ * Keyed by `placement`, which names where the tooltip is — so each entry holds the
+ * triangle that points back the other way, at the anchor. `top` means the tooltip
+ * is above its anchor, so `top` draws a triangle pointing down. Reading this table
+ * as "the direction the caret points" gets every entry backwards, which is the one
+ * mistake this shape invites.
+ *
+ * Four paths rather than one path rotated four ways, because rotation is not
+ * something a contract can express: `structure` carries CSS keywords, and every
+ * form of `rotate` needs an angle. Drawing each direction moves that decision
+ * into geometry, where it costs nothing — the shape of a triangle is not a design
+ * decision that a designer would ever want to vary by brand or mode.
+ *
+ * Shape is all that is left here. How big the caret is, and how far it sits from
+ * the chip's rounded corner, are both design decisions and both live in the
+ * contract — `width`/`height` per side, and `padding-inline`/`padding-block` for
+ * the inset that keeps the caret clear of the chip's rounded corner. This file
+ * carried the size for one pass, as an `em` ratio on the SVG itself, and that put
+ * a decision where no contract, no generated doc and no Figma push could see it.
+ *
+ * So there is no width or height attribute below. The stylesheet supplies both,
+ * and each direction carries only its own viewBox — the aspect the triangle is
+ * drawn at, which has to agree with the bound box or the shape would be scaled to
+ * fit and stop being the shape that was drawn.
+ */
+const CARET = {
+    top: { viewBox: '0 0 8 4', d: 'M0 0 L4 4 L8 0 Z' },
+    right: { viewBox: '0 0 4 8', d: 'M4 0 L0 4 L4 8 Z' },
+    bottom: { viewBox: '0 0 8 4', d: 'M0 4 L4 0 L8 4 Z' },
+    left: { viewBox: '0 0 4 8', d: 'M0 0 L4 4 L0 8 Z' },
+};
+/**
+ * The chip only. When it appears, and where, is the anchor's decision — this
+ * component has neither a timer nor a position of its own. Both ship beside it, as
+ * `useTooltip` and `TooltipAnchor`, so that a consumer with a trigger this cannot
+ * wrap still has the parts to assemble one.
+ *
+ * `placement` names where the tooltip sits relative to its anchor — `top` is above
+ * it — and the caret is drawn on the opposite edge so it points back at what it
+ * describes. Naming the placement rather than the caret's own edge is what lets the
+ * wrapper pass one value straight through to two readers: the stylesheet that moves
+ * the chip, and this file that picks which triangle to draw. Neither has to remember
+ * to invert it. Nothing here moves the tooltip, so a `placement` that disagrees with
+ * where the chip actually sits is still the consumer's mistake to avoid.
+ *
+ * `role="tooltip"` carries no behaviour of its own; it is what makes the
+ * `aria-describedby` on the anchor announce as a description rather than as a
+ * second, unrelated run of text. Which is why the contract's second `a11y`
+ * requirement has no executable `check`: the association lives on the anchor,
+ * and nothing in this component's own DOM can prove it was made.
+ *
+ * `id` is not a declared prop — it arrives through `HTMLAttributes`, and the
+ * anchor needs it to point here at all. That is the reason this contract has an
+ * `api.extends` where Card deliberately does not.
+ *
+ * `showCaret` decides whether the caret is rendered at all, rather than rendered and
+ * hidden. That is a contract decision and not this file's: the anatomy declares the
+ * part `presentWhen: "showCaret"`, which is how a conditional part is described here
+ * and how the generated stylesheet and behaviour test both come to know about it.
+ * The alternative it replaced — one `placement` value meaning "nowhere", drawing a
+ * caret and then hiding it with `display: none` — spent a whole axis of the variant
+ * matrix on a chip that had no position to point from.
+ *
+ * DOM order is fixed: caret first, always. `flex-direction` carries the side —
+ * `column` and `column-reverse`, `row` and `row-reverse` — so which end of the
+ * chip the caret sits at is decided by the stylesheet from the contract, and this
+ * file never branches on placement.
+ *
+ * `hidden` shadows the native attribute of the same name and does not mean what it
+ * means: native `hidden` is `display: none`, and a tooltip that leaves the layout
+ * has nothing to fade from and no box to fade in. This one is a bound opacity, so
+ * the chip stays where it is, stays measurable, and stays pointed at by the anchor's
+ * `aria-describedby` — the description is still announced with the control it
+ * explains, which is the whole reason that association exists. Shadowing a native
+ * attribute is Input's precedent, where `size` means the control's scale rather than
+ * a character count.
+ */
+export function Tooltip({ placement = tooltipDefaults.placement, alignment = tooltipDefaults.alignment, showCaret = tooltipDefaults.showCaret, hidden = tooltipDefaults.hidden, children, ...rest }) {
+    const caret = CARET[placement];
+    return (_jsxs("div", { className: tooltipParts.root, role: "tooltip", "data-placement": placement, "data-alignment": alignment, "data-hidden": hidden, ...rest, children: [showCaret && (_jsx("svg", { className: tooltipParts.caret, viewBox: caret.viewBox, "aria-hidden": "true", children: _jsx("path", { d: caret.d, fill: "currentColor" }) })), _jsx("div", { className: tooltipParts.body, children: children })] }));
+}

package/dist/components/core/tooltip/Tooltip.types.d.ts

@@ -0,0 +1,38 @@
+import type { HTMLAttributes, ReactNode } from 'react';
+export interface TooltipOwnProps {
+    /**
+     * `top` — The tooltip sits above its anchor, so the caret drops from the bottom edge to meet it
+     * `right` — The tooltip sits on the trailing side of its anchor — the right in English, the left in Arabic — so the caret reaches back across to meet it. The name is physical and the behaviour is logical: the chip's own direction mirrors this, caret and all
+     * `bottom` — The tooltip sits below its anchor, so the caret rises from the top edge to meet it
+     * `left` — The tooltip sits on the leading side of its anchor — the left in English, the right in Arabic — so the caret reaches across to meet it. The name is physical and the behaviour is logical: the chip's own direction mirrors this, caret and all
+     */
+    placement?: 'top' | 'right' | 'bottom' | 'left';
+    /**
+     * `center` — The chip is centred on its anchor and the caret's point lands on the middle of it. Use this unless the chip is much wider than the thing it points at
+     * `start` — The chip's leading edge lines up with the anchor's own, so a chip wider than its anchor grows away from it rather than back across the layout. For an anchor at the start of a row
+     * `end` — The mirror of start: the chip's trailing edge lines up with the anchor's, for an anchor at the end of a row
+     */
+    alignment?: 'center' | 'start' | 'end';
+    /** Whatever reveals the tooltip has not revealed it yet, or has dismissed it. Defaults to false, which means visible — so something has to drive this, or the chip is simply on. Keeping it mounted and hidden rather than unmounting it is what lets it fade in, and what keeps the anchor's aria-describedby pointing at something real.
+  
+  Flipping it is the whole animation. The chip fades from opacity.hidden and scales up from motion.scale.enter over motion.duration.fast on motion.easing.enter, growing out of the edge nearest its anchor rather than its own middle. The dismissal is not animated at all — transition-duration is motion.duration.instant while hidden, because by then the pointer has already gone somewhere else. Do not write a transition of your own: the stylesheet declares transition-property from what this axis changes, and a second declaration would both override that list and escape the prefers-reduced-motion guard generated with it. */
+    hidden?: boolean;
+    /** Drawn by default. Leave it on whenever something holds the chip against its anchor — the point is what ties a floating description to the control it belongs to */
+    showCaret?: boolean;
+    /** Allowed: text */
+    children: ReactNode;
+}
+export type TooltipProps = TooltipOwnProps & Omit<HTMLAttributes<HTMLDivElement>, 'className' | 'placement' | 'alignment' | 'hidden' | 'showCaret'>;
+/** The class each part carries. Apply these — do not retype them. */
+export declare const tooltipParts: {
+    readonly root: "dds-tooltip";
+    readonly caret: "dds-tooltip__caret";
+    readonly body: "dds-tooltip__body";
+};
+/** Generated so defaults cannot drift from the contract. */
+export declare const tooltipDefaults: {
+    readonly placement: "top";
+    readonly alignment: "center";
+    readonly hidden: false;
+    readonly showCaret: true;
+};

package/dist/components/core/tooltip/Tooltip.types.js

@@ -0,0 +1,9 @@
+// GENERATED from tooltip.contract.json. Do not edit.
+/** The class each part carries. Apply these — do not retype them. */
+export const tooltipParts = {
+    root: 'dds-tooltip',
+    caret: 'dds-tooltip__caret',
+    body: 'dds-tooltip__body',
+};
+/** Generated so defaults cannot drift from the contract. */
+export const tooltipDefaults = { placement: 'top', alignment: 'center', hidden: false, showCaret: true };

package/dist/components/core/tooltip/TooltipAnchor.d.ts

@@ -0,0 +1,52 @@
+import './tooltip-anchor.css';
+import { type HTMLAttributes, type ReactElement, type ReactNode } from 'react';
+import { type TooltipProps } from './Tooltip.types.js';
+import { type UseTooltipOptions } from './use-tooltip.js';
+export interface TooltipAnchorProps extends UseTooltipOptions {
+    /**
+     * The trigger: one element, which the description is attached to and the pointer and
+     * focus handlers are added to. It has to be something focus can rest on — a button
+     * or a link, not a span — or the description is one no keyboard ever reaches.
+     *
+     * Typed as a single element rather than ReactNode because this clones it. Text, a
+     * fragment or a list has nothing to clone and nowhere to put an aria-describedby, so
+     * the constraint is better carried by the type than discovered at runtime.
+     *
+     * A component works as well as a plain element, provided it forwards the props it is
+     * handed — which is what a contract's `api.extends` promises, and why Button can be a
+     * trigger. One that declares none swallows them silently: the type still fits, and the
+     * description reaches nothing.
+     */
+    children: ReactElement<HTMLAttributes<HTMLElement>>;
+    /** The description. Short — the contract's own guidance is that this is a label, not a panel. */
+    content: ReactNode;
+    /**
+     * Which side of the anchor the chip sits on, passed straight through to the chip so
+     * one value places the box and draws the caret pointing back the other way.
+     */
+    placement?: TooltipProps['placement'];
+    /** Where along that side, which is the axis the placement did not use. */
+    alignment?: TooltipProps['alignment'];
+    /** Passed through to the chip, which renders the caret or leaves it out. */
+    showCaret?: TooltipProps['showCaret'];
+}
+/**
+ * A trigger and its tooltip, placed against each other.
+ *
+ * `Tooltip` is the chip and nothing else, and `useTooltip` is when it arrives. This is
+ * the third thing neither of them does: where it lands. It is a wrapper rather than
+ * anything cleverer because the placement is pure CSS — one positioning context around
+ * both boxes, and `placement` read by a stylesheet — so there is nothing to measure,
+ * nothing to watch for resizes, and no layout pass to be one frame behind.
+ *
+ * What that buys is that the caret now lands on the point it names. What it does not
+ * buy is flipping: a chip whose named side has no room overflows rather than moving to
+ * the side that does, because knowing there is no room means measuring the viewport.
+ * The contract says as much in its own guidance, and this module does not retract it.
+ *
+ * Reach past this to `useTooltip` when the trigger is not something this can wrap —
+ * one already inside another component, or one that is not an element at all. That is
+ * the whole of what an external anchor needs: the hook's `anchorProps` go on whatever
+ * the trigger turns out to be, and `tooltipProps` on a chip rendered wherever suits.
+ */
+export declare function TooltipAnchor({ children, content, placement, alignment, showCaret, ...options }: TooltipAnchorProps): import("react").JSX.Element;

package/dist/components/core/tooltip/TooltipAnchor.js

@@ -0,0 +1,69 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import './tooltip-anchor.css';
+import { cloneElement } from 'react';
+import { Tooltip } from './Tooltip.js';
+import { tooltipDefaults } from './Tooltip.types.js';
+import { useTooltip } from './use-tooltip.js';
+/**
+ * The two boxes this renders. Written here and in tooltip-anchor.css, and nowhere
+ * else — there is no generated constant for them, because they are this module's own
+ * DOM rather than parts the contract declares. A part declared in the contract has to
+ * appear in Tooltip's own markup, and keeping a positioning wrapper out of Tooltip is
+ * what this module is for.
+ */
+const parts = {
+    root: 'dds-tooltip-anchor',
+    tip: 'dds-tooltip-anchor__tip',
+};
+/**
+ * Both handlers, the trigger's own first.
+ *
+ * cloneElement replaces rather than merges, so a trigger that already listened for the
+ * pointer would silently stop doing so — the kind of loss that shows up as a bug in
+ * the consumer's own code, nowhere near here.
+ */
+function chain(theirs, ours) {
+    if (theirs === undefined)
+        return ours;
+    return (event) => {
+        theirs(event);
+        ours(event);
+    };
+}
+/**
+ * A trigger and its tooltip, placed against each other.
+ *
+ * `Tooltip` is the chip and nothing else, and `useTooltip` is when it arrives. This is
+ * the third thing neither of them does: where it lands. It is a wrapper rather than
+ * anything cleverer because the placement is pure CSS — one positioning context around
+ * both boxes, and `placement` read by a stylesheet — so there is nothing to measure,
+ * nothing to watch for resizes, and no layout pass to be one frame behind.
+ *
+ * What that buys is that the caret now lands on the point it names. What it does not
+ * buy is flipping: a chip whose named side has no room overflows rather than moving to
+ * the side that does, because knowing there is no room means measuring the viewport.
+ * The contract says as much in its own guidance, and this module does not retract it.
+ *
+ * Reach past this to `useTooltip` when the trigger is not something this can wrap —
+ * one already inside another component, or one that is not an element at all. That is
+ * the whole of what an external anchor needs: the hook's `anchorProps` go on whatever
+ * the trigger turns out to be, and `tooltipProps` on a chip rendered wherever suits.
+ */
+export function TooltipAnchor({ children, content, placement = tooltipDefaults.placement, alignment = tooltipDefaults.alignment, showCaret = tooltipDefaults.showCaret, ...options }) {
+    const { anchorProps, tooltipProps } = useTooltip(options);
+    const own = children.props;
+    const described = own['aria-describedby'];
+    const trigger = cloneElement(children, {
+        // Appended rather than replaced. A trigger that already carries a description has
+        // two of them, and a reader is meant to hear both.
+        'aria-describedby': described === undefined
+            ? anchorProps['aria-describedby']
+            : `${described} ${anchorProps['aria-describedby']}`,
+        onPointerEnter: chain(own.onPointerEnter, anchorProps.onPointerEnter),
+        onPointerLeave: chain(own.onPointerLeave, anchorProps.onPointerLeave),
+        onFocus: chain(own.onFocus, anchorProps.onFocus),
+        onBlur: chain(own.onBlur, anchorProps.onBlur),
+    });
+    return (_jsxs("span", { className: parts.root, children: [trigger, _jsx("span", { className: parts.tip, "data-placement": placement, "data-alignment": alignment, children: _jsx(Tooltip, { ...tooltipProps, placement: placement, alignment: alignment, showCaret: showCaret, children: content }) })] }));
+}

package/dist/components/core/tooltip/tooltip-anchor.css

@@ -0,0 +1,145 @@
+/*
+ * Placement for TooltipAnchor, which no contract describes.
+ *
+ * These two boxes are a behaviour module's own DOM rather than parts of the
+ * component's anatomy, and the difference is load-bearing: a part declared in the
+ * contract has to appear in Tooltip's own markup — the generated behaviour test
+ * asserts exactly that — and keeping a positioning wrapper out of Tooltip is the
+ * whole reason this module exists. So the classes are written here and in
+ * TooltipAnchor.tsx, and nowhere else.
+ *
+ * Every value is a token, read through the same custom properties the chip's own
+ * generated stylesheet reads. Nothing here is a raw dimension: `100%`, `50%`, `0`
+ * and `max-content` are the geometry of "beside the anchor", not sizes anyone would
+ * want to tune per brand.
+ */
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor {
+  /* The positioning context. Inline-block so it hugs the trigger rather than
+     whatever column the trigger sits in — otherwise a chip centred on the anchor
+     centres on the column, and lands nowhere near the thing it describes. */
+  position: relative;
+  display: inline-block;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip {
+  position: absolute;
+
+  /* Out of the flow means shrink-to-fit, and shrink-to-fit against a single inset is
+     measured from that inset to the containing block's edge — so a wide chip on a
+     narrow trigger would wrap at whatever that distance happened to be. max-content
+     puts the measure back on the text, and the chip's own max-inline-size still caps
+     it. This is the one thing the preview harness that prototyped this never hit,
+     because its trigger was always wider than its sample sentence. */
+  width: max-content;
+
+  /* Never a target. The chip already refuses the pointer, but this box is larger than
+     the chip's ink and sits over content the pointer does need. */
+  pointer-events: none;
+
+  /* How far the chip clears the anchor: the caret's own height, so that the gap and
+     the thing crossing it scale together. It stays the same with showCaret false —
+     a description touching the control it describes reads as part of it. */
+  --dds-tooltip-anchor-gap: var(--space-gap-xs);
+
+  /*
+     Above the page it floats over.
+     `position: absolute` alone leaves this at `z-index: auto`, which paints in tree
+     order among positioned elements — so any positioned sibling declared later covers
+     the chip, and a tooltip on the first of two cards loses to the second. Measured
+     before this line existed: `tipZ: auto`.
+     `layer.popup` rather than a number chosen here. The primitive ramp has carried
+     0/100/200/300/400/800/1600 all along, and the reason components reach for bare
+     integers is that no semantic role pointed at it — so this is the first consumer of
+     the role rather than the eighth hand-picked value.
+     It does not make the chip immune. A z-index only orders siblings within a stacking
+     context, so an ancestor that creates one — a transform, a filter, an opacity below
+     1, an isolation — still traps the chip inside it however high this goes. The only
+     thing that escapes that is the top layer, which means the popover API and a
+     different positioning story. Worth knowing before this is trusted absolutely. */
+  z-index: var(--layer-popup);
+}
+
+/*
+ * Which side the chip sits on, read from `placement` directly rather than through a
+ * vocabulary of its own — that prop already names where the tooltip is, which is why
+ * it names the placement and not the caret's edge. A lookup translating one name into
+ * another is a second opinion waiting to disagree with the contract.
+ *
+ * Logical insets, because `left` and `right` name the leading and trailing side rather
+ * than two points of the compass: a leading-side tooltip is on the right in Arabic, and
+ * `inset-inline-end` puts it there with nothing here to help it. The block axis is not
+ * mirrored by direction, so `top` and `bottom` mean what they say.
+ */
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='top'] {
+  inset-block-end: 100%;
+  margin-block-end: var(--dds-tooltip-anchor-gap);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='bottom'] {
+  inset-block-start: 100%;
+  margin-block-start: var(--dds-tooltip-anchor-gap);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='left'] {
+  inset-inline-end: 100%;
+  margin-inline-end: var(--dds-tooltip-anchor-gap);
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='right'] {
+  inset-inline-start: 100%;
+  margin-inline-start: var(--dds-tooltip-anchor-gap);
+}
+
+/*
+ * Where along that side, which is the axis the placement did not use: the inline axis
+ * for a chip above or below, the block axis for one beside. Twelve arrangements in all,
+ * which is the number the contract's own guidance names.
+ *
+ * Centring is the one place a physical inset is correct. `left: 50%` puts the chip's
+ * left edge on the anchor's middle and the shift takes back half the chip's width, and
+ * those two cancel in either direction — a logical inset would need the shift to change
+ * sign with the direction, which is two rules to say what one says here.
+ *
+ * `start` and `end` share an edge with the anchor instead: the chip's leading edge on
+ * the anchor's leading edge, its trailing on the trailing. What they did before was hold
+ * the caret's point over the anchor's middle, which is what `center` is already for —
+ * two of the three values agreed about the caret and disagreed about the chip, and the
+ * chip wider than its anchor hung back across the layout it came from. An inset of zero
+ * is the whole rule now, and the caret lands wherever its own inset from that edge puts
+ * it: inside any anchor wider than the corner it clears.
+ */
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='top'][data-alignment='center'],
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='bottom'][data-alignment='center'] {
+  left: 50%;
+  translate: -50% 0;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='top'][data-alignment='start'],
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='bottom'][data-alignment='start'] {
+  inset-inline-start: 0;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='top'][data-alignment='end'],
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='bottom'][data-alignment='end'] {
+  inset-inline-end: 0;
+}
+
+/* The same three arrangements on the block axis, for a chip beside its anchor. The
+   harness that prototyped this placed those centred whatever the alignment said, which
+   left four of the twelve points unreachable. */
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='left'][data-alignment='center'],
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='right'][data-alignment='center'] {
+  inset-block-start: 50%;
+  translate: 0 -50%;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='left'][data-alignment='start'],
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='right'][data-alignment='start'] {
+  inset-block-start: 0;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='left'][data-alignment='end'],
+:where([data-dds-context="marketing"]) .dds-tooltip-anchor__tip[data-placement='right'][data-alignment='end'] {
+  inset-block-end: 0;
+}

package/dist/components/core/tooltip/tooltip-impl.css

@@ -0,0 +1,54 @@
+/* Implementation CSS that the contract's staticCss cannot express. */
+
+/*
+ * The caret's drawing, mirrored for right-to-left.
+ *
+ * `placement` left and right name the leading and trailing side, not two fixed
+ * points of the compass, and the chip's own `flex-direction` is already logical —
+ * `row` and `row-reverse` follow the inline direction. So the caret's *box* moves to
+ * the correct edge under RTL with nothing here to help it: a tooltip on the leading
+ * side is on the right in Arabic, and its caret lands on the left, which is the edge
+ * facing the anchor.
+ *
+ * What cannot follow is the triangle. It is one of four fixed paths in Tooltip.tsx,
+ * drawn rather than rotated because an angle is not something a contract can carry,
+ * and a path has no way to flip itself. Without this rule the box arrives on the
+ * correct edge with the point aimed away from the anchor — the one arrangement worse
+ * than having no caret at all.
+ *
+ * The inline axis only. `top` and `bottom` sit on the block axis, which right-to-left
+ * does not mirror; scaling those would take a caret that already points at its anchor
+ * and turn it around.
+ *
+ * `scale` rather than `transform`, so that a consumer's own transform on the part is
+ * not silently replaced by this one.
+ */
+:where([data-dds-context="marketing"]) .dds-tooltip:dir(rtl)[data-placement='left'] .dds-tooltip__caret,
+:where([data-dds-context="marketing"]) .dds-tooltip:dir(rtl)[data-placement='right'] .dds-tooltip__caret {
+  scale: -1 1;
+}
+
+/*
+ * The transform origin's inline half, mirrored for right-to-left.
+ *
+ * The chip scales up out of the edge nearest its anchor, and the contract names that
+ * edge per placement — `left` places the chip on the leading side, so the edge facing
+ * the anchor is its `right`. That holds in English and inverts in Arabic: the leading
+ * side is the right, the chip sits there, and the edge facing the anchor is its `left`.
+ *
+ * `transform-origin` has no logical keyword to say this with. It takes `left` and
+ * `right`, never `inline-start` — so unlike `flex-direction` and the logical insets in
+ * tooltip-anchor.css, the generated rule cannot follow the direction on its own, and
+ * this is the same gap the caret's path above falls into.
+ *
+ * The inline axis only, for the same reason: `top` and `bottom` sit on the block axis,
+ * which right-to-left does not mirror. Without this the chip grows out of the edge
+ * facing away from its anchor, which reads as retreating from the control it describes.
+ */
+:where([data-dds-context="marketing"]) .dds-tooltip:dir(rtl)[data-placement='left'] {
+  transform-origin: left;
+}
+
+:where([data-dds-context="marketing"]) .dds-tooltip:dir(rtl)[data-placement='right'] {
+  transform-origin: right;
+}