Density inventory

Every dp dimension that teksilo-widgets, the three theme presets and teksilo-preview-ui bake in, with the density treatment package P20 applied to each — the route by which that dimension reaches a density, or the reason it has none. This is the artifact to audit conformance against, and the fixture list P40's target-conformance gate walks; it is also the evidence behind the target numbers quoted in the touch design.

Status: P20 has landed. The treatment column is no longer a plan. Each row either names the function that resolves it (FooRecipe::for_tokens, foo_bar(&InputTokens), density_min_size(..)) or says, in the same column, why the dimension is fixed and which mechanism carries its touch conformance instead. crates/teksilo-widgets/tests/density_projection.rs parses this document and holds it to those rules, so a row that claims a treatment the code does not implement fails a test rather than misleading a reader.

How a dimension reaches a density

The projection is not a token read at paint time. ComponentStyleSlots is empty in every shipped preset, so there is nothing in a Theme to re-run; instead each recipe reads the tokens at its own construction site, in the crate that owns it. Three things make that work:

1. Every Recipe*Style and its *Recipe gained for_tokens(&InputTokens) -> Self, and Default is now defined as for_tokens(&InputTokens::default()) — so the Compact column below cannot drift from the shipped values.
2. Every widget's lazy fallback — Rc::new(RecipeFooStyle::default()) — became Rc::new(RecipeFooStyle::for_tokens(&ctx.theme().input)), a one-line change at a site that already existed.
3. A preset that installs Tier-3 slots of its own registers a teksilo_core::styles::DensityProjection in its theme extensions. Theme::with_density calls it when present, so Fluent, macOS and Material 3 rebuild their slots for the new density instead of carrying Compact dimensions across. A slot an app installed stays untouched — a hand-written style owns its own metrics — which is documented behaviour, not an oversight.

WidgetTree::set_input_density marks BindingLevel::Rebuild, because a dimension baked in build() cannot be moved by a layout+paint mark.

The floor rule, and why some Targets do not scale

dp(base, TargetRole::Target, tokens) is a floor — base.max(target_size) — so routing a dimension whose Compact value is below 24 dp through it would raise it at Compact, which the programme's no-regression invariant forbids. Therefore:

A Target dimension is routed through dp(.., Target, ..) only when its Compact value already meets min_target_conformance (24 dp). Every sub-24 dimension keeps its painted value at every density and takes its conformance from the hit mechanisms — hit_outset, target_regions, partition_targets, the miss-only slop pass — which is exactly what A10 designed them for ("hit-only: no layout moves, Compact renders identically").

The one exception is a MinSize: a MinSize is a hit box, and 24 dp is the floor that governs hit boxes, so density_min_size enforces it there. The sites in the whole tree that were below it are enumerated in §0, and each of them changes at Compact. That list is the only place the count lives, so a later package that takes another such exception adds a row there rather than a number here.

§0 — the sites that change at Compact

The only Compact-visible changes the density work makes, and the enumeration the rest of this document and the target-conformance gate both defer to: an exception that is not a row here has not been taken. Each was an interactive control whose own minimum hit box sat below WCAG 2.2 SC 2.5.8 (level AA). Rows are not call sites — the macOS entry below is four sites, three of them on one constant and the fourth on two rungs of its own.

Nothing else in the rows below changes at Compact.

One row left this table, and P40 measured why. text_input.rs's clear button was a fourth entry here: 16 dp raised to a 24 dp MinSize box. A later touch package replaced that with a hit-only mechanism — the slot is crate::button::HitTarget::fixed(16.0, 16.0) declaring a Widget::hit_outset, so the paint stays 16 dp at every density and the field's row does not widen. text_input.rs's own module doc states the trade ("raising its box would widen every field in the workspace at Compact"), and the target-conformance gate measures the result: the slot paints 16 × 16 and reaches 24 × 24 at Compact, pinned by an_outsets_claim_survives_the_slop_pass_in_the_shipped_controls. It is therefore not a Compact-visible change and cannot sit in a table whose whole job is to enumerate those. That figure is the slot with a query typed; with the field empty HitTarget::active withdraws the outset and the same slot reaches 22 × 24 while still taking the press — a written allow-list entry of its own, measured by the search_field/empty fixture, and a targeting question rather than a dimension one. The §1 row for its old MinSize::new call site is corrected in place rather than deleted, so the site P02 audited is still accounted for.

The completion-popup row is the same exception as the others and worth stating once more, because it is the case where the floor rule's escape hatch does not exist: a stack of adjacent rows cannot take its conformance from hit_outset, since the only neighbour a row could borrow space from is another row, and an outset on each of them just moves the boundary between the two. A MinSize is a hit box, 24 dp is the floor that governs hit boxes, and the paint has to move.

Dimensions live in three homes, and P20 has to reach all three:

1. MinSize::new(w, h) call sites — the existing hit-area pattern (§1).
2. crates/teksilo-widgets/src/styles/recipe_*_style.rs — the 39 default Tier-3 recipes, whose module constants are the real dimension table for every themable widget (§2).
3. const … : f32 in the widget modules themselves, plus the theme presets' own constants (§3, §4).

Classification

Two treatments recur and mean something specific:

• "visual fixed; grab via hit_outset" — the painted geometry is unchanged at every density (Compact renders identically, which is the programme invariant); only the hit rectangle grows. A 6 dp splitter gutter still paints 6 dp and is grabbable at 24 dp (44 at Touch).
• "moves into GestureProfile" — the constant is a recognizer threshold, not a layout dimension. It leaves the widget entirely and becomes a per-pointer-kind token; density does not enter into it.

How each count was measured

# §1 — MinSize::new call sites (all, before excluding tests)
grep -rn "MinSize::new" --include=*.rs crates/ | wc -l                        # 40

# §2 — recipe files, and the one carrying a min_size field
ls crates/teksilo-widgets/src/styles/recipe_*_style.rs | wc -l                # 39
grep -rln "min_size" crates/teksilo-widgets/src/styles/recipe_*_style.rs      # 1 file
grep -rnE '^\s*(pub )?const [A-Z_0-9]+: f32' \
     crates/teksilo-widgets/src/styles/recipe_*_style.rs | wc -l              # 233

# §3 — widget-module constants outside styles/
cd crates/teksilo-widgets/src
grep -rnE '^\s*pub const [A-Z_0-9]+: f32' --include=*.rs . \
  | grep -v '/styles/' | grep -v 'tests.rs' | wc -l                           # 53
grep -rnE '^\s*const [A-Z_0-9]+: f32' --include=*.rs . \
  | grep -v '/styles/' | grep -v 'tests.rs' | wc -l                           # 113

# §4 — theme presets and the previewer UI
grep -rnE '^\s*(pub )?const [A-Z_0-9]+: f32' --include=*.rs \
     crates/teksilo-theme-{fluent,macos,material3}/src \
     crates/teksilo-preview-ui/src | grep -v tests.rs | wc -l                 # 133

Totals

Class counts after P20's corrections (the pre-flight classification is in Corrections; 27 sub-24 dp Target rows moved to a visual-fixed treatment, which is why Decoration is larger and Target smaller than the P02 pass reported).

Of those, 228 rows carry a live density route (97 through dp(.., Target, ..) or density_min_size, 128 through spacing(..), plus the three MinSize floor sites); the rest are fixed, each with its reason in its own row.

The §2 and §3b row counts are one below their grep counts (233 and 113): each table drops a single-letter local alias declared inside a function body — recipe_tab_style.rs:484 (const T: f32 = TAB_UNDERLINE_ACTIVE;) and preview_catalog/icons.rs:22 (const SZ: f32 = 16.0;). Neither is a dimension definition.

"Not a dimension" rows are ratios, alphas, shadow densities, epsilons and durations that the const … : f32 grep sweeps up; they are listed so a later reader can see they were considered and dismissed, not missed.

Corrections to the pre-flight estimates

Corrections P20 made to this document

The counts above survived; four classifications and one value did not, and the row that made the largest difference was one nobody had looked at twice.

Corrections P25 made to this document

Every count above survived. What did not is the assumption behind them: a projected recipe field is only a projection if something reads it. Four consumers measured against the raw Compact constant while the recipe beside them carried the projected value, so the ladder was inert for four of the most common targets in a real application.

One refusal, with its measurement

docking/activity_bar.rs's item_extent maps an IconButtonSize to a rail item's square extent by reading the raw ICON_BUTTON_SIZE_* constants, and P25 left it that way. The reason is the one already recorded for the rail's gaps: the same function feeds the strip's layout, its overflow-capacity estimate and its drop-insertion geometry, two of them pure functions with their own unit tests and no theme in scope, and projecting one without the others makes the rail's capacity disagree with its layout. What the projection would buy is comfort, not reach — every IconButtonSize a rail can carry (24 / 24 / 30 / 40 / 50 dp) already clears min_target_conformance, which is 24 dp at every density, and the rail's default is 40. Owner for any future change: whoever revisits the rail's geometry as a whole.

Corrections P40 made to this document

The target-conformance audit measures a target's reachable extent rather than its painted one, so it is the first reader of this document that could not take a named mechanism on trust: a row naming a mechanism that does not exist measures short and the gate says so. Five rows below were wrong, in three ways — two named a mechanism the code could not implement, two named one that is implemented and does not deliver, and one understated a floor. The first two are the same failure P25 recorded for SPLIT_BUTTON_CHEVRON_WIDTH — a mechanism named in the treatment column that the code could not implement as written — which makes it the failure mode the next reader of this table should look for first.

Dimensions that are not constants

Three dimensions the audit flagged were inline literals with no constant to rename. P20 introduced one for each; all three are below the 24 dp floor, so the constant names a painted extent that stays put at every density, and the treatment column says which hit mechanism — if any — makes up the shortfall.

This table's second column names the function, not a line: of 34 line citations in one earlier artifact exactly one still resolved 36 packages later, and two of the four rows P40 rewrote below carried an off-by-one. A function name survives a refactor that renumbers a file, which is the same reason TargetMeasurement::path is a chain of type names.

table_view/header.rs splits one header cell into a label zone and a filter zone by coordinate inside a single node (filter_zone_width, read in HeaderCell::build and in HeaderCell::target_regions); it has no dp constant at all and is handled by core::partition_targets through one header_cell_zones function, not by a density projection. Its floor per zone is the density's target_size — 24 dp at Compact, 32 and 44 above it — read once in HeaderCell::build and cached, because a density change marks the tree at BindingLevel::Rebuild. It is not a fixed 24 dp.

§1 — MinSize::new call sites

29 production sites. Every one is a hit-area or control-height floor; each becomes density_min_size(base, axes, &tokens) under P20, except the three marked Decoration.

Excluded and why: crates/teksilo-widgets/src/button.rs:1287, :1288, crates/teksilo-widgets/src/popover_widget.rs:907, crates/teksilo-widgets/src/primitives/min_size.rs:226, :238, crates/teksilo-widgets/src/scroll_bar.rs:868 (inline #[cfg(test)] modules); crates/teksilo-widgets/src/combo_box/tests.rs:1167, :1201, crates/teksilo-widgets/src/layout_integration_tests.rs:138 (test files); crates/teksilo-widgets/src/primitives/min_size.rs:22, crates/teksilo-widgets/src/scroll_area.rs:25 (doc comments). One further production site lives outside the crates tree, in examples/widget_catalog/src/tabs/layout.rs:244.

§2 — the 39 default recipes

Every themable widget's Compact dimensions are module constants in its recipe_*_style.rs. Under P20 each Recipe*Style gains for_tokens(&InputTokens) -> Self; Default stays and equals for_tokens(&InputTokens::for_density(Compact)), so these values are the Compact column by construction.

Exactly one recipe carries a min_size field: recipe_button_style.rs, on ButtonRecipe, set to Size::new(72.0, 24.0) by all three variant constructors (lines 267, 298, 325) and consumed at line 141. Every other recipe expresses its target as a bare height/size constant, which is why P20 cannot go through min_size alone.

§2.1 — fields per recipe

Five recipes carry no dimension constant of their own: recipe_grid_view_style.rs (colours + a focus-ring width described in prose only), recipe_list_container_style.rs (surface fill only), recipe_rich_text_editor_style.rs and recipe_spin_box_style.rs (both re-export recipe_text_input_style as field_dims and reuse TEXT_FIELD_*), and recipe_split_button_style.rs (reuses the SPLIT_BUTTON_* constants that live in split_button.rs, §3a).

§2.2 — every recipe constant

§3 — widget-module constants outside styles/

§3a — pub const … : f32 (53 rows, 50 of them dimensions)

§3b — private const … : f32 (113 rows)

Not public API, but P20 had to reach them anyway: this is where the splitter gutter, the dock gutter, all five SCROLLBAR_THICKNESS copies, the five duplicated EDGE / MAX_VELOCITY auto-scroll pairs and the text-drag threshold lived.

The five auto-scroll copies are gone. ListView, TreeView, TableView, TreeTableView, GridView's marquee and the TabBar strip each carried their own EDGE = 32.0 / MAX_VELOCITY = 12.0 and their own copy of the ramp; all six now call common::drag_autoscroll. Its band_for(PointerKind) is the reason the constants left this table rather than gaining a density route: the edge band is a property of the device — a cursor lands where it is put, a fingertip's reported centre wanders — so it widens for a coarse pointer (32 → 64 dp) and is unchanged for a precise one. It does not move with TargetDensity, which describes how big the UI's targets are. The velocity cap is a rate, not a dimension, and is the same everywhere.

The activity rail's gaps are fixed, and that is a decision, not an omission. RAIL_ITEM_SPACING and RAIL_PADDING are read by three co-dependent computations: the rail's layout (VStack::spacing, Padding::uniform), its overflow-capacity estimate (item_stride → shown_capacity) and its drop-insertion geometry (rail_insertion). Two of those are pure functions with their own unit tests and no theme in scope. Scaling the layout without the capacity estimate would make the rail show more items than fit; threading tokens through the pure pair would rewrite assertions this package is not allowed to touch. The rail's touch conformance comes from its items — DockRailItemSize resolves through IconButtonRecipe, which is target_size-routed — not from the gaps between them. Owner for any future change: P30.

§4 — theme presets and the previewer UI

teksilo-theme-fluent, teksilo-theme-macos and teksilo-theme-material3 install their own Tier-3 styles with their own constants, so P20's projection has to reach them or a preset silently stays Compact under Touch. teksilo-preview-ui is included because its navigator rows (22 / 28 dp) are the smallest interactive rows in the workspace.

How a preset re-projects. Each preset's *_style() metric factory gained a *_style_for(&InputTokens) twin, and the zero-argument original is now defined as the Compact call — so no existing caller or test changed, and install_styles reads theme.input. Each preset then registers a teksilo_core::styles::DensityProjection in its theme extensions; Theme::with_density calls it, and the preset rebuilds its own slots against the new tokens while colours, id, palette extension and any slot the app installed ride across untouched. Its own tests assert this (a_density_switch_re_derives_the_installed_slots).

The three presets do not share a ladder. Material 3 keeps its published 48 dp touch target (material3::input_tokens), so an M3 button is 40 dp at Compact and 48 dp at Touch, not 44. Fluent has no published touch ladder — WinUI's 40 px / 7.5 mm is a recommendation, not a metric its controls scale by — so it uses the generic one. macOS has none at all (there is no macOS touchscreen), so it uses the generic one too, and its [unpublished] 22 dp control height and [measured] 14 dp glyph controls stay at Apple's numbers in the paint at every density: growing them would falsify a preset whose whole purpose is to reproduce those numbers. What rises on macOS is the minimum hit box around a control — the two MinSize sites in §1.