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.