# Vendored Taffy — Exact patches

- **Upstream:** `taffy` 0.14.0, crates.io package supplied offline at
  `~/Library/Caches/exact2-textflow/taffy-0.14.0/` (M8, 2026-09-18).
  The archive's `.cargo_vcs_info.json` pins commit `77f385683c1d698c91a23a259f87fdddf26925fb`.
- **Why vendored:** patches 3, 4, 5, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70 and 71 below remain. `[patch.crates-io]`
  selects this copy; the kernel declares `taffy = "0.14"`.
- **Owner:** Charlie Cheever (kernel/layout).
- **Features:** std, taffy_tree, flexbox, grid, block_layout, content_size, calc.
  `BlockContext` belongs to block_layout; float_layout is unnecessary and
  disabled. No float row is exposed. Upstream's other newly default features
  (flexbox_balance, detailed_layout_info) are unnecessary here too.
- **Replacement plan:** upstream the remaining fixes; remove each divergence
  when a published version provides it. The numbered inventory retains the
  history so a refresh cannot silently lose an Exact correction.

The original patch descriptions refer to the supplied, unmodified 0.14.0
source. The dated upstream audit below separately records current upstream work. The package's source is copied in full; examples,
Cargo.lock, Cargo.toml.orig and packaging receipts are omitted as before.

## Upstream submission audit, 2026-10-02

Initial coverage audit: DioxusLabs/taffy main `fb461a7826e49f488f31220744bf12227ffb580e`.
The final ratio submission also integrates main `22f941e19e05d1b29621703b4f3a9d96d7839886`.
The vendored implementation is unchanged; a merged upstream change is not yet
available to Exact until its dependency is refreshed and checked.

| Patch | Current upstream coverage |
| --- | --- |
| 10 | Block percentage padding was merged in [#1187](https://github.com/DioxusLabs/taffy/pull/1187). The remaining two flex paths are merged in [#1209](https://github.com/DioxusLabs/taffy/pull/1209), by `ccheever`; 16 new Chrome-generated variants, eight failing before the fix. |
| 11 | Missing sizing-mode and margin-collapse cache inputs are submitted in [#1210](https://github.com/DioxusLabs/taffy/pull/1210), by `ccheever`; three restyle regressions fail before the fix. The original percentage-parent-height regression already passes current main and is retained as a control, so no additional parent-height key change was submitted. |
| 12 | Submitted as [#1213](https://github.com/DioxusLabs/taffy/pull/1213), by `ccheever`, with 500 new Chrome-derived variants. Shared ratio resolution covers block/flex/grid/absolute/root paths, min/max transfer, content minima, percentage bases and content-box ratio semantics. Includes #1210 as a prerequisite and explicitly credits/reconciles overlaps with [#1184](https://github.com/DioxusLabs/taffy/pull/1184) (`l7aromeo`) and [#1081](https://github.com/DioxusLabs/taffy/pull/1081), [#1098](https://github.com/DioxusLabs/taffy/pull/1098), [#1157](https://github.com/DioxusLabs/taffy/pull/1157) (`nicoburns`). |
| 14 | Negative-margin contribution fixes are already submitted in [#1165](https://github.com/DioxusLabs/taffy/pull/1165) and its dependent [#1166](https://github.com/DioxusLabs/taffy/pull/1166), by `nicoburns`. The earlier [#1164](https://github.com/DioxusLabs/taffy/pull/1164) is merged. Of 32 Chrome variants, eight fail current main and all pass at #1166 head `6c6fcb15a80d58c2ce9f38139e6780df79b86dea`. |
| 17 | The absolute-inset half is merged in [#1203](https://github.com/DioxusLabs/taffy/pull/1203). Replaced grid alignment is submitted in [#1158](https://github.com/DioxusLabs/taffy/pull/1158), by `nicoburns`, on top of #1157. The three natural-size grid probes fail on current main and pass at #1158's head. Ratio sizing remains tracked with patch 12. |
| 18 | The shared out-of-flow solver and hoisting are merged in [#1194](https://github.com/DioxusLabs/taffy/pull/1194); the auto-margin inset condition is merged in [#1202](https://github.com/DioxusLabs/taffy/pull/1202). Negative block-axis auto margins and inset/static-position shrink-to-fit are covered by existing [#1206](https://github.com/DioxusLabs/taffy/pull/1206), by `nicoburns`. Ratio semantics remain tracked with patch 12. |
| 20 | Static positioning and containing-block hoisting are merged in [#1140](https://github.com/DioxusLabs/taffy/pull/1140) and #1194. Existing #1206 covers the remaining RTL static shrink-to-fit cases. Upstream owns the hoist record internally, so Exact's caller-maintained record/replay API is not proposed upstream. |

Fresh coverage audit: 528 preserved Chrome XML probes of negative margins,
absolute boxes, and static containing blocks pass 480/528 on current main.
Applying #1206's source (`b0a6a1b3ec5447810184cd7103d140d843af381d`)
passes 520/528; the remaining eight are the negative-margin cases for patch 14.
This excludes ratio cases from the claimed coverage. No duplicate PRs or
comments were sent to the authors of existing work.

The final ratio submission is `da1fac00a19f2fb366c198f7ab16aa6ceac14785`:
6,978 committed tests pass, four ignored (6,693 XML, 153 unit, 127 handwritten,
five doctests). A broader audit passed 7,925 XML cases. Its 500 new XML variants
come from 125 HTML fixtures; natural-ratio choice remains with the host, while
`aspect_ratio_content_box` declares the chosen ratio's sizing box. Formatting,
feature checks, gentest compilation, clippy (existing warnings only), and an
independent exact-commit review passed. The authorized seven-round final pass
resolved the earlier block, grid, absolute and column-flex regressions without
changing browser expectations. See the completed submission record in
`issues/closed/20260930-taffy-patches-not-sent-upstream.md`.
The submission itself changes no vendored code; other ticket fixes below are
recorded separately. Refreshing the vendor after upstream merges is still owed.

## Patch 1: used cross sizes and intrinsic cache entries — upstream

`src/compute/flexbox.rs::determine_flex_base_size` clamps
`child_known_dimensions` using `transferred_min_size`/`transferred_max_size`
before measuring the flex basis. `src/tree/cache.rs::CacheKey` encodes
known dimensions/available space, parent size and definiteness;
`Cache::get(&LayoutInput)` compares keys, never promotes a result's size
into an input dimension. Both parts of the old patch are therefore removed.

The 24 literal-Chrome reader cases in `kernel/tests/it/reader.rs` retain their
expectations, including both width spellings, both box-sizing modes and the
long-token overflow case. Incremental/fresh/rehydrated reader equality stays.

## Patch 2: first baseline from measured leaves — upstream API, kernel adapter

`src/tree/taffy_tree.rs::compute_layout_with_measure` now accepts
`FnMut(LayoutInput, NodeId, Option<&mut NodeContext>, &Style) -> LayoutOutput`.
`LayoutOutput.baselines` is `Baselines { first, last }`. The kernel calls
upstream's `compute_leaf_layout` for the ordinary size rules, captures the
host's first baseline, adds top border/padding, and writes `output.baselines`.
The custom MeasureOutput type and additive baseline entry points disappear.
No vendor baseline patch is needed. Region baseline-dependency regressions
and the 512-tree fresh-layout comparison remain consumers.

The style adapter lowers CSS `normal`, the alignment rows' default, to None
on every display (2026-09-23; before, only an implicit block align-content).
0.14's block algorithm establishes a BFC for Some(align-content), so a
stretch default carried into blocks would stop nested margins collapsing.
`default_block_alignment_preserves_nested_collapsed_margins`
pins 151px for both nested border tops, rather than the incorrect 211px
paragraph top. Authored block alignment establishes the BFC, as CSS says.
`measured_baselines_include_padding_and_inherited_direction_relayouts_boxes`
checks a literal padded baseline and inherited RTL placement/replay.

## Patch 3: allocation-free unfrozen set — re-applied

`src/compute/flexbox.rs::resolve_flexible_lengths` still collects a
`Vec<&mut FlexItem>` in upstream. Retain lazy forward iteration at every use.
Order and floating-point accumulation order are unchanged. Each item only
mutates its own frozen flag, so lazy filtering selects the same set.

## Patch 4: pooled FlexItem scratch buffer — re-applied

Upstream `generate_anonymous_flex_items` still returns a fresh Vec. Retain
the caller-supplied buffer and thread-local stack of at most 32 buffers.
The iterator body is upstream 0.14's, including its new definiteness logic.
Buffers are cleared before reuse; capacity is the only retained state.
More than 32 concurrent/returned buffers fall back to allocation/drop;
no_std retains upstream's allocate-per-container behavior. FlexLine allocation
remains unchanged. The 512-tree regression checks cached versus fresh layouts.

## Patch 5: replaced-element ratio constraints and overflow — re-applied

`src/compute/leaf.rs` still independently clamps axes and then floors height
from the ratio; ContentSize still discards the ratio. Port the CSS 2.1 §10.4
`replaced_constraints` table and retain the ratio in ContentSize. Retain the
replaced-element overflow correction, now expressed as
`scrollable_overflow_rect` covering the used padding box. Natural bitmap size
must not enlarge an explicitly sized image's scrollable extent.

`kernel/tests/it/image.rs` covers the constraint table and stretching flex column;
`review_fixes.rs` covers intrinsic item contributions. The new upstream block
algorithm itself respects an image's natural width: the former declared
block-stretch deviation no longer exists.

## Patch 6: intrinsic items exclude their container's inset — upstream

`src/compute/flexbox.rs::determine_container_main_size` adds the container's
inset after the item contributions. Neither item contribution is floored by
`main_content_box_inset`; the two old deletions need no port.
`intrinsic_flex_items_do_not_include_their_containers_padding` is unchanged.

## Patch 7: final-measure height proof — dropped, replaced by upstream input

The full LayoutInput above supplies run_mode, known_dimensions, parent_size
and sizing_mode. The kernel records the effective height proof separately;
upstream `compute_leaf_layout` preserves the ordinary callback contract:
ComputeSize receives border-box known dimensions, PerformLayout receives
Size::NONE. No proof metadata influences ordinary returned metrics.
`upstream_leaf_keeps_border_box_compute_size_inputs` keeps the 400px offer
for a 300px content-box text leaf with 50px side padding.

The old emulated-callback differential is removed. There were no recorded
old-frame fixture files. Its 512 seeded trees now compare incremental against
fresh 0.14 layouts (49,152 node layouts, including overflow and insets).
Literal browser fixtures, not two copies of the old callback, remain the
behavior oracle. The measurement-count assertion is the negative control.

## Patch 8: the automatic minimum is measured only where used — upstream

**Original implementer:** Claude (Fable 5.1), 2026-09-19, owner commit
`9d282bcd` (patch 7 on trunk's 0.9.2). Reconciled with 0.14 in M15.

The supplied upstream 0.14.0 `src/compute/flexbox.rs`,
`determine_flex_base_size`, already uses
`style_min_main_size.unwrap_or_else(|| { ... measure_child_size ... })`.
The option includes an authored minimum or the scroll container's zero
`Overflow::maybe_into_automatic_min_size`. Its closure therefore runs only
when the automatic minimum actually needs min-content. No port or additional
vendor source change is needed: **zero lines** beyond retained patches 3–5.

The owner's rationale still applies: 0.9.2's eager `unwrap_or` discarded
this measurement when a minimum was already known. A flex reader list laid
out its entire mounted content at zero width on every window change, evicting
row layouts before measuring again at the real width. His 2.3 MB document,
three seconds at 3,600 px/s, went from 59,682 to 614 measure calls, unchanged
row calls 57,793 to 9, and CoreText measurements 694 to 455. These are his
0.9.2 measurements, not a new 0.14 timing claim.

**Held by** his unchanged `kernel/tests/it/reader.rs` regression
`a_scroller_in_a_flex_row_is_not_probed_for_a_minimum_it_does_not_use`
(only 628px text offers; 5974px column), and the two adjacent intrinsic-cache
regressions, now with an ordinary non-scrolling box that requires the probe.
His `text_measurement_cache.rs::a_padded_text_that_flexes_wraps_in_its_content_box`
also retains its 260px border box / 244px content box / 56px height assertions.
The 0.14 kernel adapter now takes both text offers from content space while
keeping `LayoutInput`'s independent height proof and `LayoutOutput` baselines.

The owner's 0.9.2 upstream suite report was 2,181 passed, 6 failed, 4 ignored
both with and without his patch. Those results are historical, not results
for this 0.14 package. M15 validation: all 8 tests in the owner's reader and
text-measurement-cache suites pass with their expectations unchanged; the
source-identical 0.14 scratch copy passes 130 unit tests and 5 doctests using
M8's offline setup (unused uncached roxmltree dev dependency omitted).
The generated browser conformance corpus is absent from the supplied package.

## Changed expectations in the upgrade

- `image.rs`: auto-width block image 390×146.25 becomes intrinsic 320×120,
  as CSS replaced-element sizing requires. The old test explicitly pinned a
  deviation; the replacement tests its removal.
- `reader.rs`: remove the requirement to execute a 1716px MinContent probe.
  0.14 avoids that probe. The final 628px offer/468px measured height,
  5974px column and no-remeasurement cache assertion are unchanged.
- `reader.rs`: column's propagated horizontal overflow 1278 becomes 1246
  (32px start padding + 14px child inset + 1200px word). Upstream's
  `compute/common/scrollable_overflow.rs` and flexbox final layout implement
  CSS Overflow's end-padding contribution only for scroll containers. The
  prior value added 32px end padding to an overflow-visible column; the
  literal HTML fixture never recorded this value. Its 24 browser-backed
  geometry/scroll-height cases all remain unchanged. Chrome confirmation of
  this horizontal extent is owed outside the sandbox.

## M8 Part B investigation — no new patch shipped

`BlockContext` exists without float_layout, but its private `y_offset` and
`insets` are provisional, not always the final child border-box origin.
An instrumented source copy under ignored `target/textflow-scratch/m8/`
ran these cases; it is not linked into Exact:

- A 50px preceding block with 40px bottom margin followed by a paragraph
  with 10px top margin: context y=100, final y=90.
- The same paragraph at width 100 in a 200px parent, with auto side margins:
  context x=0, final x=50.
- A scratch correction uses the collapsed sibling margin and resolved auto
  side margins. These two cases pass, but a nested block with 60px top
  margin and first paragraph with 100px top margin still measures at y=110
  and is ultimately placed at y=150 (the paragraph is at local y=0).

`compute/block.rs::perform_final_layout` calls the child before it knows
`item_layout.top_margin`, then resolves `y_margin_offset` and final location.
It also resolves relative insets after measurement. Forwarding this context
alone is therefore insufficient for the requested arbitrary block parent
chain. A sound continuation needs settled margin-strut/position semantics
and the wrapping context's identity within the BFC, as well as the leaf
callback parameter and cache treatment. No relayout loop or partial offset
API was introduced. The Part B vendor diff is **zero lines**.

Auto-height exclusions landed later without any vendor change (LLP 1043.000
§8, "Stage 2"): the kernel restricts them to block contexts, where a leaf's
offset depends only on preceding content, and re-lays out to a verified fixed
point instead of reading `BlockContext` at measure time. Still zero lines here.

## M8 validation and handoff

All Cargo commands ran offline with EXACT_UPDATE_TRUST=development. Bun's
frozen offline install passed. Exact's public measure API and native ABI are
unchanged; this is an engine adapter change, not a new exclusion interface.

The five checks on the final source:

| Check | Result |
| --- | --- |
| cargo build --workspace --offline | Pass, 377.817s |
| cargo test --workspace --no-fail-fast --offline, three allowed exclusions | Fail: results below |
| cargo clippy --workspace --offline --all-targets -- -D warnings; cargo fmt --all -- --check | Both pass |
| bun scripts/caps.mjs | Pass: 715 source files, 93 vendored files excluded |
| bun scripts/boot.mjs | Pass: 2 modules, 1 wasm reference, 138248 reachable JS bytes |

The final workspace suite, with the brief's three exclusions (exact-js,
exact-js-bake, exact-js-web), completed in 2670.502s: **1632 passed, 2 failed,
9 ignored, 283 targets**. It is not a green workspace result:

- Apple `fresh_preparation_reads_platform_secrets_and_defers_effects_until_commit`
  fails at abi_tests.rs:260 because Keychain returns Operation not permitted.
- Linux `full_undrained_session_does_not_block_another_sessions_native_workers`
  fails at image/control_tests.rs:180: delivery_cells is 1 instead of 0.
  It passed the first workspace run; two isolated retries failed too (2 and 1
  cells). Stop after those three failures. The test and worker implementation
  are untouched, and its fixture does not compute layout. This remains an
  investigation for the orchestrator, not a claimed resolved flake.

The first workspace suite had 1632 passes and only the Keychain failure,
before the final block-default regression test was added. An earlier focused
host run also hit Apple's process-wide worker cap in
`byte_budget_and_illegal_opt_ins_refuse_before_transport`; it passed alone
and did not recur in either workspace suite.

Additional results:

- Kernel: 242 passed. All 24 literal-Chrome reader cases, the 512-tree
  differential, layout equality, scrolling/list and review fixes pass.
- Textflow app: all 9 Linux tests and the data test pass; the all-scenes
  larger-font/shape-avoidance test also passes in release mode.
- Available Taffy tests: 130 unit tests and 5 doctests pass in a source-identical
  scratch copy, before offset instrumentation. Its unused roxmltree dev dependency
  was omitted because that version is not cached. Generated upstream browser
  conformance fixtures are absent from the supplied package and were not run.
- Web glue: 21 tests pass. `bun host/web/build.mjs textflow-web` passes.
- `bun host/apple/build.mjs --app textflow` passes with the supplied Swift shim
  first on PATH. Swift XCTest: 159 of 163 tests pass; ten assertions fail in the
  same four untouched MacShortcut/MacToolbar window/sheet tests recorded by M9.
- Release Linux screenshots: all six scenes, 100% and 115%, at 960x900 and
  clock zero, captured and visually inspected. Every 100% image is pixel-identical
  to the requested M9 reference; all twelve match the debug captures. Explicit
  EXACT_PAINTER=cpu is required here: default GPU discovery never became ready
  in three attempts (including a 120s probe).

The 10,000-ordinary-leaf test still checks no unchanged remeasurement and
at most eight measurements after the small side context's exclusion moves.
The 2,000-paragraph/32-exclusion stress case checks 64,000 candidate leaf visits
per pass. This upgrade adds no exclusion traversal or relayout loop. Patch 4
retains at most 32 scratch buffers per thread; excess buffers are dropped,
with capacities proportional to encountered container sizes. The padded
baseline and explicit block-BFC cases are additional negative controls.

Logs, timing samples, offset probes, and inspected linux-cpu-*.png captures
are under target/textflow-scratch/m8/. Outside the sandbox, rerun the full
workspace suite including the three JS packages, the Swift suite, and drive
all six scenes in macOS and Chrome at both font sizes. Confirm reader.html's
horizontal overflow interpretation in Chrome. B/C remain pending; no seventh
scene or fixed-height-slack removal has been claimed. QUEUE.md also records
LLP 1001's now-obsolete block-image deviation for a governing-doc follow-up.

### Layout timings

Five paired serial runs of the existing kernel flow tests, alternating the
retained pre-upgrade executable and final 0.14 executable, after local builds
finished. One warm-up per executable is excluded; no measured sample is dropped.
Medians are milliseconds, not per-frame numbers:

| Existing workload | 0.9.2 + seven patches | 0.14 + retained patches |
| --- | ---: | ---: |
| 10,000 ordinary leaves, 30 cached passes | 53.126 | 52.980 |
| Same plus a small side wrapping context | 51.701 | 53.537 |
| 2,000 paragraphs, 10 passes, no exclusions | 3.253 | 3.546 |
| Same with 32 exclusions and one moving source | 453.706 | 477.922 |

Moving-exclusion medians are 5.3% slower in this sample; ranges overlap
(old 442.864–504.126ms, new 458.443–621.273ms). The loaded shared machine
also produced one failed 5% side-context timing gate: new run 3 measured
75.123ms plain versus 172.381ms with the small context. All five old runs and
the other four new runs passed all eight tests. The failure is retained in
paired-final-new-3.log and paired-final-timings.json. Earlier samples during
builds varied substantially too. No speedup or resolved performance result is
claimed: rerun the unchanged timing gate and paired comparison on an idle
machine. The measure-count and sparse-work assertions remain unchanged.

## Updating this copy

Reconcile every `EXACT PATCH` marker with this inventory, compare against the
selected upstream package, and run the available upstream tests and Exact's
checks. Each remaining patch carries at least one marker, and there are no
patches 22 to 24. The crates.io package does not include the generated browser
conformance corpus. Do not describe those absent fixtures as tested.

## Patch 9: sparse layout writes and caller-proven boundary replay (S6)

`tree/taffy_tree.rs` records changed unrounded layouts at their existing write
seam. `take_layout_changes` transfers those node identities to the kernel;
the sparse journal deduplicates repeated writes and removes destroyed identities,
so nonpublishing region trials retain at most one entry per live node. A dense
journal plus sparse positions makes both draining and removal proportional to
changed entries, without scanning a prior large hash-table capacity. No layout
algorithm, cache key, root sizing rule or rounding behavior changes.

A sparse opt-in map retains, for candidate boundaries only, the exact final
`LayoutInput` and `LayoutOutput` and whether an ancestor could have consumed
any other content-dependent answer since it was last invalidated through the
node: a `ComputeSize` without both known dimensions (or a known width on the
horizontal axis: every algorithm's short-circuit answers those from the query
alone), or a `PerformLayout` under other inputs. Recording is at the
`cache_store` seam, which every miss passes, and a hit returns an entry stored
under the same known dimensions, so the record is complete. A full
`mark_dirty` through the node starts a new record, since every ancestor that
asked it anything is invalidated with it; a hidden layout's `cache_clear`
drops the saved inputs. `last_layout_input` answers only while nothing else
was consumed. `mark_dirty_to` clears the dirty path through that boundary;
`compute_boundary_with_measure` replays the same input through Taffy's
ordinary child-layout algorithm, retaining the parent-assigned location and
updating the box's own overflow. `set_style_unmarked` and
`set_children_unmarked` (children detached or already the parent's) change
the tree without invalidating it, for a caller that marks the node dirty,
either way, before any layout. This is one serial Taffy owner, without a
second engine or a continuation/pending-layout API. Callers must establish an
independent formatting context and invalidate ancestors when its output changes.

The kernel defers style, child-list and text invalidation to the next layout
and then admits, as a boundary for each change, the nearest box at or above it
(strictly above a restyled one) that clips both axes, is in flow, is not
restyled or dirty, and has a replayable record, under no hidden ancestor and
an unchanged definite viewport. Flex, grid, percentage and auto sizing need no
rule of their own: the record says whether the ancestors asked. Every
ordinary invalidation walks before any local one, so none stops at a box a
local walk cleared. A changed size, collapsed-margin or baseline output
propagates normally, except that a flex column's non-startmost item's
baselines are unread (CSS Flexbox §8.5 and §9.4: the column aligns no item by
baseline and takes its own from its startmost item). Clipped internal overflow
publishes on the boundary. Exclusions, changed offers, a dirty root and
nested boundaries take the normal root path. A virtualized list (`flex: 1`,
`min-height: 0`, `width: 100%` under a column) is such a boundary for its
window changes, row measurement, inserts and removes.

A change confined to absolutely positioned boxes (2026-10-18,
`kernel/src/layout/absolute.rs`) replays at their containing block when it is
a positioned flex or grid container: one only gaining or losing absolutely
positioned children, or anything inside such a child. Positioned boxes keep a
record too, and `saved_layout` answers it whatever the ancestors asked, since
none of their answers (intrinsic sizes, baselines) reads an absolutely
positioned child; the block's overflow reaches them, so the replay compares
how far it reaches past the border box. A block container is never such a
boundary: margins collapse through it. A source under another root laid out
before waits for that root's pass instead of dirtying its whole path in the
first root's (unless the hoists moved), so a host that lays out several roots
keeps either kind of boundary. `layout::absolute_tests` holds a step
strip's playhead dot local and its coupled cases at the root, and 3,000 seeds
of each `layout_equality` differential (about 99,000 replays) showed no
divergence.

Kernel publication follows sparse ancestor paths in document order and descends
where absolute origins move. Per-root publication generations expire old geometry
flags without a sweep. Apple accumulates the resulting publication candidates
through silent list passes, including overflow-only changes, before comparing
against its presenter mirror. Region/exclusion publication retains its existing
conservative traversal.

Regressions in `kernel::locality_tests` compare all frames and overflow bitwise
with a fresh engine, assert one measure and three publication visits among 100
and 2,000 unrelated siblings, and exercise negative dependencies, mixed dirty
sources, changed viewports and reparenting. `layout::containment_tests` holds
the list shape local and its coupled cases (first item, content-sized, header,
restyled) at the root; `layout_equality`'s random trees gain clipping boxes and
a list-shaped differential of clipping panes, each round compared with a
rehydrated and a replayed kernel, frames and scroll extents. Over 1,500 seeds
of both (about 14,000 contained replays) this patch adds no divergence: the
four seeds that differ also differ on the prior tip; patch 11 fixes all four. Apple layout tests cover silent
settlement and inherited spelling hints on unmoved editors. Existing layout,
reader, exclusion, region and upstream differential expectations are unchanged.

## Patch 10: percentage padding and border resolve against the inline size — to upstream

**Implementer:** Claude, 2026-09-23 (found by the 2026-09-22 kernel review).

`src/compute/block.rs::generate_item_list` resolved each child's padding and
border with `resolve_or_zero(node_inner_size, …)`, a `Size` basis, so the top
and bottom sides resolved against the container's inner *height*. CSS Box
Model 3 §4 (CSS 2.1 §8.4) resolves percentage padding, and Taffy's
percentage border, against the containing block's inline size on every side,
as the item's own layout (`parent_size.width`) and the flex and grid item
paths already do. The wrong basis fed the item's `box_sizing_adjustment` and
`padding_border_sum`: a content-box `height: 50px; padding-top: 5%` child of
a 400px-wide auto-height block was 50px tall (Chrome 153: 70px), and under a
300px-tall parent `height: 10px; padding: 5% 0 10%` was 60px (Chrome: 70px).
`src/compute/flexbox.rs::determine_used_cross_size` had the same basis in the
content-box adjustment of a stretched item's maximum cross size (a 400×300
row, `max-height: 50px; padding-top: 10%`: 80px, Chrome: 90px). Both sites
now pass `.width`; nothing else changes.

Upstream wants the two-line fix and a gentest per site in its HTML fixture
format; the cases above are that fixture's content. Held by
`kernel/tests/it/browser_cases.rs::percentage_padding_resolves_against_the_containing_block_width`:
nine literal-Chrome cases, including the `padding-top: 56.25%` embed idiom,
which a zero `height` already kept right (only the box's own padding
counts then). Taffy's 130 unit tests pass on the patched source (a scratch
copy without the uncached roxmltree dev-dependency, as in M8).

## Patch 11: the layout cache is keyed on every layout input — to upstream

**Implementer:** Claude, 2026-09-25 (found by `layout_equality`'s seeds).

`src/tree/cache.rs::CacheKey` left three inputs out of the key under which it
reuses a result, so an entry computed under one input answered another:

- `vertical_margins_are_collapsible`. Whether the node sits in its parent's
  block formatting context decides whether a first or last child's margin
  collapses through it (CSS 2.1 §8.3.1), and so its size, its children's
  positions and the margins it reports. A block parent that turns flex or grid
  reused its child's final layout with the inner margin still collapsed through
  it (`run(2423214, 14)`: a 4.5-point margin in the wrong place).
- `sizing_mode`. `InherentSize` applies the node's own size, min and max
  styles; `ContentSize` ignores them. Flex asks `ContentSize` (flex basis,
  final layout); block and grid ask `InherentSize`, with the same known
  dimensions (`run_panes(1412, 40)`: a 58-point styled width answered a
  110-point basis probe).
- The parent's height, for measurements. `ComputeSize` lookups compared only
  the parent's width, but a node resolves its own percentage height against the
  parent's height (CSS 2.1 §10.5): `height: 86%` measured under a 62-point
  parent answered once the parent's height was auto (`run_panes(503, 40)`;
  `run_panes(405, 40)` is the same through `sizing_mode` too).
  Final-layout entries already compared the whole parent size.

The key now carries the two fields, and a measurement matches on everything but
the requested axis. The alternative, clearing a child's cache when its parent's
display changes, is not correct in general: the cache memoizes a function of the
node's subtree, which its own dirty flag covers, and of its `LayoutInput`, which
only the key covers. One unchanged block parent asks the same child under both
flag values (it measures every child's width with collapsible margins, then lays
a flex, grid or scrolling child out without), and a parent's height or sizing
mode changes without its display changing. Keying costs only hits between
genuinely different inputs.

**Upstream fixture** (`cache.rs` tests): three key tests, one per omitted input,
and three trees laid out, restyled and laid out again against a fresh tree:
block to flex and block to grid (margin collapse; grid differs from the block
only in the flag), and a block losing its height under a percentage-height flex
child. All six fail on the unpatched source and pass patched; Taffy's 135 unit
tests and 5 doctests pass (scratch copy without roxmltree, as in M8).

**Held by** `kernel/tests/it/layout_equality.rs`: `seed_2423214_…`,
`pane_seed_405_…`, `pane_seed_503_…` and `pane_seed_1412_…`, each failing before.
Seeds 1–10,000 of `run` and of `run_panes` (40 rounds) differed from a fresh
layout 21 and 16 times before and 0 times after; the 512-tree differential
passes before and after.

## Patch 12: sizing through `aspect-ratio` as CSS does — to upstream

**Implementer:** Claude (Opus 5.5), 2026-09-25, for LLP 1053 G1.

Upstream applies a ratio by `Size::maybe_apply_aspect_ratio` wherever a size,
min or max is resolved, in the box-sizing box, into any unset axis. Patch 5's
leaf then treated every leaf with a ratio as a replaced element and resolved
it by CSS 2.1 §10.4's table. Against Chrome 154 that is wrong in five ways:

- **A non-replaced box is not replaced.** A text leaf or empty box with
  `width: 200px; max-height: 50px; aspect-ratio: 1` is 200×50, not 50×50.
- **Min/max transfer only into an unsized axis.** A `max-height` becomes a max
  width for a stretched block (100×100 from `aspect-ratio: 1; max-height:
  100px`), never for a set width. The same holds for images: `width: 96px;
  max-height: 20px` on a 320×120 image is 96×20. The §10.4 table is for
  neither dimension set.
- **The derived block size is a floor.** For a box that is neither replaced
  nor a scroll container and whose `min-height` is `auto` (CSS Box Sizing 4
  §5.2), taller content grows it: `width: 20px; aspect-ratio: 1` holding five
  lines is 90 tall, not 20. `min-height: 0`, `overflow: hidden` or a
  `max-height` still hold it.
- **The ratio's box.** `auto <ratio>` and an image's natural ratio relate
  content-box sizes even under `box-sizing: border-box`.
- **A provisional stretch is not definite.** Flex measured a ratio item's
  base size, and its automatic minimum, under the stretched cross size of an
  indefinite container: `flex-grow: 1; aspect-ratio: 2` in a 400px row laid
  out at 1200×600 under a 600px-tall offer.

The fix is one module, `src/compute/ratio.rs`, plus its call sites.
`Ratio::resolve` takes a box's given border-box sizes and authored min/max,
and returns its size, min and max:
- min/max transferred into unsized axes;
- one given axis clamped, the other derived from it;
- a floored derived height becomes a minimum instead of a size.

`Style::aspect_ratio_content_box` (with `CoreStyle::aspect_ratio_content_box`)
carries the box. The call sites are:
- `leaf.rs`: sizes through `Ratio`, keeps the §10.4 table only for a
  replaced element with neither dimension given, and derives a
  content-sized box's height from its width.
- `block.rs`: the entry size, the item sizes and the container's
  known-dimension transfer.
- `flexbox.rs`: the item size; min/max transfer only into axes the item
  does not size (`transfer_into_unsized`); the base-size and automatic-minimum
  measurements drop a provisional stretched cross size for ratio items.

**Extended 2026-09-30 (Claude, Fable 5.1, for LLP 1074 T2)** to the paths the
first tranche left on upstream's `maybe_apply_aspect_ratio`:
- a flex and a grid container's own size, min and max (`flexbox.rs`
  `compute_flexbox_layout` and `compute_constants`; `grid/mod.rs`);
- a grid container's parent-assigned dimensions also feed the ratio (2026-10-02):
  an item stretched to 100px during intrinsic track measurement keeps its 1:1
  height floor even with an unresolved `height:100%`. The container's ratio floor
  cannot prematurely become that item's percentage basis. Three literal-Chrome
  cases in `browser_position.tsv` hold ratio, definite-height and auto parents;
- grid items, in `grid/alignment.rs::align_and_position_item`, in
  `GridItem::known_dimensions` and in `GridItem::minimum_contribution`, where a
  minimum only the ratio gives (a transferred one, or the floor a derived
  height is) holds beside the automatic minimum, never in its place. The item
  keeps the ratio's box and whether its height floors
  (`aspect_ratio_content_box`, `ratio_floors_height`), and `Ratio::from_parts`
  and `resolve_through` serve an algorithm that holds the parts, not the style;
- absolutely positioned boxes (patch 18) and the root (patch 19).

Completed 2026-09-30: the automatic minimum of a width derived from a definite
height, and percentage resolution against the preferred ratio height even
when the content minimum enlarges the used box. The five `OWED` cases were
removed; new Chrome fixtures cover overflowing percentage children, inline
minima, explicit min/max bounds, scroll-container opt-outs and absolute roots.

**Held by** `kernel/tests/it/browser_ratio.rs`: 60 literal-Chrome cases.
`image.rs` and `video.rs` each change one expectation to Chrome's: a set width
stays when `max-height` clamps the ratio's height. Taffy's 136 unit tests and
5 doctests pass on a scratch copy without roxmltree. The 512-tree differential
passes.

## Patch 13: `TaffyTree` resolves `calc()` through a caller's function

**Implementer:** Claude, 2026-09-24 (the iOS Messages port's
`calc(100% - 89px)`).

Upstream's `calc` feature stores a `calc()` length as an opaque pointer and
asks the tree for its value through `LayoutPartialTree::resolve_calc_value`,
but `TaffyTree`'s own implementation (`src/tree/taffy_tree.rs`, on
`TaffyView`) is a stub returning `0.0`: only a custom tree can resolve one.
`TaffyTree` gains a `calc_resolver: fn(*const (), f32) -> f32` field,
`|_, _| 0.0` by default, a `set_calc_resolver` setter, and `TaffyView`
forwards to it. Nothing else changes; the `calc` feature is now enabled.

The kernel interns each `(percent, points)` pair (`kernel/src/style.rs`,
`calc_handle`) and names it by index shifted past the three tag bits, so a
handle is never null or misaligned, equal pairs compare equal as styles, and
resolution (`resolve_calc`: `basis × percent / 100 + points`) needs no
unsafe code. Held by
`kernel/tests/it/browser_cases.rs::calc_of_a_percentage_and_a_length_resolves_against_the_containing_block`
(a `calc(100% - 89px)` child of a 400px block is 311px; a calc height, margin
and padding resolve against their own bases) and the codec's round trip of
wire kind 7. Upstream would want the same hook or a `TaffyTree` generic over
a resolver; either removes this patch.

## Patch 14: a flex item's intrinsic contribution clamps before its margin — to upstream

**Implementer:** Claude (Opus 5.5), 2026-09-26, for LLP 1054 P1.

`determine_container_main_size`'s intrinsic path (`compute/flexbox.rs`, the
min/max-content contribution of an item with a min or max main size) added
the item's margin to its content size and *then* took
`max(flex_basis)` and clamped by `min-height`/`max-height`, both inner
sizes. A negative margin therefore vanished: a content-sized column holding
`row min-height: 48px; margin-top: -44px` over 90px of content measured 90
where Chrome measures 46, so a Bluesky profile header was 44 pt too tall on
iOS (whose list rows are the kernel's layout) and right on the web (the
browser's). The fix clamps the inner size and adds the margin after, in
both the measured branch and the definite-preferred-size branch. Held by
`contract/cli/tests/it/negative_margin.rs` (five item shapes, and the
header the port found). Upstream has the same order.

## Patch 15: a node's style is shared — Exact's

**Implementer:** Claude (Opus 5.5), 2026-09-27, for the crypto list's memory.

`NodeData::style` is an `Rc<Style>` (`src/tree/taffy_tree.rs`), and
`new_leaf`, `new_leaf_with_context`, `new_with_children`, `set_style` and
`set_style_unmarked` take `impl Into<Rc<Style>>`, so an owned `Style` still
works and a caller may hand the same allocation to many nodes. A `Style` is
552 bytes and most of a list's nodes repeat a few: the kernel interns the
styles it lowers (`kernel/src/layout.rs`, `LayoutTree::share`, equality as
`write_style` already compares them) and each node holds a pointer. Layout
reads the style through the `Rc`; nothing else changes, and no result can.
It makes `TaffyTree` `!Send`, which the kernel already was. Held by the
kernel's layout suites (`cargo test -p exact-kernel`), which lay out through
shared styles throughout, and `kernel/src/kernel/trim.rs`. Upstream would
want an `Arc` or a style store keyed by handle; this stays Exact's.

## Patch 16: a replaced element that holds children is sized as a leaf — Exact's

**Implementer:** Claude (Opus 5.5), 2026-09-27, for `canvas`'s default size.

`TaffyView::compute_child_layout` (`src/tree/taffy_tree.rs`) dispatches a
node with children to its display's algorithm, which sizes an auto box from
those children. A canvas is a replaced element whose children are laid out
in its box and never size it (LLP 1014 D1, the web's `layoutsubtree`). A
node whose style says `item_is_replaced` and that has a measure context is
therefore sized by the measure function, as a leaf with no children is; on
`PerformLayout` its display's algorithm then lays the children out at that
border-box size as an independent formatting context, and only their
scrollable overflow is kept from it. Held by `kernel/tests/it/canvas.rs`
(`a_canvas_with_children_is_its_natural_size`). Upstream has no replaced
container; this stays Exact's.

## Patch 17: a replaced element never stretches to a grid area or its insets — to upstream

**Implementer:** Claude (Opus 5.5), 2026-09-27, with patch 16.

Upstream stretches an auto-sized grid item whose `justify-self`/`align-self`
are `normal`, and derives an absolutely positioned box's size from opposing
insets, whatever the box. CSS gives a replaced element neither: `normal` is
`start` for an item with a ratio or a natural size (CSS Grid 1 §6.2), and a
replaced absolute box keeps its natural or ratio size, the insets only
placing it (CSS 2.1 §10.3.8, §10.6.5). With `item_is_replaced`:
`compute/grid/alignment.rs::align_and_position_item` defaults both axes to
`start` and ignores insets for size; `compute/grid/mod.rs` gives track sizing
the same default after placement, so an auto column is not sized for a
stretched item; the absolute pass skips the inset-derived width and height
(`compute/common/absolute.rs` since patch 18). Held by
`kernel/tests/it/browser_replaced.rs`
(`replaced_elements_do_not_stretch_in_a_grid_area_or_between_insets`, 66
literal-Chrome cases: canvas, iframe, video, `svg` with and without a view
box, and a loaded image).

## Patch 18: one solver for an absolutely positioned box — to upstream

**Implementer:** Claude (Fable 5.1), 2026-09-30, for LLP 1074 T2 and T4.

Upstream sizes and places an absolutely positioned box three times, in
`compute/block.rs`, `compute/flexbox.rs` and `compute/grid/alignment.rs`, and
the three disagree with each other and with Chrome 154:
- **Auto margins in a grid.** `left: 0; right: 0; width: 100px; margin: 0
  auto` stays at x = 0: the branch for an inset box read the margins with
  `auto` as zero.
- **Auto margins in a flex container** take the container's free space, not
  the space the insets leave: with `left: 20px; right: 60px` the box is 40 px
  off.
- **A block container** centres a box that has only a `right` inset.
- **The block axis.** No container centres a box taller than the space its
  insets leave; CSS gives the two margins equal negative shares there (§10.6.4
  has no exception, as §10.3.7 has for the inline axis).
- **The ratio.** Patch 12's five differences, in all three.
- **Shrink-to-fit.** A box without a width is measured in the whole
  containing block, not in the space its insets and margins leave.

`compute/common/absolute.rs` is the one solver (its module note states the
rules). Each algorithm gives it the containing block and, for an axis with
neither inset, where the box sits by that algorithm's own rule (patch 20's
`StaticPosition`). Patch 17's rule for a replaced element lives there now.

**Held by** `kernel/tests/it/browser_position.rs`
(`positioned_boxes_roots_and_ratios_match_chrome`): 279 literal-Chrome cases
in `fixtures/browser_position.tsv`, 93 of them absolutely positioned boxes in
block, flex and grid containers, LTR and RTL.

## Patch 19: a root is a block-level box in its offer — Exact's

**Implementer:** Claude (Fable 5.1), 2026-09-30, for LLP 1074 T2 and T4.

`compute/mod.rs::compute_root_layout` resolved a root's size only for
`display: block`, through upstream's ratio transfer, stretched an auto width
less its margins, and then placed the root at the origin whatever its margins
said. The kernel worked around the first part by rewriting every root's `width:
auto` to `100%` under border-box sizing (LLP 1010 §1), which left a root's
margins unsubtracted and made its `min-width`, `max-width` and authored height
border-box under `box-sizing: content-box`.

Now, for any root that is not absolutely positioned, whatever it lays its
children out as (CSS 2.1 §10.3.3):
- its size styles go through the ratio (patch 12);
- an automatic width fills the offer less its margins, within the limits the
  ratio transfers;
- its margins place it: auto margins take the space a given width leaves
  (equal shares; a negative share goes to the end margin alone), and an
  over-constrained box ignores its end margin. An RTL root is placed from the
  offer's right edge, as before.

The kernel's rewrite and its re-derivation on `AttachRoot` are gone
(`kernel/src/style.rs`, `kernel/src/txn.rs`). Upstream keeps a flex or grid
root content-sized, so this stays Exact's.

**Held by** the 39 root cases of `fixtures/browser_position.tsv` (block, flex
and grid roots: ratios, margins, auto margins, a root wider than its offer).
`presented_height.rs` changes one expectation: a content-box root's authored
height is its content height.

## Patch 20: `Position::Static` and the CSS containing block — to upstream

**Implementer:** Claude (Fable 5.1), 2026-09-30, for LLP 1074 T1.

Upstream has `Relative` and `Absolute`, and every container lays its own
absolutely positioned children out against its own padding box. CSS places
such a box against its nearest positioned ancestor. This patch adds the value
and the containing block; a tree that never says `Static` behaves as before.

- **`Position::Static`** (`style/mod.rs`): in flow, insets do nothing (block
  and flex item insets, grid's were already `Relative`-only), and the box
  contains no absolutely positioned descendant. Block layout's in-flow and
  margin-collapse predicates test `!= Absolute`.
- **`StaticPosition`** (`tree/layout.rs`): where a box sits on an axis with
  neither inset, as its parent's algorithm gives it — a rectangle in the
  parent's coordinates and an alignment. Block gives the point the box would
  be at in flow. Flex gives its content box and the box's alignment as the
  container's only item. Grid gives the area when the grid is the containing
  block and its content box when it is not, as Chrome does.
- **The seam** (`tree/traits.rs`, three defaulted methods on
  `LayoutPartialTree`): a `Static` parent does not lay an absolute child out.
  It keeps the child's static position (`set_static_position`). The box that
  contains the child asks the tree for the boxes it holds that are not its
  children (`hoisted_absolute_count`, `hoisted_absolute`), after its in-flow
  children are placed, and lays each out through the solver (patch 18) against
  its own padding box, writing the location relative to the child's parent.
  A `Static` box at the top of a tree holds what nothing else does.
- **`AbsolutePass`** (`compute/common/absolute.rs`) is that pass, shared by the
  three algorithms.
- **`TaffyTree`** keeps the static positions and the caller's record of which
  box holds which (`set_hoisted_absolutes`), and computes a parent's origin in
  the holder's coordinates from the unrounded layouts between them.

The record is the caller's to keep current, because only the caller knows when
a position or a child list changed, and a walk of the tree per layout would
undo patch 9. The kernel rebuilds it when one did (`LayoutTree::refresh_hoists`,
proportional to the absolute boxes and their depth). The dirty marks need no
help: a box moves between containing blocks only when a box on the path
between them is restyled or re-parented, which marks both dirty.

Patch 9's replay needs one rule more. A static box between an absolute box
and its containing block is no replay boundary, now or for the change that
takes it off that path: laying its subtree out alone would not place the box,
and its old containing block still counts the box that left
(`hoist_paths`, `hoist_paths_prior`). The 1,500-seed differential found the
second half.

**Held by** `kernel/tests/it/browser_position.rs`
(`containing_blocks_and_static_positions_match_chrome`): 79 literal-Chrome
cases in `fixtures/browser_containing_block.tsv`, of which seven are what else
makes a containing block in a browser (a transform, a filter) and are declared
not the kernel's (the Contract compiler lowers `position: relative` onto such
a box). `layout_equality.rs` draws positions, missing insets and end insets on
a second random stream, so its trees' seeds are unchanged: both differentials
(incremental against rehydrated and replayed, 40 rounds) pass over 1,500 seeds.


2026-09-30 ticket sweep: patch 18 measures shrink-to-fit between intrinsic widths
after subtracting the static inline inset (for a centred static position, the
space is twice the distance from the centre to the nearer edge, as Chrome's);
patch 19 uses that solver for an absolute root in a definite offer. Chrome cases
are in `browser_containing_block.tsv` (20 shapes of shrink-to-fit from a static
inset) and `browser_position.tsv` (the derived width's minimum in 25, the ratio's
height as a percentage basis in 15, the logical alignment keywords in 148).
Patch 12 also resolves percentages against the ratio height while allowing the
content minimum to enlarge the used height, and measures the automatic inline
minimum for height-derived widths (block, flex, grid, absolute boxes and roots).

## Patch 21: table-marked containers shrink to fit in block flow — to upstream

**Implementer:** Codex, 2026-10-02, for the form-control block-sizing QUEUE item.

Upstream avoids assigning a stretched known width to a table item, which is
enough for a measured leaf but not for a container: a flex container still
uses the definite available width. For an auto-width table-marked item, block
layout now measures its min-content and max-content widths and clamps the
available width between them before laying it out. Ordinary blocks, flex/grid
items, absolutely positioned boxes and replaced elements are unchanged.

The root path likewise withholds its normal automatic-width stretch from a
table-marked root. This matches Chrome's 13 px checkbox for
`#exact-root > input` in a 400 px wrapper rather than treating the projected
element as an ordinary block root.

The kernel uses this existing internal marker for HTML form controls. It gives
Exact's reset `<button>`, block, flex or grid, HTML's shrink-to-fit block
width; text fields and leaf controls follow the same path. `kernel/tests/it/browser_controls.rs` holds the Chrome 154 matrix across
block, flex row, flex column, grid and absolute placement.

## Patch 25: available space excludes the child's margins

`LayoutInput::available_space` has one border-box convention. Parents subtract
child margins; leaf and flex entries subtract only their padding and border.
Flex intrinsic/cross-size probes, grid intrinsic probes and root layout supply
that border-box space. Block and absolute callers already did. Flex cross-size
limits use the child's margins, not the container's.

An automatic non-stretched inline size also uses CSS fit-content's intrinsic
min/available/max clamp in grid and column-flex layout, shared with the absolute
solver. The width of wrapped ink does not replace the used width. Replaced and
ratio-specific sizing retain their existing paths.

**Held by** `browser_position::available_space_with_margins_matches_chrome`:
28 literal-Chrome cases cover absolute and in-flow leaf/block/flex/grid shapes,
short and unbreakable content, percentage/negative margins, padding and max-width.
The original ticket's absolute example already matched after patch 18's explicit
shrink-to-fit width; grid children still double-subtracted margins, and column
flex children treated block/grid and leaf/flex widths differently.

Both incremental/rehydrated/replayed layout differentials also pass 500 seeds
each, 40 mutations per seed (2026-10-02); the larger loop was a temporary run,
with the ordinary checked-in smoke counts restored afterward.

## Patch 26: block `align-content` moves absolute children's static positions — to upstream

**Implementer:** Claude (Opus 5.5), 2026-10-04, for the button reversal (LLP 1001 §1).

Upstream shifts only in-flow children by the group offset, and none when
nothing is in flow. CSS Box Alignment aligns the block container's content,
and Chrome 154 places an absolutely positioned child at its static position
within that aligned content: after a centred 20px child in a 100px box at 60
(Taffy: 20), and a lone one at 50 (Taffy: 0). The offset is now computed
whenever `align-content` is set and added to every absolute item's static
position; in-flow items and the first baseline move as before.

The kernel lays out a block `button`'s content with `align-content: safe
center`, HTML's anonymous button box. **Held by**
`browser_cases::a_button_lays_out_its_content_as_chrome_does`.

## Patch 27: a multi-column container's flow thread — Exact's

**Implementer:** Claude (Opus 5.5), 2026-10-04, for LLP 1093 D2 (CSS
multi-column layout). Upstream has no multicol.

A block container's style may carry `multicol: Some(Multicol { count, width,
gap, used_height, overflow })` (`style::block`). Such a container:

- **is its own formatting context**: it joins both of `block.rs`'s
  conditions, the one that chooses a new `BlockFormattingContext` in
  `compute_block_layout` (so it shares no floats with its parent) and the one
  in `compute_inner` that keeps its first child's top margin inside (Chrome
  154: 30px below the container's top);
- **lays its in-flow children out as one column of the used column width W**,
  CSS Multi-column Layout 1 §3.4 over its content-box width U
  (`Multicol::columns`): W is their available width and their basis for
  percentage widths (Chrome: `width: 50%` is 100px in a 400px two-column
  box). A content-sized U is the content's width as one column, which the
  columns then divide (LLP 1093 D10.5 declares it);
- **takes `used_height` only at `container_outer_height`**, after its
  children: the columns' content-box height the caller cut, plus the box's
  vertical padding and border, then the existing `min-height`/`max-height`
  clamp. It never reaches `style.size`, `known_dimensions` or the percentage
  basis, so children keep their inputs and their cache entries. While it is
  set the box gives its children no percentage-height basis at all, even
  where a parent hands its height back as known (an absolute box's solver, a
  stretched flex item): that height was not definite before the flow thread
  was laid out, and resolving against it fed back into the cut;
- **reports `overflow` as its scrollable overflow** once the caller has cut
  the columns, in place of the flow thread's, so ancestors see the columns.

Every container without the field is unchanged. **Held by**
`kernel/tests/it/browser_columns.rs` (Chrome 154, 73 cases) and
`layout_equality::multicol_relayout_is_result_equal_to_full_relayout`
(incremental equals rehydrated equals replayed; 3,000 seeds once, 16 checked
in), beside the 512-tree comparison Patch 7 left behind.

## Patch 28: a column item's main size is measured at its fit-content cross size — to upstream

**Implementer:** Claude (Opus 5.5), 2026-10-05, for the Signal Clone's bubbles.

CSS Flexbox §9.2 3E: when a flex item's main size is in its block axis and its
cross size is auto and not definite, the flex base size is measured with
fit-content as the cross size, max(min-content, min(max-content, available)).
Taffy measured it under the available cross space alone. A flex container
then sized itself to its items' summed bases: in a column that does not stretch it (`align-items: flex-start`
or `center`), a single-line row holding text 300 wide in a 200-wide column took
the text's one-line height as its base size, then was laid out 200 wide with
the text in two lines spilling out. Patch 25's fit-content clamp held only for
the final layout. The base-size and minimum-content probes now pass a
fit-content cross size measured from the item's own max- and min-content
contributions, clamped to its min and max and floored at its padding and
border, through the helper and condition determine_hypothetical_cross_size already
uses for the final width (`common::fit_content_width`; a column, an auto
cross size, no ratio, not a compressible replaced element), so the two agree.
That helper's clamp is corrected to CSS's order, max(min-content,
min(max-content, available)): it let max-content win when a negative margin
inverts the two, where Chrome takes the min-content (patch 25's grid, column
flex and absolute widths alike). The measure runs only
when a probe needs it. A leaf is measured so too: a leaf wraps to the space
only while its min-content fits it, and a word that only `overflow-wrap:
break-word` breaks makes its fit-content width its `max-width`; measured at
the space, a padded chat bubble at `max-width: 100%` of a 75% column was two
lines taller than its text (chat-rooms, round 26). Stretched items, sizing
keywords and items with a ratio are as before; a wrapping column in a row (an item whose own main axis is
the parent's cross axis) is not covered.

**Held by** `browser_flex::a_fit_content_flex_item_in_a_column_is_as_tall_as_its_wrapped_lines`
(six Chrome 154 cases through the web host: the row holding a wrapping row
and the negative-margin inversion fail before; the `max-width: 0` padding
floor failed patch 28's first draft) and
`browser_flex::a_fit_content_row_is_as_tall_as_its_wrapped_text` (CSS's rule
with the monospace measurer, failing before), and the leaf by
`browser_flex::a_leaf_wider_than_its_column_is_as_tall_as_its_lines_at_its_used_width`
(Chrome 155: 304 tall, 340 before). On iOS and macOS a 200-wide
`column align-items=flex-start > row > text` of three lines was 20 tall, its
text clipped; it is 60, as in Chrome.

## Patch 29: a marked subtree's layout, replayed from one like it — Exact's

**Implementer:** Claude (Opus 5.5), 2026-10-08, `android/row`.

A list row rebound to another item (LLP 1078), or built like its neighbours,
is laid out by the same algorithms over the same styles as rows before it;
only its leaves can answer differently, and in most feeds they rarely do. On
the Android Canvas host the easy list's row cost 77 flex-container computes a
rebind (ten nested containers, each asked seven or so questions).

`tree/memo.rs`. `set_memo_root` marks a box; a marked flex or grid container
whose cache has no answer is laid out through `memo_layout`. Computing it
records a trace: each container an algorithm computes (`Visit`: its style and
every child's style and child count, which is all a parent reads of a child
before asking it), each answer from outside the computation (`Query`: a
leaf's measure, a cache hit, a hidden or replaced box, asked for real), and
each write (`Store` at the cache seam, `Layout`, `Static`). The algorithms
read the tree only through `TaffyView`, so a later root makes the same first
call and, given the same answer, the same next: a replay walks a trace,
proving each visit by comparing styles and each query by asking the box at
that place, and makes the writes between. Where it stops, the root is
computed and recorded as before. Traces share their starts in a trie, so a
lookup is one walk; nothing in it names a node.

What is not compared, and why it need not be: of a `ComputeSize` answer,
anything but the size and collapsing margins (the cache keeps no more of
one, so no algorithm reads more); of a final layout's answer, a scrollable
overflow inside the box's own border box (every algorithm copies a child's
overflow into the child's layout and otherwise gives it to
`compute_scrollable_overflow_contribution`, which answers the border box for
any such overflow: the replay writes the child's layout with the overflow the
child gave this time, and a recorded layout that did otherwise is not kept).
A recording that reads a box the trace does not hold (a hoisted absolute, a
style or child list outside the visited boxes and their children) is
dropped. A block container the recorded layouts found in its cache and this
tree must compute stops the replay (it would take its parent's block
context). A replay that stops clears the caches of the containers it had
finished, so the layout that follows is recorded as if none had run.

After 24 misses in a row the memo attempts one root in 16 (rows whose every
text is new: heavy's feed); it holds at most 24,000 steps and then starts
over. While it has given up it holds the last attempted root's trace alone,
and frees the rest (they matched nothing; crypto's feed held 4.2 MB of
them). `enable_memo(false)` turns it off.

The kernel marks the children of a `List` (`LayoutMirror::sync_children`).
**Held by** `kernel::layout::memo_tests`: rows of two kinds rebound to seen
and unseen texts, a chip added and removed, a hidden badge and a changed
margin, every batch compared bit for bit (frames and scroll extents) with a
rehydrated kernel; a feed of one kind lays out no row once its texts were
seen; the same with the memo off. Every other layout test runs with it on
for the lists it builds (`containment_tests`).

## Patch 30: a multi-column container's resolved height bounds — Exact's

The block algorithm, and the leaf algorithm for a multi-column text with no
children, resolve `min-height` and `max-height` against the containing
block's height only where Taffy holds it definite (an authored height, a
stretched flex item, an absolute box with both insets). Patch 27's caller
cuts the flow thread into columns by those bounds, and could only guess that
definiteness from styles. `LayoutPartialTree::set_multicol_bounds` (default:
nothing) receives a multi-column container's two bounds, border box, `None`
where it has none, each time its final layout is computed (a measurement
may resolve them against another basis, and a final layout taken from the
cache writes none); `TaffyTree` keeps them (`multicol_bounds(node)`), the
maximum raised to a larger minimum as the layout clamps the box (CSS 2
§10.7), and a replay (patch 29) writes them as the recorded layout did. The
block path reports them from `compute_block_layout`; the leaf path from the
dispatch in `taffy_tree.rs`, through `leaf::height_bounds`, which resolves
them as `compute_leaf_layout` does for its own size, in every sizing mode,
as the block algorithm does: a flex item's final layout is a content-size
one, handed a size the bounds already clamped, and its columns are still
cut by them.
**Held by** `kernel::tests::it::browser_columns::a_percentage_height_bound_caps_the_columns`
(`max-height` in percent under an authored height and under a stretched flex
item, against Chrome, and under a larger `min-height`),
`a_paragraph_s_height_bound_caps_its_columns` (a text leaf's, alone and as a
flex item, against Chrome) and
`kernel::layout::memo_tests::a_replayed_row_s_columns_are_cut_by_its_recorded_height_bounds`
(List rows replayed after the first).

## Patch 31: allocate tree-owned layout caches when first used

`NodeData` holds a pointer to a cache, allocated only when `Cache::store`
keeps a result. A node that has never laid out carries no nine-entry cache:
Exact's inline text runs are engine nodes, but their paragraph is measured
as one box. Clearing a populated cache retains its allocation for reuse on
later edits. Hidden-layout and collapsing-margin answers that the existing
cache declines to store allocate nothing. Cache keys, eviction, invalidation,
replay, and the public `Cache` type are unchanged.

**Held by** `tree::cache::tests::lazy_storage_preserves_cache_answers_and_clear_state`
(the same query/store/clear sequence against the existing cache, including
axis, parent-height, sizing-mode, margin and hidden-layout differences) and
`lazy_storage_allocates_only_for_a_cached_result_and_reuses_it` (misses,
refused entries, invalidation, clone independence and allocation reuse).
The kernel's layout, replay, reparenting and fresh-tree differential tests
also run against this storage. The stale `Style` size assertions now include
the vendored extension rows: 600 bytes with `String`, 568 with `Arc<str>` on
the tested 64-bit host; this patch changes neither style layout nor its size.

## Patch 32: release node contexts with their primary nodes

`TaffyTree::remove` and `TaffyTree::clear` remove the matching
`node_context_data` entries as well as the primary node slots. A secondary map
owns its values independently, so leaving these entries behind retained Exact's
measurement and flow vectors until physical slot reuse or tree destruction and
allowed stale node keys to retrieve removed contexts. Focused drop-counter
tests cover immediate and exactly-once destruction, replacement, physical slot
reuse, stale-key absence, and preservation of an unrelated survivor context.

## Patch 33: a flex item's length in its container's main size is clamped by its maximum — to upstream

**Implementer:** Claude (Opus 5.5), 2026-10-12, for issue X86
(`issues/closed/20261012-column-height-ignores-leaf-max-height.md`).

`determine_container_main_size` sums the items' lengths for a container
whose main size is automatic. Four of its sites let an item's flex base size
past its `max_size`. The definite-available-space branch and the wrapping
`MinContent` branch floored the base size by `min_size` alone. The intrinsic
branch's scroll-container arm took the base size as it was. And its two
shortcut arms, for an item that may not shrink (`flex-shrink: 0`), took the
base size as a minimum, which outranked the maximum. A leaf's base size is
measured under `SizingMode::ContentSize`, which drops its min and max
(`compute_leaf_layout`), so it is the whole content. A column whose height is
automatic, holding a text leaf at `max-height: 160px`, was therefore as tall
as the whole text:

- in definite space, whatever the leaf: a row's unstretched item when the row
  has a definite height (the issue's cases A to C, whose probe row is the
  window's height), and an absolutely positioned column (case D; a T3 Code
  popover reached 16,000 pt while its textarea was laid out clamped);
- under a max-content offer (an item of a row whose height is automatic, a
  block's child), when the leaf is a scroll container (`overflow: hidden`)
  or may not shrink. A textarea is not a scroll container in Taffy (the
  kernel makes only a scroll view and a list scroll by default), so the
  issue's case H, a textarea column in a block, held.

A box clamps its own measured size, and under a max-content offer a leaf that
neither scrolls nor refuses to shrink takes the measured arm, which clamps, so
neither showed it. Chrome sizes the column from its items' clamped sizes in
every case.

The definite and wrapping branches and the scroll-container arm now clamp the
base size by the item's min and max main sizes, floor the result at its
padding and border, and add the margin last (patch 14's order: the clamp can
go below the padding and border, and a floor taken after the margin lost it).
The shortcut arms clamp by the flex base size first and by the min and max
main size last (CSS Flexbox §9.9.1); where the two ranges overlap that is the
combined clamp they used before. The same clamps give a row's min-content
width when a leaf's unbroken word is wider than its `max-width`. Upstream
main (`7d33901cc`, 2026-10-09) has the same sites.

**Held by** `browser_flex::a_column_is_as_tall_as_its_items_clamped_by_max_height`
(Chrome 155, plain HTML, 37 cases; 28 fail on the unpatched source): a row's
column (the row's height automatic, then 300) holding a text leaf or an
image, with margins, a negative margin, content- and border-box padding, a
border-box `max-height` under its padding with and without a margin, two
leaves and a gap; the absolutely positioned column, with a margin and a
negative one; a `flex-shrink: 0` leaf in a row's column and in a block's,
with a `height`, a `min-height` and a margin; a column in a block; a block,
a row and a column holding a box as controls; and six rows of an unbroken
word at `max-width: 130px`. On macOS the issue's probe lays out cases A to D
at 132, 132, 130 and 132 pt (898, 434, 656 and 706 before), and a column
holding a content-sized textarea typed past its maximum stays at the
textarea's height.

## Patch 34: invalidate row-layout memo after environment changes

The row-layout memo exposes `forget_memo` so an environment change invalidates
recordings whose calc handles keep the same identity but resolve differently.

## Patch 35: allocate a node's rounded layout when rounding first writes it

`NodeData::final_layout` is an `Option<Box<Layout>>`, written by
`set_final_layout` (the rounding pass) and read as `Layout::new()` before it
was. Exact lays out unrounded (`disable_rounding`), so every node carried a
92-byte layout nothing wrote or read: 84 bytes a slot now, 91 KB of euxy's
1,087 slots. Reads under rounding are unchanged.

**Held by** `tree::taffy_tree::tests::make_sure_layout_location_is_top_left`
(rounded layouts read after a layout; `TaffyTree::new` rounds) and
`test_layout` (a layout read before any was written), and by the kernel's
layout tests, which read the unrounded one.

## Patch 36: compress cyclic replaced-element contributions in block layout

A replaced block child with a cyclic percentage width or max-width contributes
zero to its ancestor's min-content width, floored by its authored inline minimum
and padding/border, with margins added (CSS Sizing 3 §5.2.1). Cyclic percentages
in the minimum resolve against zero, preserving length terms in `calc()` and
comparison functions. The contribution is computed before a definite height can
transfer through the ratio. The child's own content size and final layout are
unchanged. Chrome 151 also compresses `calc()` widths containing percentages to
zero; the current specification instead resolves their percentage term against zero.

**Held by** `browser_replaced::replaced_content_contributions_distinguish_items_from_descendants`:
Chrome 151 frames for canvas, iframe, video, unsized SVG and loaded images, with
width/max-width percentages, calc, minimum and fixed sizes, padding, border and
margins. Direct flex items keep their own content minimum.
`browser_replaced::minimum` holds percentage-containing minima and the padding/border
floor under both box-sizing modes against Chrome 151 frames for the same five tags.

## Patch 37: preserve replaced ratios through flexing and min/max constraints

A replaced flex item's automatic cross size is derived from its used main size
(CSS Flexbox §9.4). The preferred main size's derived cross size is not retained:
it otherwise feeds back into the automatic minimum and survives after shrinking.
The content suggestion is measured independently, clamped by cross-axis bounds
through the ratio, and capped by the transferred and specified suggestions (§4.5).
A definite stretch still sizes the content probe (§9.8).

The leaf's CSS 2.1 §10.4 constraint table takes sizes and bounds in the box the
ratio relates, then restores the inset. Natural ratios relate content sizes under
either box-sizing; authored non-auto ratios follow box-sizing. Padding and border
therefore stay fixed when a content-box ratio scales the natural dimensions.

**Held by** `browser_replaced::constraints`: literal Chrome 151.0.7922.34 frames
for canvas and loaded images, with metadata-free video controls, direct and nested
flex items, row and column axes, automatic and zero minima, cross-axis constraints,
padding under both box-sizing modes, and authored ratios. The existing
`browser_replaced` cases retain definite stretching; `browser_replaced::minimum`
retains patch 36's descendant contributions.

## Patch 38: retain padding and transferred minima in replaced content probes

A replaced flex item's content-size probe retains the container's inline size
for percentage padding ([CSS Flexbox §4.2](https://www.w3.org/TR/css-flexbox-1/#item-margins)).
ContentSize still ignores the preferred width. The automatic minimum includes
the resolved padding as well as the natural content width.

When the tentative ratio box has a zero dimension, the leaf constraint table
uses the explicit ratio to transfer minima. A transferred minimum is capped by
the destination's maximum, then its own minimum wins
([CSS Sizing 4 §4.4](https://www.w3.org/TR/css-sizing-4/#aspect-ratio-size-transfers)).
The inset is retained, so an unsized SVG's shrink-to-fit ancestor includes the
width required by its minimum height and padding.

**Held by** `browser_replaced::constraints::independent_content_minima_keep_percentage_padding`
and `zero_content_minima_transfer_through_the_ratio`: literal Chrome 151.0.7922.34
frames for canvas, loaded images, unsized SVG and metadata-free video. Cases cover
both box-sizing modes, row and column axes, authored ratios, borders and a maximum
that caps a transferred minimum.

## Patch 39: retain the ratio's inset in flex sizing and intrinsic floors

The definite-cross-size flex basis, intrinsic main-size contribution and min/max
transfers into unsized axes use `Ratio::width` and `Ratio::height`.
These conversions subtract the source-axis inset and restore the destination-axis
inset for a content-box ratio. An authored border-box ratio uses zero inset.
A padded canvas stretched to 100px tall therefore has a 180px flex basis:
80px of content height at 2:1, plus 20px of horizontal padding.

The kernel's intrinsic measurement of a replaced element without natural size
also transfers the vertical padding/border floor through an authored border-box
ratio. Its content height cannot become negative, so its automatic width must
fit that floor before the leaf applies constraints. The floor can exceed an
offered width or the percentage fallback; an explicitly given width still wins.
Content-box ratios retain their zero content-size contribution.

**Held by** `browser_replaced::constraints::intrinsic_padding_floors_preserve_the_replaced_ratio`
and `flex_ratio_transfers_keep_padding_and_border`: literal Chrome 151.0.7922.34
frames measured on 2026-10-18. Cases cover metadata-free videos in block flex
items, stretched canvases, both flex axes and box-sizing modes, width and height
maxima, asymmetric padding with borders, and authored and auto ratios.
`intrinsic_flex_ratio_transfers_keep_padding_and_border` holds growing canvases
inside a shrink-to-fit block, including column sizing and zero-grow controls.
`unsized_ratio_padding_floors_survive_width_offers` holds video, iframe and SVG
floors against narrow definite offers and cyclic percentage widths, including
an offer wide enough to expose the full max-content contribution.

## Patch 40: retain the definite height in absolute shrink-to-fit probes

An absolute non-replaced box's intrinsic width probes receive its authored
height, or the height between top and bottom insets, clamped by min/max and
floored by padding and border. A flex row can then stretch its items and
transfer their ratios when computing its intrinsic width. An automatic height
with only min/max constraints is still passed as unknown.

**Held by** `browser_replaced::constraints::absolute_flex_intrinsic_width_uses_the_clamped_definite_height`:
literal Chrome 151.0.7922.34 frames measured on 2026-10-18 for two padded
canvases in an absolute flex row. The 29 cases cover authored and between-insets
heights, min/max clamping, a minimum above the maximum, a percentage height,
an authored height overriding insets, growing and zero-grow items, authored
border-box ratios, and automatic-height controls with only a maximum.
The separate automatic-height constraint gaps are recorded in `QUEUE.md`.

## Patch 41: restrict intrinsic flex stretching to eligible items

An intrinsic main-size contribution uses the container's cross size for stretch
only in a single-line container with a definite cross size and with neither
cross-axis margin automatic. Otherwise the item contributes its content size
without a transferred stretch. This applies both to an absolute flex container's
width probe and to a flex container inside a shrink-to-fit block.

**Held by** `browser_replaced::constraints::intrinsic_flex_stretch_requires_a_single_line_and_non_auto_cross_margins`:
literal Chrome 151.0.7922.34 frames for top, bottom and paired auto margins,
wrap and wrap-reverse, with controls for ordinary stretch, main-axis auto
margins, non-stretch alignment and an authored item height, in both containers.
`absolute_flex_height_resolves_against_an_auto_height_containing_block` holds
percentage and calc heights and opposing insets against the containing block's
used height, with automatic and zero item minima.

## Patch 42: a recorded call is looked up among its own box's calls — Exact's

**Implementer:** Claude (Opus 5.5), 2026-10-18, for
`issues/closed/20261017-memo-recorder-repeats-quadratic.md`.

Patch 29's `Recorder::repeats` asks whether the trace already holds a box's
answer under an input, once for every answer a recorded layout takes from
outside the computation (a measure, a cache hit). It scanned every call
recorded so far, so recording a subtree of n boxes made O(n²) comparisons.
`asked` now links each call to its box's call before it, and `last_asked`
holds each box's last call by the trace's box index (dense: indices are
given in order from 0), so a lookup compares that box's own few inputs and
answers as before.

**Held by** `tree::memo::tests::a_recorded_call_is_looked_up_among_its_own_boxs_calls`
(2,000 boxes asked three questions each, twice: every answer is recorded
once, and no lookup makes more than three comparisons; the scan made up to
6,000 comparisons a lookup, 36,000,000 in all),
`a_lookup_answers_as_a_scan_of_every_recorded_call_does` (20,000 recordings
and lookups in a fixed pseudo-random order, each lookup checked against a
scan of every recorded call), both run by hand (`cargo test --manifest-path
vendor/taffy/Cargo.toml --lib tree::memo`; no lane runs taffy's unit tests),
and the kernel's `layout::memo_tests`, which compare replayed layouts with
fresh ones bit for bit.

## Patch 43: keep height bounds indefinite during intrinsic flex sizing

Equal or inverted width bounds remain known in both sizing modes so they can
size a column's height. Height bounds do not supply a known height while the
inline size is unresolved in `ContentSize` or an intrinsic width probe. The latter
includes `InherentSize`, which a block parent uses to measure its children.
This prevents premature stretch and ratio transfer during width measurement
without discarding a column's bounded width during height measurement. Authored
sizes and dimensions supplied by the caller remain intact, including the clamped
final height an absolute box receives in `ContentSize`. Block and root size
promotion are unchanged.

**Held by** `browser_replaced::constraints::intrinsic_flex_height_bounds_do_not_make_auto_height_definite`:
12 literal Chrome 151.0.7922.34 cases measured on 2026-10-18. Absolute flex rows
and normal flex rows inside absolute blocks stay 640px wide with two 320px
canvases, for equal and inverted height bounds and natural and authored
border-box ratios. Their final height stays 100px. Normal rows in a definite
800px parent keep 400px items. Floated rows were also measured at 640/320px in
Chrome; the kernel has no float style row. Patches 40 and 41 retain their
definite-height, auto-margin and wrapping controls.

`intrinsic_flex_column_height_uses_bounded_width` holds 12 further Chrome cases:
max-content grid rows sized by bounded columns with canvases and percentage-width
squares, plus non-stretched flex-parent controls. Equal and inverted width bounds
and `column-reverse` retain the width used for height measurement. Taffy's
`bounded_column_width_sizes_content_and_max_content_grid_height` holds both sizing
modes and grid items with `width:max-content;height:max-content`, whose keywords
are not exposed by the kernel. The grid, column and square stay 200px tall at a
bounded 200px width.

## Patch 44: distinguish a flex row's used height from a definite height

A flex row distinguishes a used height from a definite cross size at its own
layout entry. An absolute row's automatic height with a maximum stays indefinite
for flex basis sizing unless an authored size, ratio or opposing insets makes it
definite. Equal or inverted height bounds likewise supply only a used height
unless a preferred or caller-supplied height makes it definite. This uses the
existing `known_dimensions_are_definite` input within flex layout; the absolute
solver continues to supply definite used dimensions to blocks, grids and columns.

Flex items therefore keep the main sizes determined before final cross-axis
stretching, as [CSS Flexbox §9.4](https://www.w3.org/TR/css-flexbox-1/#cross-sizing)
requires. An absolute auto-height row capped at 100px keeps its two padded
canvases at 320px wide inside a 640px row; an authored 100px height still gives
180px items inside a 360px row. No flex-grow-specific rule or saved basis is needed.

**Held by** `browser_replaced::constraints::intrinsic_flex_height_bounds_do_not_make_auto_height_definite`:
36 literal Chrome 151.0.7922.34 cases measured on 2026-10-18, including zero-grow
and growing canvases, natural and authored border-box ratios, a maximum alone,
equal and inverted bounds, absolute rows, rows inside absolute blocks and normal
flow rows. The existing patch 40 and 41 cases retain authored and opposing-inset
heights, wrapping and auto-margin controls; patch 43's column cases still pass.

`browser_position::positioned_boxes_roots_and_ratios_match_chrome` also holds
22 Chrome 151 cases for absolute column wrapping and clamped ratio percentage
bases, including reversed directions, `wrap-reverse`, equal bounds, authored
heights, minima and block/flex/grid controls. Patch 45 adds the maximum-only
columns' container frames and the missing reversed-column cases.

## Patch 45: size an automatic flex column height from its longest line

`determine_container_main_size` applies the available-space floor to multiline
rows only. A column's automatic height uses its longest line, including gaps,
margins and the container's inset, then applies its height bounds. This follows
[CSS Flexbox's automatic block sizing](https://www.w3.org/TR/css-flexbox-1/#algo-main-container).
The absolute solver's definite offer still limits wrapping; it no longer raises
a 60px line to a 100px maximum. Definite heights and row sizing keep their paths.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
34 full container/item frame cases measured in Chrome 151.0.7922.34 on
2026-10-18, including 24 new cases. They cover absolute and normal-flow columns,
both column directions, wrap-reverse, nowrap, equal and inverted height bounds,
minimum and preferred heights, unequal lines with gaps, padding, and row and
row-reverse controls in block and shrink-to-fit contexts. The maximum-only
column is 300×60; reversed items start at y=0. Equal 100px bounds and nowrap
retain a 100px height. The test had 17 frame mismatches before this patch.

## Patch 46: include automatic item minima in flex line contributions

`determine_container_main_size` clamps each flex basis by the resolved minimum
that flexible-length resolution enforces, including the content-based automatic
minimum from [CSS Flexbox §4.5](https://www.w3.org/TR/css-flexbox-1/#min-size-auto).
The maximum clamp, padding/border floor and final margin addition keep patch 33's
order. The shared contribution sizes columns in definite available space and
wrapping rows under a min-content constraint. Patch 45's row-only available-space
floor remains intact.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
40 literal Chrome 151.0.7922.34 cases measured on 2026-10-18. Three column items
with a 60px flex basis and 100px-tall contents give a 100px wrapping container;
reversed items start at y=0. A nowrap column capped at 400px is 300px tall, and
a wrapping row in an 80px offer keeps its 100px content minimum. Cases cover
both directions and wrap-reverse, normal-flow controls, single-item and capped
nowrap columns, item maxima, zero minima, scrollable overflow, padding, borders
and positive and negative margins. The added cases had 100 frame mismatches
before this patch. The nowrap and row defects also reproduce on origin/main
before patch 45; its available-space floor masked the reported wrapping-column
case.

## Patch 47: measure a capped row's max-content width without wrapping

`collect_flex_lines` preserves a row's `MaxContent` width constraint when it
has a maximum. All items contribute to one line, as
[CSS Flexbox §9.9.1](https://www.w3.org/TR/css-flexbox-1/#intrinsic-main-sizes)
requires; the existing size clamp then applies the maximum. `compute_preliminary`
recollects lines against the clamped inner width before resolving flexible lengths,
measuring height and placing items. This also covers a root laid out directly
under `MaxContent` and a both-axis size measurement, which need not receive a
later definite-width pass. Line fitting sums item lengths and gaps separately,
matching intrinsic width accumulation. Interleaving fractional gaps can round a
line above its own max-content width or a maximum that should fit it exactly.
The fit comparison also allows 1/1024px of rounding error: a sum can round above
an independently represented width even with consistent accumulation. This
fixed tolerance is sixteen times smaller than Chrome's 1/64px layout unit.
Columns retain maximum-based wrapping:
ordinary block layout also uses `MaxContent` for indefinite vertical space.
Balanced wrapping is unchanged and remains disabled in the kernel.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
16 full container/item frame cases measured in Chrome 151.0.7922.34 on
2026-10-18. Absolute rows and rows inside capped absolute blocks are 100×90
with three 60×30 items; reversed items start at x=40. Controls cover normal
flow, no maximum in a 100px containing block, nowrap, contents narrower than
the maximum, and absolute and normal-flow columns in both directions. The
added cases had 12 frame mismatches before this patch.

`browser_position::max_content_roots_wrap_at_their_resolved_width` holds 14
further Chrome cases under `Offer::MAX_CONTENT`: 60px and 100px items in both
row directions and wrapping directions, gaps and padding in both box-sizing
modes, and nowrap, below-maximum and column controls. The Chrome analog is a
row inside a `width:max-content` wrapper; `float:left` wrappers give the same
eight basic row frames. These were measured with the same Chrome version and
date. Before recollecting lines, ten cases had 34 frame mismatches, including
100×30 roots that should be 100×90. Taffy's
`capped_max_content_rows_measure_their_wrapped_height` holds the eight basic
cases in both sizing modes; all 16 measurements previously returned 30px height.

Ten further root-frame cases and 40 measurements cover fractional widths and
gaps in both row directions, with maxima above and below the unwrapped width.
The root frames use the same Chrome version, date and `width:max-content`
analog. Three 60.1px items with 0.1px gaps fit on one line below a 300px maximum;
60.2px items with 0.2px gaps fit two per line under a 120.6px maximum. Before
matching the accumulation order, these cases had ten frame mismatches and 16
incorrect measured heights. The 73.33px controls cover two-decimal item widths.
Chrome's 1/64px length quantization accounts for less than 0.05px frame
drift in these fixtures; the size measurements check widths within 0.001px
and heights exactly.

Eight boundary root-frame cases cover three 60.4px items under `width:181.4px`
and `max-width:181.4px`, in both row directions. With 0.1px gaps they occupy
one line; 0.125px gaps still force wrapping. These use the same Chrome version,
date and wrapper. Sixteen further measurements cover the maximum in both sizing
and wrapping modes. Without the fit tolerance, the 0.1px cases had eight frame
mismatches and eight measurements with 60px height instead of 30px.

## Patch 48: measure a wrapping row's min-content contributions

`determine_container_main_size` takes the largest outer intrinsic contribution
of a wrapping row's items. It measures each item under `MinContent` with its
preferred width and min/max constraints, including when `min-width:0` or hidden
overflow makes the automatic minimum zero. Margins are added after sizing the
border box. Columns, nowrap rows and balanced wrapping retain their paths.

Chrome 151 applies neither flex-basis clamp in this calculation, unlike the
algorithm in [CSS Flexbox §9.9.1.3](https://www.w3.org/TR/css-flexbox-1/#intrinsic-sizes).
A 60px basis contributes 100px for 100px-wide contents and 20px for 20px-wide
contents, even with `flex-grow:0;flex-shrink:0`. An authored `width:60px`
contributes 60px in both cases. `InherentSize` measures these preferred widths
and bounds through the item's own layout algorithm, without substituting its
flex basis or suppressing a scroll container's contents.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
28 literal cases measured in Chrome 151.0.7922.34 on 2026-10-18, with full
container, item and content frames. They cover both row directions, zero and
automatic minima, hidden overflow, growable and shrinkable items, preferred
widths, narrower contents, item bounds, padding, borders, positive and negative
margins, and nowrap. Float wrappers in an 80px offer give the same frames.
Before this patch the new cases had 56 frame mismatches. The reported absolute
row is now 100×300 with 60×100 items; reversed items start at x=40.

Taffy's `wrapping_min_content_width_uses_contents_independently_of_flex_basis`
holds 18 direct `MinContent` layouts and 36 size measurements in both sizing
modes, against rows in `width:min-content` wrappers measured in the same Chrome
version. These include the 20px contribution that shrink-to-fit's available-width
floor hides, and the resulting overflow or shrinking of the 60px items.

`compute_preliminary` also lays out again at the resolved min-content width
before measuring height or placing items. This refreshes content-dependent flex
bases, percentage sizes and descendant wrapping under the known width. Taffy's
`min_content_rows_wrap_at_their_resolved_width` holds eight further layouts and
16 measurements: 200px contents whose three 60px bases fit on one line, zero
bases, and 90px/400px container maxima, in both row directions. Without this
step, six layouts and twelve measurements had incorrect heights; twelve item
frames also differed from Chrome.

`min_content_rows_remeasure_content_dependent_bases` in the kernel and Taffy
holds ten further Chrome cases, measured with the same version and date: a
100px item followed by two nested wrapping rows, each containing two 40px
boxes. Their auto bases measure 40px under `MinContent` and 80px at the resolved
width. The outer row is 100×300 with 80×100 nested items. Recollecting lines
with the earlier bases incorrectly merged the last two items into one line.
The cases include block wrappers, 60px item maxima, 50% preferred widths, a
definite 40px basis control, and both row directions. Literal frames in
`browser_position.tsv` hold the absolute shrink-to-fit path and direct
`MinContent` root layouts; Taffy also checks both sizing modes. Before refreshing
layout at the known width, these direct requests had 57 kernel frame mismatches
and 34 Taffy size/frame mismatches. All absolute cases already agreed with Chrome.

## Patch 49: resolve percentage heights against a changed final stretch size

`calculate_flex_item` treats the final cross size as definite when stretching
changes it from the hypothetical cross size. This supplies the used height to
percentage children as [CSS Flexbox §9.4](https://www.w3.org/TR/css-flexbox-1/#algo-stretch)
requires. Preliminary measurements retain patch 12's ratio rule. If content
grows a ratio item without stretch changing its height, its percentage children
still use the preferred ratio height.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
25 literal cases measured in Chrome 151.0.7922.34 on 2026-10-18, including full
container, item and descendant frames. They cover absolute and normal rows,
maxima and minima, definite heights, flex-start, columns, wrapping, reversed
rows, padding, borders, taller siblings and content growth. Before this patch,
12 frames differed: the reported 30px item gave its child 50px instead of 30px.
An uncapped normal row's content-grown 130px item retains its 50px percentage
basis, as does a row capped at that unchanged height.

Taffy's `stretched_ratio_percentage_height_uses_the_final_cross_size` holds
eight normal-flow layouts, including the capped failure and the content-growth
control. Its percentage heights and following sibling positions failed before
the final stretch size became definite.

`determine_used_cross_size` compares the clamped and hypothetical cross sizes
in 1/64px units, truncating each positive size as
[Blink's `LayoutUnit(float)`](https://raw.githubusercontent.com/chromium/chromium/main/third_party/blink/renderer/platform/geometry/layout_unit.h)
does. Rounding their difference incorrectly treats distinct lengths within the
same unit as stretch. When the item's measured outer size already fills the
line, compare with the same container insets added to both sides, preserving
its hypothetical height before reversing inset and margin additions. Apply the
item's bounds to that comparison too: an item maximum can cancel stretching.
This changes definiteness only; layout geometry and intrinsic measurement stay
unchanged.

Fourteen fractional-margin cases and 44 container cases, measured in Chrome
151.0.7922.34 on 2026-10-18, cover absolute and in-flow rows, padding, borders,
box-sizing, nested containers, columns, bounds and layout-unit boundaries.
Eight further cases cover fractional constraints in both flow modes. Chrome
uses 110.078125px for a 110.09px maximum; minima of 110.102px, 110.108px and
110.109px share the natural 110.09375px unit and retain a 50px percentage basis.
The latter two minima gave the percentage child the full height before the
correction: eight frame mismatches. These eight fixture cases compare literal
frames in layout units because the kernel retains f32 geometry.

Taffy's `fractional_cross_margins_do_not_make_content_growth_a_stretch` checks ten
layouts without pixel rounding. `container_insets_do_not_make_content_growth_a_stretch`
checks twenty-four more, including the fractional bounds, unit boundaries and
an unchanged subunit cap. Four layouts failed before the per-size comparison.
Both retain the ratio basis for content growth and the final size for stretch.

## Patch 50: include the definite height in a ratio box's automatic width minimum

`minimum_ratio_width` combines its content-only min-content measurement with
the width transferred from the definite height, taking the larger before
capping by `max-width` ([CSS Sizing 4 §5.1](https://www.w3.org/TR/css-sizing-4/#intrinsic),
[Flexbox §4.5](https://www.w3.org/TR/css-flexbox-1/#min-size-auto)). The height
is clamped by its own min/max before transfer; `Ratio` preserves padding and
border according to `box-sizing`. Replaced boxes, scroll containers and
explicit width minima retain their existing paths.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
27 literal cases measured in Chrome 151.0.7922.34 on 2026-10-18, prefixed
`Chrome 151 ratio minimum`. Before the patch, 22 frames differed: the empty
80px square shrank to 50px in a narrow row and to 0px in the absolute-block
case. Coverage includes siblings, max-width, wider content, height bounds,
padding and borders under both box-sizing modes, and the explicit-minimum,
overflow, stretch and column controls. The shared minimum fixes the absolute
case without a separate intrinsic-layout change.

The final cross-size clamp omits the automatic inline minimum when a column
stretches the item's width. That cross size takes the line width and authored
bounds ([Flexbox §9.4](https://www.w3.org/TR/css-flexbox-1/#algo-stretch)).
Intrinsic measurement retains the minimum so shrink-to-fit and wrapping
columns account for wider content. Rows, non-stretched columns, block and
grid keep their ratio minima.

Twenty-six `Chrome 151 ratio column stretch` fixtures, measured with the same
Chrome version and date, cover definite and automatic column heights,
column-reverse, alignment overrides, margins, bounds, padding, wider content
and wrapping, plus block and grid controls. Ten frames failed before the
correction, including an 80×80 item where Chrome stretches it to 50×80. Six
additional frames guard intrinsic measurement: omitting the minimum during
setup narrowed wider-content columns from Chrome's 120px to 80px.

## Patch 51: use a definite flex basis in a row's intrinsic contribution

A row substitutes the item's hypothetical border-box main size when its
intrinsic contribution exceeds the flex base and it cannot grow, or falls
below the base and it cannot shrink. The used basis must be definite. This
matches Chrome 151's
[`ComputeMinMaxSizeOfRowContainer`](https://chromium.googlesource.com/chromium/src/+/refs/tags/151.0.7922.34/third_party/blink/renderer/core/layout/flex/flex_layout_algorithm.cc#2871)
and [Flexbox §9.9.1](https://www.w3.org/TR/css-flexbox-1/#intrinsic-main-sizes).
The hypothetical size already includes the automatic minimum and min/max
bounds. Margins are added afterward (Patch 14). Rows no longer use the
column basis clamps or scroll-container basis shortcut. Columns retain
Patch 33's clamp ordering; wrapping min-content retains Patch 48's separate
contribution path.

An absolute box's fit-content width probes both intrinsic sizes through
`common/absolute.rs` and `common/mod.rs`. A block wrapper forwards the same
intrinsic query through `block.rs`. Neither needs a separate sizing fix.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
30 literal cases prefixed `Chrome 151 intrinsic flex basis`, measured in
Chrome 151.0.7922.34 on 2026-10-18. They cover the absolute row and block
wrapper, siblings, growth and shrink limits, automatic minima, bounds,
percentage and auto bases, padding, borders, margins and overflow, with
column, definite-width and wrapping controls. Before the patch, the first
25 cases had 13 frame mismatches: the reported row was 100px wide
instead of 40px, and 130px instead of 70px with its sibling.

Taffy's `intrinsic_row_contributions_respect_definite_flex_bases` checks
12 layouts under both intrinsic widths and both sizing modes. Chrome's
`width:min-content` and `width:max-content` measurements supply the expected
sizes, including `flex-basis:content` controls that the kernel does not
expose. Before the patch, 16 queries differed. Run with
`cargo test --manifest-path vendor/taffy/Cargo.toml --no-fail-fast`.

Wrapping max-content is floored by the widest outer min-content contribution
before container insets and bounds. It shares Patch 48's measurement, so a
direct MaxContent query has the floor Chrome applies even without an absolute
fit-content caller. Seven `Chrome 151 intrinsic wrap floor` fixtures check
direct kernel MaxContent layouts; Taffy's
`wrapping_max_content_is_floored_by_min_content` also checks both sizing modes
and contents with an explicit zero minimum. Measured with the same Chrome
version and date. Before the correction, seven kernel frames and twelve
Taffy measurements/layouts differed, including 40px instead of 100px.

The contribution guard distinguishes a definite used basis from a computed
base size made definite by an aspect ratio. Content and intrinsic-keyword
bases remain content-based for this guard; ratio-derived definiteness still
serves percentage layout. Taffy's
`ratio_content_bases_do_not_clamp_intrinsic_contributions` checks seven
Chrome-measured cases under both intrinsic widths and sizing modes. Twenty
queries failed before the distinction: the reported content-basis row was
20px instead of 100px, and disabling shrink kept a 10px row at 20px.

Intrinsic line sizes sum the computed outer contributions directly. The
unused flex-fraction round trip divided a negative difference by a zero
inner flex base, then discarded it when multiplying back. This erased
negative margins at a zero basis or padding/border floor, and contributions
already below the base without Patch 51's substitution.

Nine `Chrome 151 intrinsic flex basis zero inner` fixtures cover these cases,
positive-margin controls and a column. Taffy's
`zero_inner_flex_bases_preserve_negative_contributions` also checks direct
MaxContent measurements and layouts in both directions, with growth enabled
and disabled. All were measured in Chrome 151.0.7922.34 on 2026-10-18. Before
the correction, nine kernel frames and twelve Taffy measurements/layouts
differed; the reported 20px row was 30px.

## Patch 52: keep flex cross-axis auto margins nonnegative

`resolve_cross_axis_auto_margins` distributes only positive free space to
automatic margins. An overflowing item stays at block/inline start: the top
in a row, the left in an LTR column, and the right in an RTL column. RTL
columns use the negative free space as a position offset, preserving fixed
margins and keeping auto margins at zero. Items without cross-axis auto
margins retain their alignment path.

This follows Chrome 151's
[`ResolvedAlignSelf` and cross-axis margin resolution](https://chromium.googlesource.com/chromium/src/+/refs/tags/151.0.7922.34/third_party/blink/renderer/core/layout/flex/flex_layout_algorithm.cc#1894):
auto margins coerce alignment to flex-start and their share is clamped to
zero. It gives the overflow placement required by
[Flexbox §9.6](https://www.w3.org/TR/css-flexbox-1/#algo-cross-margins)
without assigning a negative used auto margin.

**Held by** `browser_position::cross_axis_auto_margins_match_chrome`:
84 literal cases in `browser_flex_auto_margins.tsv`, measured in Chrome
151.0.7922.34 on 2026-10-18. They cover individual and paired margins,
negative, zero and positive free space, both axes and reversed directions,
RTL columns inside LTR blocks, multiple lines, fixed positive and negative
opposite margins, and alignment overrides. Before the patch, 18 frames
differed; the reported item was at x=-30 instead of x=0.

Taffy's `cross_axis_auto_margins_never_consume_negative_space` checks the
used margins for 54 layouts, including RTL left-auto cases whose frames
already matched despite negative margins. Before the patch, 18 margin pairs
differed. Run with `cargo test --manifest-path vendor/taffy/Cargo.toml
--no-fail-fast`.

## Patch 53: preserve flex-start in overflowing distribution fallbacks

`apply_alignment_fallback` keeps `stretch` and `space-between` at unsafe
`flex-start` when lines or items overflow. Implicit safety previously turned
that into logical `start`, losing the reversal in `wrap-reverse` cross axes
and reversed main axes. RTL column placement already handles its direction;
its line offsets need no separate correction.

This follows Chrome 151.0.7922.34, measured on 2026-10-18.
[CSS Align §4.3](https://www.w3.org/TR/css-align-3/#distribution-values)
specifies `flex-start` for `stretch`, but **safe** `flex-start` for
`space-between`; Chrome uses the unsafe fallback for both in these cases.
Explicit positional `safe`/`unsafe` alignment and the safe-center fallbacks
of `space-around` and `space-evenly` are unchanged. Grid and block callers
also match Chrome: without flex reversal, `start` and `flex-start` place
content at the same edge, including RTL grids.

**Held by** `browser_position::flex_distribution_fallbacks_match_chrome`:
105 literal cases in `browser_flex_wrap_reverse.tsv` cover one and two
lines, overflow and fitting lines, both axes, wrap directions, LTR/RTL,
reversed main axes, positional/distribution controls and grid/block overflow.
Before the patch, 40 frames differed. The two-line row changes from y=20,0
to y=10,-10; the RTL column from x=-10,10 to x=0,20.

Taffy's `distribution_fallback_preserves_flex_start_edge` failed on four
reversed offsets before the patch. The accompanying safety and spacing
test holds the other fallback behavior. Explicit content-alignment safety
and `justify-content:stretch` are covered at the Taffy layer because the
kernel's declaration vocabulary does not admit them.

## Patch 54: derive a flex column item's ratio width after flexing

A width transferred from a preferred height is not an authored cross size.
Column item setup keeps that width unresolved, allowing the automatic height
minimum to use a definite stretched width or the content alone, as
[Flexbox §4.5](https://www.w3.org/TR/css-flexbox-1/#min-size-auto) and
[§9.8](https://www.w3.org/TR/css-flexbox-1/#definite-sizes) require.
Patch 12 still excludes a provisional stretched width in wrapping columns.

Cross sizing derives the width from the flexed height ([§9.4](https://www.w3.org/TR/css-flexbox-1/#cross-sizing)).
Patch 50's automatic inline minimum is resolved at this stage for columns:
`minimum_ratio_width` accepts the used border-box height and keeps the larger
of its transferred width and the content's min-content width. With an auto
preferred height, that content probe retains the width cap transferred from
`max-height`; flexing supplies the ratio transfer without making the probe
definite. Other layout callers retain the preferred-height calculation.
Final stretch still uses authored width bounds, preserving Patch 50's
intrinsic-width protection.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
32 literal `Chrome 151 ratio column shrink` cases measured with Chrome
151.0.7922.34 on 2026-10-19. Before the patch, 22 frames differed. The reported
50×80 item becomes 50×50. In a 20px-tall column, stretch gives 50×50,
`flex-start` gives 20×20, and wrapping gives 50×20. Controls cover explicit
widths, auto and fixed margins, taller content, minimum and maximum widths,
zero height minima, hidden overflow, disabled shrinking, two ratios, reversed
columns, padding and borders under both box-sizing modes, and rows. Existing
`Chrome 151 ratio column stretch` cases retain intrinsic and wider-content coverage.

## Patch 55: floor stretched flex sizes before cross-axis alignment

`determine_used_cross_size` includes padding and border in the minimum used
cross size, including when an authored maximum is smaller. This keeps the
content size nonnegative ([CSS Sizing §3.3](https://www.w3.org/TR/css-sizing-3/#box-sizing))
before `outer_target_size` feeds alignment. Applying the floor only in child
layout left alignment using a size smaller than the box it positioned.
The same floor applies to the comparison that detects actual stretch.
Patch 50 still excludes a column's automatic ratio minimum from final stretch;
authored bounds keep their box-sizing adjustment and minimum precedence.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
23 literal `Chrome 151 column stretch floor` cases measured with Chrome
151.0.7922.34 on 2026-10-19. Eight frames failed before the patch. The reported
40×80 item in a 10px RTL column moves from x=0 to x=-30, including with a
ratio under either box-sizing mode. Controls cover LTR, fitting items,
`flex-start`, explicit widths, padding and borders, and minimum/maximum
bounds under both box-sizing modes. Existing ratio-stretch fixtures pass.

## Patch 56: transfer incoming dimensions in flex and grid content measurement

Flex resolves Patch 12's ratio from the incoming dimensions when computing its
layout constants. Grid omits preferred sizes before
ratio resolution in `ContentSize`, retaining the sizes and limits derived from
incoming dimensions. A content probe can therefore transfer a definite cross
size without restoring the preferred main size it was asked to ignore
([Flexbox §4.5](https://www.w3.org/TR/css-flexbox-1/#min-size-auto),
[§9.8](https://www.w3.org/TR/css-flexbox-1/#definite-sizes)).

For non-replaced containers in `ContentSize`, a transferred width is a minimum,
not a known dimension: flex measures its items and grid sizes its tracks before
combining their content with that floor. Taller content can likewise exceed
the existing automatic height floor. Both transfers use the declared box
sizing and retain the authored bounds. Both incoming dimensions remain
authoritative; an authored size replaced by flexing no longer supplies a
second ratio floor.
A ratio height derived from a definite width supplies a definite cross size
and available space for flex item measurement, even while retained as a floor
that content can exceed ([CSS Sizing §4.2](https://www.w3.org/TR/css-sizing-4/#aspect-ratio)).
This preserves item sizing when the root reaches its ratio floor on its first
pass and needs no second layout. The parent-side rules of patches 44, 50, 54
and 55 are unchanged.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
40 literal `Chrome 151 ratio container minimum` cases measured with Chrome
151.0.7922.34 on 2026-10-19. Seventeen frames failed before the patch. Flex and
grid items with `height:80px;aspect-ratio:1` in a 50×20 column change from
50×20 to Chrome's 50×50. The row analogues change from 20×80 (flex) and 20×50
(grid) to 50×50 through the same fix. Controls cover block items, taller
content, zero minima, hidden overflow, alignment, wrapping, explicit widths,
padding and borders under both box-sizing modes, specified-height caps,
disabled shrinking, percentage children and a nested flex column.

The 31 literal `Chrome 151 ratio container content floor` cases use the same
Chrome version and date. Thirteen frames failed with a transferred width
treated as known: flex and grid row items with 70px or 120px of min-content
width stayed 50×50 instead of Chrome's 70×50 or 120×50. Controls cover fixed
and stretched cross sizes, specified-width caps, zero minima,
hidden overflow, alignment, both box-sizing modes, wider and taller column
content, and a flex column inside a row. The original 10px-content row cases
retain the 50px transferred floor. Four `ratio two transfer` cases with 10px
content hold the declared ratio: columns give 50×25 and rows give 60×30 for
both flex and grid items.

Ten `Chrome 151 ratio definite cross` cases use the same version and date,
both in a 50px block and as roots offered 50px
(`ratio_roots_in_a_definite_offer_match_chrome`). Four root frames and six
wrapped frames failed before preserving the definite cross size and available
space. The auto-width 1:1 flex root's ratio item changes from 10×50 to 50×50,
matching Chrome and `origin/main` at c8f5d6c96. Controls cover a second ratio,
height bounds, wrapping, alignment, column direction, and flex and grid items.

## Patch 57: preserve the inline content minimum beyond a ratio height cap

A non-replaced container's `ContentSize` probe with a supplied height keeps
its authored maximum width instead of the width transferred from `max-height`.
The automatic inline minimum's container probe supplies its clamped definite
height; an indefinite-height probe retains the transferred cap, including
for a flex basis. Leaves use the same height distinction (Patch 64).
The minimum combines that independent content width with the height transfer.
Block uses the same ratio-aware content measurement as flex and grid: a
derived width is an automatic minimum that wider content can exceed, unless
an explicit inline minimum or scrolling disables it. Block and flex also
keep the transferred maximum out of a supplied-height probe's min/max short
circuit.

A row item with a definite height keeps that wider content minimum when
flex chooses its automatic minimum. Specified widths and maximum widths
still cap it. When flex chooses its main-axis automatic minimum, auto-height
rows, columns and replaced elements retain the transferred cap; the
hypothetical-size clamp is unchanged. A column item with a definite preferred
height can still exceed its transferred width cap, as in block, absolute and
root layout.
This follows Chrome 151.0.7922.34, measured on 2026-10-19.
[Flexbox §4.5](https://www.w3.org/TR/css-flexbox-1/#min-size-auto) defines a
converted cross-axis maximum for the content suggestion of non-replaced
elements too; the inline-axis behavior here is the measured browser result.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
50 literal `Chrome 151 ratio max-height minimum` cases. Before the patch,
28 frames differed. The reported item changes from 60×60 to 120×60; with
`max-width:90px` it becomes 90×60. Controls cover block, flex and grid items,
wide and tall column content, minimum heights below and above the maximum,
ratios 2 and 0.5, explicit minima, hidden overflow, box sizing, flex bases,
shrinking, wrapping, reversed rows, percentage heights and definite stretch.
An auto-height row item stays 60×60, as does the column analogue.

`browser_replaced::constraints::ratio_cross_maximum_still_caps_replaced_minima`
holds eight measurements of canvas and loaded-image items (natural size
300×150), including 60×60 rows and columns, a width cap and a zero minimum.

The 48 literal `Chrome 151 ratio max-height growth` cases use the same Chrome
version and date. They hold growth in 200px rows with block, flex and grid
items and outer parents. Removing the transferred cap from an indefinite-height
basis probe froze the reported item at 60×60 instead of Chrome's 200×60;
25 cases (33 frames) failed before restricting the uncapped probe to a
supplied height. Controls cover zero minima, hidden overflow, padding under
both box-sizing modes, flex bases, a width cap, another ratio, minimum heights,
explicit heights and definite stretch. Equal minimum and maximum heights
without an authored height keep 60×60 in a 50px row, as
Chrome and `origin/main` do; they do not gain a definite-height exception.

The 24 literal `Chrome 151 ratio inline probe` cases use the same version
and date. Eleven text-leaf frames failed before preserving the independent
probe. The 120px word keeps 120×60 with max-height and 120×80 without it;
controls cover an authored width cap, zero minimum, scrolling, another ratio,
both box-sizing modes, shorter and wrapping text, and growth. Block and
absolute children, the root and flex-start column items with a 120px child
keep 120×60 in Chrome and the kernel; main's 60×60 is not a cap to restore.

## Patch 58: preserve grid ratio minima and bound track contributions

Grid alignment keeps `minimum_ratio_width` in its final minimum-width clamp
when the inline size depends on the ratio.
The shared minimum already respects authored `max-width`; a maximum
transferred from `max-height` must not erase wider content. Grid track sizing
clamps a preferred size by its resolved minimum and maximum before using it
as the item's minimum contribution, as `known_dimensions` already does.
This applies on both axes, including items without a ratio.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
17 literal `Chrome 151 grid ratio maximum` cases, measured with Chrome
151.0.7922.34 on 2026-10-19. Before the patch, 22 frames differed. The
reported grid changes from 50×80 to 50×60 and its item from 60×60 to 120×60.
Controls cover explicit auto columns, start alignment, narrower content,
no maximum, block parents, authored widths and bounds, zero minima,
hidden overflow, a minimum height above the maximum, ratio 2, both box-sizing
modes with padding and borders, no ratio, and a max-width counterpart.

Explicit inline stretch supplies the grid area's width before resolving the
ratio, so neither the ratio's automatic inline minimum nor transferred bounds
replace that width. Auto margins cancel stretch; authored width limits still
apply. This follows [Chromium 151's inline sizing](https://github.com/chromium/chromium/blob/782af9cb30a53f54487e5d2e44738645a8ec457c/third_party/blink/renderer/core/layout/length_utils.cc#L527).
Intrinsic track contributions retain the shared content minimum. A derived
width is not an authored preferred width: an automatic minimum follows the
auto-track, overflow and fixed-track-limit rules. Thus a fixed 60px track
stretches the item to 60px, while an auto track sized by its 120px content
stretches it to 120px.

The same test holds 32 `Chrome 151 grid ratio stretch` cases, measured with
the same version and date. Before this correction, 20 frames differed.
They cover fixed widths below and above the ratio transfer and content,
implicit and explicit auto columns, intrinsic and fractional tracks, capped
auto minima, normal and start alignment, auto and fixed margins, authored
widths and limits, height limits, overflow, and both box-sizing modes.
Second-row siblings expose the auto column's width independently of the
ratio item's final size. No `justify-self` row is exposed by the kernel.

The automatic-minimum predicates inspect only the tracks the item spans,
as required by [CSS Grid §6.6](https://www.w3.org/TR/css-grid-1/#min-size-auto).
An unrelated fractional track must not erase the content minimum; an
unrelated auto minimum must not enable it. Both axes use the same predicates.
The same test holds 12 `Chrome 151 grid ratio span` cases, measured with the
same version and date. Six frames failed before this correction, including
items without ratios on both axes. Controls cover preceding and following
fractional tracks, a fraction inside the span, a single track, gaps, normal
alignment and zero minima. Four `Chrome 151 grid ratio minimum floor` cases
also retain measured 100×100 items with `min-height:100px`, in max-content
and absolute shrink-to-fit grids, with normal and stretch alignment.

## Patch 59: let automatic ratio heights contain content above a width cap

`Ratio::resolve` retains the height floor derived from the capped width,
but does not transfer `max-width` into a content-based automatic height's
maximum. This lets block, absolute and grid layout measure taller content
instead of treating equal transferred bounds as a known height or clamping
the final height to the ratio. Authored `max-height` still caps content;
explicit minima, scroll containers and replaced elements retain their bounds.
See [CSS Sizing 4 §4.3](https://www.w3.org/TR/css-sizing-4/#auto-min-size)
and [§4.4](https://www.w3.org/TR/css-sizing-4/#aspect-ratio-size-transfers).

A flex container's ratio-derived percentage basis does not determine its
automatic main size. Its content can exceed the ratio floor. Flex item
sizing still transfers constraints independently: a column's content size
suggestion is capped by the ratio-converted `max-width`, including when the
item also has a preferred height or `max-height`
([CSS Flexbox §4.5](https://www.w3.org/TR/css-flexbox-1/#min-size-auto)).

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
66 literal `Chrome 151 ratio max-width height` cases, measured with Chrome
151.0.7922.34 on 2026-10-19. The first 65 cases failed with 21 differing
frames before the patch. The reported grid remains 60×50 while its item
changes from 60×60 to 60×120; block and absolutely positioned items grow
likewise. Controls retain 60×60 for short content, 60×50 in a flex row and
60×60 in a flex column. They cover authored height bounds, explicit minima,
hidden overflow, a second ratio, padding and borders under both box-sizing
modes, and block, flex and grid contents. The existing replaced-element
constraint tests retain their ratio caps.

The column content cap floors `max-width` by `min-width` before converting
it through the ratio. A conflicting width minimum wins on that axis;
the preferred height and authored maximum height still cap the resulting
automatic minimum. The same test holds 25 `Chrome 151 ratio column conflicting
widths` cases, measured with the same version and date. Seventeen frames
failed before this correction. The reported item with an 80px height changes
from 100×60 to 100×80; its automatic-height sibling changes from 100×60 to
100×100. Controls cover height bounds, overflow, both box-sizing modes,
percentage bounds, short content, nested flex/grid contents, ratios 2 and 0.5,
and reversed columns. Non-binding and binding 70px width maxima retain
40×70 and 70×70 items respectively.

## Patch 60: a cache's measure slots are allocated as they are used

`Cache::measure_entries` held `CACHE_SIZE` (nine) `Option<CacheEntry<Size<f32>>>`
inline, 360 of a boxed cache's 448 bytes, for a box that is measured under one
or two inputs before its final layout. It is now a `Vec` of the slots used so
far, grown three at a time (`reserve_exact`), the entries at the same indices:
slots fill in cursor order, the cursor skips only a slot whose recently-used
bit is set (a filled one) and wraps only past the ninth, so slot `i` exists for
every `i < len()`, and the store either replaces slot `i` or pushes it. Hits,
eviction and `clear` (which keeps the allocation) answer as before. Euxy's
first screen: 312 caches of 448 bytes become 312 of 120 and their slots.

**Held by** `tree::cache::tests` (`lazy_storage_preserves_cache_answers_and_clear_state`
compares every answer with an eagerly stored cache through 240 mixed stores,
hits and clears) and the kernel's layout tests.

## Patch 61: transfer an intrinsic flex container's resolved width through its ratio

After intrinsic main sizing resolves a flex row's width, repeat preliminary
layout with that width and the input definiteness flags. The known width
bounds the repeat to one pass. Item generation now resolves percentage heights
and height bounds against the ratio height before flex sizing and alignment;
refreshing only the container constants left the items' sizes unresolved.
Pass only the width so content can exceed the automatic height floor without
changing the ratio's percentage basis. Authored height bounds, explicit minima
and scroll containers keep their existing ratio rules.
See [CSS Sizing 4 §4.2](https://www.w3.org/TR/css-sizing-4/#aspect-ratio-automatic),
[§4.3](https://www.w3.org/TR/css-sizing-4/#auto-min-size) and
[§4.4](https://www.w3.org/TR/css-sizing-4/#aspect-ratio-size-transfers).

**Held by** `browser_position::max_content_roots_wrap_at_their_resolved_width`:
17 literal `Chrome 151 intrinsic ratio floor` cases, measured with Chrome
151.0.7922.34 on 2026-10-19 inside `width:max-content` wrappers and compared
with direct `Offer::MAX_CONTENT` kernel layouts. Before the patch, 17 frames
in 11 cases differed. The reported root changes from 100×60 to 100×100;
without `max-height` it changes from 120×30 to 120×120. Controls cover definite
width and height, columns, grid, content exceeding the floor, centered and
stretched lines, reverse wrapping, nowrap, ratio 2, padding and borders under
both box-sizing modes, a zero minimum and hidden overflow.

The same test holds 16 literal `Chrome 151 intrinsic ratio percentages` cases,
measured with Chrome 151.0.7922.34 on 2026-10-23 in `width:max-content` wrappers.
Before item generation was repeated, 18 frames in 14 cases differed. A 60×60
ratio root's 50% item now measures 60×30 instead of 60×0 (60×10 with a 10px
minimum); a 100% item measures 60×60. Controls cover wrapping and reverse
wrapping, padding under both box-sizing modes, definite width, percentage
height bounds, ratio 2, a zero minimum and hidden overflow. Taller content and
multiple lines check that the ratio's percentage basis stays below the used
height when content exceeds it.

Columns repeat after cross sizing supplies their width, before the size-only
return. Repeat only when both dimensions were unknown: the supplied width
bounds recursion even when the ratio height remains automatic. The input
definiteness flags and the ratio's percentage basis are preserved as for rows.

The same test holds 18 literal `Chrome 151 intrinsic ratio column percentages`
cases, measured with Chrome 151.0.7922.34 on 2026-10-24 in `width:max-content`
wrappers. Before the column repeat, 31 frames in 15 cases differed. The reported
root changes from 60×0 to 60×60 and its 50% item from 60×0 to 60×30. With a
120px-tall sibling, the root grows to 60×150 while the item stays 60×30.
Controls cover definite width and height, no ratio, column-reverse, wrapping
and reverse wrapping, ratio 2, width and height caps, padding and borders under
both box-sizing modes, zero minimum, hidden overflow and percentage bounds.

## Patch 62: allocate rare style fields only when needed

`Style` keeps its grid templates, automatic tracks, names, areas, placements
and `multicol` in one optional `Arc<RareStyle>`. Absent fields read shared
initial values; clones share the allocation and writes copy it on demand.
Default construction and conversion of an all-default group keep no allocation.
Equality compares field values, including an allocated default group and NaNs,
so the kernel's value interning and `engine_hash` retain their meaning. Ordinary
block and flex styles no longer carry the grid vectors and placements inline:
with Exact's features on 64-bit hosts, `Style` falls from 600 to 256 bytes
(`RcInner<Style>`: 272). The kernel adapter keeps their rare group absent.
Layout inputs are unchanged.

## Patch 63: calculated lengths participate in automatic grid repetition

`TrackSizingFunction::has_fixed_component` includes calc handles: they are
length-percentage values, so a calculated minimum can size an `auto-fill` or
`auto-fit` repetition. The existing resolver supplies the value against the
container's content box. See [CSS Grid 2 §7.2.3](https://www.w3.org/TR/css-grid-2/#auto-repeat).

`FromCss` and `CssParseResult` are exported so Exact can extend the generic
`GridTemplateTracks` parser with its existing calculation parser. Taffy still
parses line names, ordinary breadths and repetition counts; Exact owns the
calculation representation and evaluator. Calculated `fit-content()` limits
remain unsupported.

**Held by** `style::grid::expand_tests::track_sizing_function_calc_round_trips` and
Exact's `calculated_grid_tracks` parser, wire and layout tests. The layout
cases were measured in Chrome 151 on Linux on 2026-10-23: automatic repetition
at 150px and 650px, `auto-fit`, percentage arithmetic, clamped rows, negative
results and indefinite percentage bases. The kernel retains floating-point
coordinates; comparisons allow Chrome's 1/64px layout quantization.

## Patch 64: retain transferred height caps in ratio leaf content probes

A non-replaced ratio leaf's horizontal `ContentSize` probe with no known
width keeps its height bounds and uses `container_sizes_through_ratio`
when its height is unknown or its available width is min-content.
Its preferred sizes and width bounds remain ignored. With no supplied
height, the transferred maximum caps the intrinsic width, as it does for
containers.
The flex basis then agrees with the hypothetical size instead of exceeding
it and freezing growth under [Flexbox §9.7](https://www.w3.org/TR/css-flexbox-1/#resolve-flexible-lengths).
The flexible-length freeze rule is unchanged.

When the preferred height is definite, `minimum_ratio_width` supplies the
clamped height to leaves as well as containers. For this min-content probe,
the shared helper makes the width transfer a floor and removes the
transferred width cap, so wider text is still measured independently. When
the preferred height is auto, the probe leaves height unknown so its
transferred cap still bounds the content minimum, even when a flex column
supplies a used height for the ratio transfer.
Cross-size resolution with a supplied height keeps the ratio-derived
preferred width so text wraps at that width. Replaced leaves, vertical
probes and probes with a known width retain their existing sizing path.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`:
literal `Chrome 151 ratio text growth` cases, measured with Chrome
151.0.7922.34 on 2026-10-24, with the monospace advance normalized to 10px.
Ten frames in nine cases failed before the patch: the reported
leaf changes from 60×60 to 200×60, and content-box padding from 80×80 to
200×80. Controls cover a zero basis, explicit minima, hidden overflow,
a width cap, ratio 2, both box-sizing modes, definite heights, stretch,
a growing sibling, auto-height columns with auto and zero height minima,
and no ratio or height cap. The existing block
growth, definite-height inline minima, replaced-element, percentage-height
and exclusion-height tests remain passing.

23 `Chrome 151 ratio text wrapping` cases use the same version and date,
normalizing both letters and spaces to 10px. Seven failed when the helper
also handled column cross-size resolution: the reported leaf measured
130×100 instead of 100×100. They cover flexed and percentage heights,
ratios and box sizing, with stretch, overflow, inline bounds, row, block
and absolute controls. The auto-height column with a 100px height cap
already measured 60×60 before Patch 64; it remains an owed case in `QUEUE.md`.

## Cargo workspace boundary

`Cargo.toml` declares an empty workspace so `cargo fmt --all` in a nested
Exact worktree does not attach this excluded path dependency to the enclosing
checkout. This is an Exact integration patch to retain when updating.

## Patch 65: measure stretched items at a ratio row's definite height

A single-line flex row with a ratio-derived automatic height measures a
stretched auto-height item at that definite cross size, clamped by the item's
authored height bounds and padding/border floor. Its overflowing descendants
no longer inflate the row's content-based height minimum. Wrapping rows,
non-stretched items, auto cross margins and explicit item heights keep their
content measurement. The row's automatic height remains a floor that those
items can exceed; columns, block and grid retain their content minima.

This follows [Flexbox §9.8](https://www.w3.org/TR/css-flexbox-1/#definite-sizes)
and Chrome 151's
[`BuildSpaceForLayout`](https://chromium.googlesource.com/chromium/src/+/refs/tags/151.0.7922.34/third_party/blink/renderer/core/layout/flex/flex_layout_algorithm.cc#702),
which applies definite stretch during measurement as well as final layout.
Rows with a supplied outer height retain their existing intrinsic measurement:
that measurement does not determine the container's height.

The root solver transfers its filled width only when the width was automatic.
Transferring an explicit width twice had mistaken its derived height minimum
for an authored minimum and fixed the height. Explicit-width roots now retain
the same content-based floor as automatic-width roots.

**Held by** `browser_position::positioned_boxes_roots_and_ratios_match_chrome`
and `ratio_roots_in_a_definite_offer_match_chrome`: 29 literal
`Chrome 151 ratio root overflow` cases measured in Chrome 151.0.7922.34 on
2026-10-24, in a 50px block and as direct roots offered 50×600 and 50×1000.
The ten existing `ratio definite cross` cases were remeasured in both offers.
Before the fix, the auto-width flex root and its ratio item were 50×70;
both are now Chrome's 50×50, with the 10×70 child overflowing. The same defect
without the item's ratio is covered. An explicit-width wrapping root was
50×50 instead of Chrome's 50×70. Controls cover block, grid, columns,
wrapping, explicit widths and heights, alignment overrides, auto margins,
item minima, hidden overflow, padding and borders under both box-sizing modes.
The grid control matches Chrome at 50×70 with a 70×70 item.

## Patch 66: justify in-flow block children

Block layout resolves a child's `justify-self` against the container's
`justify-items`. Non-stretch alignment gives an automatic width fit-content
sizing; placement aligns the margin box, with auto margins taking precedence
and `safe` overflow falling back to the container's start edge. Self-relative
values use the child's direction. `normal` and `stretch` retain block sizing.
The block style traits expose both properties, and their existing `Style`
fields are available with block layout as well as grid.

This follows [CSS Box Alignment 3 §6.1.1](https://www.w3.org/TR/css-align-3/#justify-block)
and Chrome 151.0.7922.34, measured on 2026-10-24. A centered 20px child in a
100px block moves from x=0 to x=40; an automatic-width wrapper around it
changes from 100px to 20px wide. A 120px child centers at x=-10, or x=0 with
`safe center` in LTR. In RTL with an LTR child, `start` puts a 20px child at
x=80 and `self-start` at x=0.

**Held by** `browser_position::block_justify_items_matches_chrome`: 82 in-flow
cases covering fixed and automatic widths, physical and logical alignment,
RTL, overflow safety, margins, bounds, percentages, insets, box sizing,
text, and block-level flex/grid children. The 72 mismatched frames before
the patch now match Chrome. `block_justify_self_overrides_the_container_default`
also failed before the patch and holds the vendor's per-item override; no
Contract attribute is added. The remaining fixture records the absolute-child
follow-up in `QUEUE.md`: automatic insets still give x=0 instead of Chrome's
x=40. Floats remain disabled in Exact.

## Patch 67: a scroll container's end padding extends its children's margin boxes

Flex, block and grid layout added a scroll container's end padding (inline-end
and bottom) to its whole scrollable overflow rectangle, which includes the
overflow of descendants. [CSS Overflow 3 §2.2](https://www.w3.org/TR/css-overflow-3/#scrollable)
adds it to the margin boxes of the container's in-flow children (and grid and
flex items) only; descendant overflow counts as it is. A child's margin box
is taken where it sits before any relative offset. So a full-bleed hairline in
a padded list (`margin: 0 -10px` inside 10px of side padding) reaches the
padding edge and leaves nothing to scroll, where Exact made the list scroll
10px sideways; a last child's bottom margin now comes before the bottom
padding; and a descendant overflowing its parent gets no padding after it.
`common::scrollable_overflow` holds the rule (`margin_box_contribution`,
`with_end_padding`). A container with no children keeps a rectangle of its
padding alone, as before.

Chrome 155.0.8059.86, measured on 2026-10-24: a 200 × 100 scroller with 10px
padding (padding box 220 × 120) holding a hairline bled to its padding edge
has `scrollWidth` 220 (Exact 230 before the patch); a 150px child with a 20px
bottom margin gives `scrollHeight` 190 (170); a 50px child holding a 200px
grandchild gives 210 (220); a 300px child with a 15px right margin gives
`scrollWidth` 335 (320); a 200px child moved 30px by `left` gives 240 (250).

**Held by** `browser_scroll_padding::end_padding_extends_children_not_descendants`:
17 cases across block, flex row and column, grid, RTL and relative offsets,
all of which failed before the patch.

## Patch 68: a stretched item in a single-line column of known width is not measured for its width

`determine_hypothetical_cross_size` measured every column item with an auto
width at its fit-content width, which asks the item for its min- and
max-content widths. For a list, that is every row's intrinsic widths, and
the rows laid out again at the list's max-content width; when a row is
inserted whose text is wider than any before, the max-content width changes
and every row is laid out again. When the column is single-line and its
width is known, the line's cross size is the container's inner width
([Flexbox §9.4 step 8](https://www.w3.org/TR/css-flexbox-1/#algo-cross-line)),
and an item that stretches (`align-self: stretch`, auto width, no auto
margins) takes that width less its margins (step 11), whatever its
hypothetical width was. Such an item now takes the stretched width as its
hypothetical width, clamped by its min and max width, as patch 65 does for a
row's height. Chrome skips the measurement too
([`WillChildCrossSizeBeContainerCrossSize`](https://chromium.googlesource.com/chromium/src/+/refs/tags/151.0.7922.34/third_party/blink/renderer/core/layout/flex/flex_layout_algorithm.cc)).
Nothing else reads the hypothetical width of such an item: the line's size
comes from the container, a column aligns no item by its baseline, and the
item's width was already definite, which is all patch 49's comparison of the
two widths decides. Frames are unchanged.

**Held by** `kernel/tests/it/list_insert.rs`: two rows inserted at the top of
330 rows of an inbox's shape (a swipe row of a wrapping title line, a subject
and a preview) measure 82 texts, 3,266 before; the 330 rows' first layout
measures 13,530, 48,840 before; every moved row keeps its size. Every
`browser_*` Chrome case and the layout-equality comparisons pass unchanged.

## Patch 69: where a grid placed an item from, for its caller — Exact's

A table's row or row group keeps no engine children: its cells are the
table grid's items beside it, and the kernel places them from the grid's
origin, moved as the row is moved (`kernel/src/layout/table.rs`,
`displacement`). How far the engine moved the row — a relative offset as
Taffy resolves it (percentages, `calc()`, `right` over `left` right to
left), or an absolutely positioned row's insets, whichever box contains it —
is its location less where the grid placed it from, which only the grid
algorithm knows. `LayoutPartialTree::set_grid_origin` (default: nothing)
receives that origin each time a grid places a child, in the grid's
border-box coordinates, as `location` is: for an in-flow item
(`grid::alignment::align_and_position_item`), its place in its area with
its alignment and margins but without its relative offset (the same
`align_item_within_area`, asked as `Static`); for an absolutely positioned
child (`compute_grid_layout`'s out-of-flow pass), its grid area's origin.
`TaffyTree` keeps it (`grid_origin(node)`, `None` for a node no grid
placed), reports a changed origin as a changed layout
(`take_layout_changes`), as a changed location is, so a caller that places
by it publishes again, and a replay (patch 29) writes it as the recorded
layout did (`Event::Origin`). No algorithm reads it; frames are unchanged.

**Held by** `kernel/tests/it/table.rs`:
`the_grid_reports_each_items_area_and_places_it_as_before` (the origins,
and an in-flow and an absolute item placed where they were before the
patch), `a_relative_row_without_insets_moves_nothing_however_aligned`,
`a_popover_rows_cells_follow_a_grid_that_moves_beneath_it`,
`a_popover_row_before_a_viewport_keeps_its_cells_on_it` and
`a_relative_rows_cells_take_the_engines_offset`. Every `browser_*` Chrome
case and the layout-equality comparisons pass unchanged.

## Patch 70: a grid container may raise its highest line — Exact's

Taffy clamps every placement to lines −10,000 to 10,000 and every span to
10,000 tracks (`MAX_GRID_TRACKS`, its reading of
[CSS Grid 1 §8.1.2](https://www.w3.org/TR/css-grid-1/#overlarge-grids)), so
items placed past the 10,000th track all land in it. A table laid out as a
grid (`kernel/src/layout/table.rs`, LLP 1153 D7.3) gives each row a track of
its own, and Chrome lays out a table of any length. An authored grid keeps
the limit, past which the kernel refuses its values (LLP 1001 §1).

`RareStyle::grid_line_limit` (read through
`GridContainerStyle::grid_line_limit`; 10,000 by default) is the highest
line, in OriginZero coordinates, at which a grid places an item, and the
largest span, up to `i16::MAX`. `LineLimit` carries it to everything that
read the constants: the conversion to OriginZero lines, the grid size
estimate, the placement of in-flow and absolutely positioned items, and the
detailed layout info (which takes the limit that covers its own lines). So
that every track index still fits an `i16`, the lowest line rises as the
highest passes 22,767; at `i16::MAX`, the kernel's value for a table, nothing
is placed before the explicit grid, where a table places nothing. Since a
line and a span may each reach `i16::MAX`, adding a span to a line saturates
(`OriginZeroLine` plus or minus a `u16`), and the result is clamped as
before. The `into_origin_zero*` methods of `GridPlacement`,
`Line<GridPlacement>`, `NonNamedGridPlacement` and `Line<NonNamedGridPlacement>`
take a `LineLimit`, which Taffy does not export, so only Taffy calls them.
The explicit grid's own limit of 10,000 tracks is unchanged.

Chrome for Testing 156.0.8078.4 lays 10,010 rows of `tr > td > div` (a 20 × 10
div) out with row 10,000 at y 140,002 and row 10,009 at 140,128, the table
140,142 tall; before the patch Exact put every row from 10,000 on at row
9,999's 139,988, the table 140,002 tall. On an Apple M5 Pro at the
`host-dev` profile, best of three, a first layout of 10,010 such rows takes
96 ms (98 before the patch), and of 30,000 rows 321 ms (313); a layout after
one cell's width changes takes 74 ms (75) and 238 ms (235).

**Held by** `kernel/tests/it/table.rs`'s
`a_tables_rows_past_ten_thousand_follow_each_other` (Chrome's frames above),
which failed before the patch, and
`compute::grid::placement::tests::test_placement_algorithm::a_raised_line_limit_places_rows_past_ten_thousand`
(a raised limit's lines, spans and lowest line, and the default limit's
placements unchanged). Every `browser_*` Chrome case and the layout-equality
comparisons pass unchanged.

## 71. Styles own their opaque calculation handles

`RareStyle::keep_calc` retains an evaluator's owner beside the style's raw
calculation handles, including grid tracks. Style clones share these owners;
the last drop releases them. Ordinary styles allocate no owner list. The
kernel uses weak hash indexes, so dropping a style can reclaim calculations
without invalidating a detached dimension or another retained style.

Held by the kernel's calculation reclamation and retained-style tests.