mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-24 03:16:43 +00:00
xarmian
74813fcc72
* Revert "feat(web): dissolve the item action bar into a new .tab-strip wrapper (TASK-2328) (#1033)" This reverts commit10a5ae2271. * fix(web): action bar holds one row and compresses to the container width The band was `flex-wrap: wrap` with a hard `min-width: 70px` per button, so five controls (star + quick actions + children + backlinks + overflow) needed ~340px and wrapped to a second row in any pane narrower than that. Replace the hard floor with `flex: 0 1 70px` scoped to `.meta-actions`: the 70px basis reproduces the old width when there is room, so nothing moves on a wide container, and `min-width: auto` bounds the shrink at each button's own label rather than clipping it. The graph drawer's `.action-btn`s keep the plain floor — their labels are wider than 70px. `.menu-anchor` and `.quick-actions-menu` become flex so the ⋯ / ⚡ triggers they wrap participate in the compression instead of sitting at block min-content. Below a 340px band a container query reclaims 4px of inline padding per side, which covers the 312px pane minimum (the draggable floor) with the full control set — measured 0 overflow there, and 0 with a 3-digit child count. Deliberately not `overflow-x: auto`: an invisible scrollport is what made controls silently unreachable in TASK-2328. Also narrows the button `transition: all 0.1s` to the three hover properties. Now that width is container-derived, `all` animated padding during a pane drag. Measured in Chromium at 264-912px band widths: no wrap and no clipped label at any width; anchored ⋯ menu still escapes the new container (panel renders 162px below the band); mobile BottomSheet still resolves against the viewport (390x844) rather than the container, for both the ⋯ and ⚡ menus. Gates: svelte-check 0 errors, 490 vitest, 39 e2e across the five specs that drive these controls. * fix(web): one width and one height for every action-bar control The ⚡ quick-actions trigger belongs to QuickActionsMenu and never carried `.action-btn`, so it rendered 41x22 beside its neighbours' 70x26 — a different width AND height, which is what read as awkward. Give its wrapper the same 70px basis, let the trigger fill it, and set the band's box metrics in one place instead of two. The ⋯ overflow trigger is the deliberate exception and now sizes to its glyph (38px). That needs `min-width: auto` as well as the flex change: `.action-btn`'s base `min-width: 70px` reaches it as a grandchild, so the direct-child override missed it and a 70px floor held it wide regardless of flex-basis. Pin `line-height: 1.35` so glyph metrics stop leaking into the height — "⋯" and "☆" resolved 1px apart, which `align-items: center` then showed as a misaligned row — and take block padding to `--space-2` for the requested ~30% more height: 26.1px -> 34.1px (+30.7%). Measured at 216-864px band widths: one height (34.1px) everywhere, no wrap and no clipped label at any width, ⋯ exempt at 38px. Uniform width holds wherever the row has slack; below ~382px the controls necessarily diverge as each compresses toward its own label, and a label wider than 70px (a 3-digit child count) still grows past the basis rather than truncating. Gates: svelte-check 0 errors, 490 vitest, 39 e2e. * fix(web): harden the ⚡ wrapper selector + pin the sheet-containment invariant Codex review findings on92f8a6e2/5bd799aa. P2 (real): `.meta-actions :global(.quick-actions-menu)` was (0,2,0), exactly tying QuickActionsMenu's own scoped `.quick-actions-menu.svelte-<hash>` `display: inline-block`. Cross-file stylesheet order was the only thing making `display: flex` win, so a chunking change could silently restore inline-block: the wrapper would keep the 70px basis while the ⚡ inside snapped back to intrinsic width, undoing the uniform width and shrinking the touch target. The `div` qualifier takes it to (0,2,1) and wins outright. P1 (refuted, then pinned): Codex read the Containment spec to mean `container-type: inline-size` establishes a fixed-position containing block, so the mobile BottomSheet — a non-portaled `position: fixed` descendant of the band — would collapse into a ~342x34 strip. Measured in Chromium it does not: the overlay is confirmed a DOM descendant of `.meta-actions[container-type: inline-size]` and still resolves to the full 390x844 viewport, for both the ⋯ and ⚡ menus. Since that rests on engine behaviour rather than a guarantee, add e2e coverage instead of just asserting it. The new spec checks the premise (band really is a query container, and much smaller than the viewport) before the invariant, and fails loudly rather than vacuously if BottomSheet ever starts portaling. Mutation-tested: adding `contain: layout` to the band collapses the overlay to the band's width and the test fails with "overlay spans the viewport width" (expected 412, received 364) — which also demonstrates `contain: layout` and `container-type: inline-size` are NOT equivalent here. The same spec pins the uniform width/height and the no-wrap, no-clip invariants on desktop. jsdom computes no layout, so none of this is unit-testable. * docs(web): correct the containment claim; cover both menus in the sheet test Codex nit, and it changes the mechanism rather than just the wording. `container-type: inline-size` applies STYLE and INLINE-SIZE containment, not layout containment (css-conditional-5 §container-type). Layout containment is what establishes a fixed-position containing block, so the mobile sheet is safe BY SPEC, not by engine luck — my comment and the spec header both repeated PLAN-2326 DR-3's claim that `inline-size` implies `contain: layout style inline-size`, which is wrong, and wrong in the direction that makes an unsafe change look safe. Codex reached its P1 from the same bad premise. Reframed accordingly: the standing hazard is not a future engine, it's someone adding `contain: layout` (or a transform/filter) to this band later. Both comments now say that explicitly. The sheet test also only drove the ⋯ menu while the commit message claimed both. It now loops over ⋯ and ⚡ — separate wrappers with separate styling, so one does not establish the other — and throws rather than skipping if the ⚡ trigger is missing on an owner-viewed item. * fix(web): put the action-bar control height back to 26.1px The ~30% taller controls (34.1px, --space-2 block padding) were rejected on review — desktop first, then mobile too. Back to --space-1 and the band's original 26.1px on every surface, so no per-breakpoint split is needed. The uniform sizing from5bd799aastays: all four controls are one height rather than the 26/22/25 they were before, and the ⚡ trigger still matches its neighbours instead of sitting 4px short.