49445ded77be8fdad526d9e55a663a378ef6a1b7
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 logan
|
20c337651f |
fix(ui): the phone's nav sheet says when it scrolls
Since #71 the phone's "More" is a bottom sheet, and at the reference viewport it does not fit: measured at 424x439 with the seed's eight destinations, the body is scrollHeight 412 against clientHeight 373, so 39px is below a fold nothing announces. Where the cut lands on a row boundary the sheet ends in a clean edge that reads as the end of the list, which is what #207 fixed one sheet over. The rule is that sheet's, not a second answer to the same question: #207's two background layers move into styles/sheet-scroll.css.ts and both sheets adopt them, with the colour left to each host as --yj-sheet-surface. The nav sheet paints the sidebar's --yj-bg-surface and the context sheet the menus' --yj-bg-elevated, so a shared rule that hard-coded either would draw that seam across the other one. The half that makes it visible is that nothing inside the sheet may repaint the surface. These are layers on the scroller, and app-sidebar's host carries the same grey -- in the shell its own background, in the sheet a second opaque copy of the sheet's, over the fade. With the fragment adopted and that rule missing, the running app measured a flat 52,58,64 to the bottom edge with 39px still below: the defect unchanged, with every assertion about background-attachment passing. menu-surface already meets it from the other side, where the sheet's panel is background-color: transparent. Closes #210 |
||
|
logan
|
8c85db8968 |
docs(ui): quote the shipped fade's own measurement
The comment on `wa-dialog::part(body)` carried bottom-edge pixels from an intermediate probe (29,33,36) while `.planning/NOTES.md` recorded the final sample against the shipped rule (22,24,27) — the same gradient, read a few pixels higher up the box. A measurement written in two places has to agree, or neither can be trusted. |
||
|
logan
|
02e2251bb2 |
fix(ui): the phone's context sheet says when it scrolls
The bottom sheet's body has scrolled since #60 and said nothing about it. Measured at 424x439, the track list's menu ended at y=470 with the fold at 439 — reachable, since the body is `overflow-y: auto`, but with no affordance saying so, and worst where the cut lands on a row boundary and the sheet ends in a clean edge that reads as the end of the list. The cap stays: `menu-surface`'s own comment says a surface covering the whole screen is a page, not a sheet. What changes is that the body draws a fade, from two background layers whose *attachments* are the feature — a shadow pinned to the box (`scroll`) under a cover of the sheet's own colour painted at the end of the content (`local`), which scrolls up over the shadow exactly when there is nothing more to see. So the fade is absent on a menu that fits, present the moment one does not, and gone again at the end of the list, with no scroll listener and nothing reaching into `wa-dialog`'s shadow root for the scroller. `background-attachment` is Chrome 4; the reference device is Chrome 113. The other two options in the report — a shortened last row, or a max height that makes the cut obvious — both need `height mod 48`, which CSS cannot express, and the observed case is exactly the one where the cut already lands on a row boundary. The curve is steep rather than linear because the rows under it stay live: a scrim over a menu item is that item's text surface, so the 4.5:1 rule reaches it, and the light ramp is what makes that real. A 48px linear scrim at 0.8 greyed the last label to 5.0:1; 32px already down to a quarter strength at 14px measures 9.9:1 there and spends its weight on the strip below it. The test asserts the pair of attachments rather than the pixels, on this file's existing grounds that no tier here renders like the device — it fails on the pre-fix stylesheet with `expected 'scroll' to be 'local, scroll'`. The rendered result was measured in the harness and is recorded in `.planning/NOTES.md`. Closes #207 |
||
|
logan
|
9aaa8beb99 |
feat(shell): draw a context menu where it fits, not where it is anchored
On the reference device every context menu in the app is clipped, and the two halves of that are structural rather than incidental. Chrome 113 has no Popover API, so wa-popup takes its own documented fallback and positions with strategy: "fixed"; .main-panel carries contain: layout style paint, and paint containment clips fixed descendants. Measured at 424x439 before any of this: the main panel spans 0-318, the open menu spanned 191-401, and three of its seven items were cut off with no way to reach them. Rows were 29px against a 44px floor. menu-surface is one element with two presentations -- a wa-popup above 600px, a wa-dialog bottom sheet below it -- so the host keeps rendering the panel it always rendered and ContextMenuController keeps driving .active and .anchor as though it were talking to a popup. showModal() is Chrome 37 and uses the real top layer, so the sheet is immune by construction rather than by styling. Four things needed measuring on the hardware rather than reading. "A dialog escapes containment" was the premise and was untested here: every other dialog in this app is mounted in index.html, outside .main-panel. A probe dialog appended to track-list's shadow root paints to y=439, over the mini player and the tab bar. A native dialog's UA stylesheet centres it and caps its width, which drew a 354px panel in the middle of a 424px screen -- so four declarations in this component are pure undoing. wa-dialog focuses [autofocus] or itself on the frame after showModal(), and it cannot see our first menu item to prefer it: the panel is slotted, so its own querySelector stops at the <slot>. A longer retry budget does not fix that, because the first attempt succeeds and is then overwritten -- hence menu-shown and MenuKeyboard.refocus(). The budget became time-based anyway, since what is being waited for is another component's animation. And a dismissal has to travel back: wa-dialog closes itself on Escape, which would leave the controller believing the menu is open. The failure mode there is not a stuck sheet but the *next* long-press doing nothing, which reads as the gesture breaking. |