---
enabled: true
touches: [crates/layout/src/fragment.rs]
depends-on: []
---

# Default `layout_with_resolver` to the generated absolute resolver

`absolute-batches`'s review (already landed) noted one non-disqualifying gap:
`layout_with_resolver` in `crates/layout/src/fragment.rs` still hardcodes
`crate::absolute::resolve_baseline` for the absolute seam when the caller doesn't
override it, instead of `generated::absolute::resolve` — the candidate `layout()`
already defaults to. `generated` is already imported (`use crate::generated;`) and
`generated::absolute` is already `pub`; this is a one-line change, no new imports,
no signature or type changes. `layout_with_resolvers` (plural) has no defaults to
change — every one of its five resolver parameters is a required argument, so the
fix is entirely inside `layout_with_resolver` (singular).

`layout_with_resolver`'s doc comment currently says margin collapsing, percentage
resolution and absolute positioning all stay on their own baselines. Absolute no
longer will; update the comment to say so, and that margin/percentage still do.

Add a regression test in `crates/layout/src/fragment.rs`'s own `#[cfg(test)] mod
tests`, modeled on `layout_correct`'s shape: call `layout_with_resolver` with no
absolute override, on a fixture with `position: absolute` and an explicit
`left`/`top`, and assert the box lands where the generated resolver puts it (honors
`left`/`top`) rather than where baseline would (ignores them, uses the static
position) — the same contrast `crates/generation/src/absolute_runner.rs`'s
`baseline_ignores_an_explicit_left_and_uses_the_static_position` and
`a_candidate_that_reads_left_and_top_resolves_them_against_the_containing_block`
already draw between baseline and an override.

`fragment_check` only ever calls plain `layout()` (already generated-by-default),
never `layout_with_resolver`/`layout_with_resolvers`, and the 227-case corpus it
runs has no absolute-positioning category at all — absolute cases live in the
separate `absolute_cases.rs`/`absolute-ground-truth` corpus. So `cargo test
--workspace` passing and `fragment_check --random` staying at 216/227 with every
category unchanged is the verify condition, and there is no path by which this
change could move that number; run both anyway to confirm rather than reasoning
about it.