Range picker

Anatomy

A group and its segments: two levels and nothing else. Everything below is drawn by design/system/components/range-picker.css through the same entry point a product screen loads, so this page cannot drift from the screens.

• .range the group: a flex row with an 8px gap and a bottom margin. It carries role="group" and the accessible name, so a screen reader announces "Choose a time range" once instead of three unrelated buttons
• .range button the segment. flex: 1, so the three divide whatever width the screen gives them and "12 months" is exactly as wide as "3 months". A real button, never a link: nothing here navigates
• [aria-pressed] which one is current. The attribute IS the selector: there is no .is-selected class anywhere, so the state a screen reader announces and the state the stylesheet paints are one fact
• [disabled] the native attribute, set on all three behind the Pro gate. It also takes the segment out of the tab order, which a class could not do
• min-height reads --tap. It was 40px in the grey, the only product control in the whole set under the floor, and it was raised at stage 07

Variants and sizes

One axis and no size axis at all: a segment's width comes from the group and its height is the 44px floor everywhere. But the axis is a cross rather than a list, and drawing it as a list is exactly how the fourth form went unnamed for a stage. Availability has two values and selection has two, so there are four cells, and all four render in the product today.

The fourth cell was found by measuring, not by reading. The census walked the rendered product and reported that on history-trends-locked the "3 months" segment is disabled AND bold: [aria-pressed="true"] sets the weight, [disabled] overrides colour, fill and border and leaves the weight alone, and the two attributes sit at the same specificity so source order decided it. Nobody chose that. Step 2 decided it is the right answer anyway and that it becomes a declared form, so the rule now exists at its own specificity with its reason attached. Not one pixel moves: the declaration writes down what the cascade was already producing.

Width is deliberately not an axis, and neither is count. Three segments is what the product has, and a fourth would fit by arithmetic alone; what it would cost is legibility at 360px, where the three already measure 99px each on the coloured Your trends screen as it renders today.

2026-08-18: three buttons became one segmented control

The founder, on the coloured Pro gate at a desktop width: “я не понимаю, что это у нас тут вообще огромные кнопки зачем-то”. They were three separate bordered buttons, each flex: 1 of an uncapped pane. Measured before: 250.67px a segment at a 1440 window, three 250 by 44 slabs across the top of the screen - heavier than the chart whose range they choose, and heavier than the primary action further down the page.

A segmented control is one object with three parts, and that is the whole change. A recessed track, three transparent segments inside it, and no border on any of them: the three borders are what made the group read as three controls, and with the track carrying the shape the selection is a figure on a ground instead of an outline among outlines. Measured after: the track is 320 by 48 from a 520px window up, and 100% of the column below that, so a segment never goes under the 44px floor on a phone. It was 384 by 52 until 2026-08-19; see the cap below.

The cap is 20rem and it is arithmetic, not taste. “12 months” is the widest label; at --type-body with 16px of side padding a segment needs about 102px, so three of them plus the track's own padding need roughly 314. 20rem is 320, the tightest register that still clears it. flex: 1 stays and its old reason with it: the three segments divide the track, so “12 months” and “3 months” are the same size and the group reads as one thing.

It came down from 24rem on 2026-08-19, on the founder's decision: "кнопки переключения очень большие". At 384 by 52, alone on a line across a 1280 screen, it was the largest object above the fold on a screen whose subject is a number. Two values moved and neither is the tap target: the cap 24rem to 20rem, so a segment is 104 rather than 126, and the track's padding --space-4 to --space-2, so the control is 48 tall rather than 52. min-height: var(--tap) on the segment did not move and may not - 44px is the floor a pointer target may not go under, and shrinking a control by shrinking what a thumb has to hit is the one way to get this wrong. The control lost 64px of width and 4px of height; the thing a person presses is exactly the size it was.

What did NOT change is the selection, and that was deliberate. The chosen segment keeps --bg-selected and --text-action: petrol on the current selection is the second of the four jobs the One Voice Rule allows it, and lifting the selection onto a white pill with a shadow - the other common way to draw this control - would have quietly spent that decision. Only the border went, on every state, because there is no border on a segment any more. The hover is the ink coming up instead of an edge appearing.

When to use it

A person meets this on Your trends, which is a Pro screen, and most of them meet it behind the gate first: the canonical person in this product is on Free, so the locked view is the only view of that screen she can have. That is why the disabled forms matter more here than they would anywhere else. They are not an edge case, they are the majority of the renders.

Its job is to re-frame what is already on the screen, never to fetch a different screen. "How your monthly total has moved over time. Nothing to act on here, just the shape of it." The picker changes the window on that sentence and nothing about the sentence's job, which is why it is a selection and not an action, and why choosing a range is not something a person can get wrong.

The rule, and the anti-rule

Limits

U13, context. PRESS. A segment goes down by one nudge while it is held. The disabled segment does not move: it is the Pro range on a Free account, and moving it would answer a press the product will not honour. Everything in this product that moves travels exactly one --nudge, which is 2px, and nothing anywhere travels two. Hover and release run at --dur-state (150ms) on --ease-arrive; a press runs at --dur-press (90ms), because it answers a finger that is already down. The full language and the live specimens are on Motion; the table with sources is Usage rules.

It switches the screen, since 2026-08-19

The other half of the founder's sentence was "и не работают", and it was true: three segments that had never moved a pixel on the screen behind them since the wireframe. A control that does nothing is a defect and not a style, so this is the fix, and none of it is in this file.

The data lives on the button that selects it. Each segment carries data-points and data-scale for the range it names, and design/system/behaviour.js copies them onto every chart in the screen and asks it to redraw from its own two attributes. Nothing here knows the geometry, and nothing about the picker's own CSS changed to make it work.

What switches besides the picture is declared in the markup, not built by the script. Any element in the screen carrying data-view names which ranges it belongs to, as a space-separated list of the same keys the buttons use. That is how a sentence written for three months and a row that only moved over twelve stay product copy with an owner in voice/docs/microcopy.md, rather than strings a script assembles. Buttons are skipped: a data-view on a button names what it SELECTS, not where it appears.

With no script the screen is the three-month view, whole and correct, and this control looks pressed on it because the markup says so. That is the same bargain the chart makes with its authored path. The disabled form behind the Pro gate carries no data at all, and the script leaves it alone: a control that cannot be used must not move anything.

States

Four states, and they exist because a segment is a real button. Each one is a token override rather than a style of its own: no hex and no number appears inside :hover, so the dark theme costs three lines in tokens.css rather than a rewrite here.

Hover is declared before selection, and that order is the decision. The two rules are the same specificity, so the later one wins on a segment that is both, and the selected segment therefore does not repaint under the pointer. That is right rather than accidental: the pointer is asking "what happens if I press this", and for the current range the answer is nothing you have not already got.

Rest and disabled, live

The second group is genuinely disabled, by the attribute rather than by a class the product does not carry. Tab through both: the first group takes three stops and the second takes none, which is the attribute doing a job no class could do.

The four, in both themes

The states are described, not photographed. Founder's decision, 2026-08-11: the snapshot strip went from every page in this kit, 120 images across 18 pages. They were framed as measurements rather than illustrations, and that framing was honest, but the bill came due all session: a value moves, and every picture of it is quietly stale until somebody re-shoots it. A stale picture is worse than no picture, because it looks checked. What is left is what a picture never carried anyway: the state, and the token it reads. The resting component is live and interactive above, so hover it, tab to it, and read the value off the real thing rather than off a photograph of it.

Active is not shown and that is not an omission. The component declares none: pressing a segment selects it, so what a person sees on release is the selected form, and a separate pressed paint between the two would be a third appearance in a quarter of a second.

The technical half

Lives in design/system/components/range-picker.css. Stands on 3 grey pages and all three of their coloured copies: Your trends, the Pro gate, its loading state. It has no class name of its own and is selectable only as .range button, which the census filed as a control with no family. Step 6 renamed what the map listed and this is not on it, so the finding is still open and still not corrected here.