Merge pull request 'fix(ui): the phone's nav sheet says when it scrolls' (#222) from fix/210-nav-sheet-scroll-affordance into main
This commit was merged in pull request #222.
This commit is contained in:
@@ -4,6 +4,7 @@ import '@awesome.me/webawesome/dist/components/icon/icon.js';
|
||||
import '@awesome.me/webawesome/dist/components/drawer/drawer.js';
|
||||
import type WaDrawer from '@awesome.me/webawesome/dist/components/drawer/drawer.js';
|
||||
import { designTokens } from '../../styles/tokens.css';
|
||||
import { sheetScrollFade } from '../../styles/sheet-scroll.css';
|
||||
import '../sidebar/app-sidebar.js';
|
||||
import { nameDialog } from '@utils/name-dialog';
|
||||
import { ICON_PLAYLIST } from '@utils/icon-language';
|
||||
@@ -167,6 +168,15 @@ export class BottomNav extends LitElement {
|
||||
overflow: hidden;
|
||||
}
|
||||
|
||||
/* And this list does not fit (#210): measured at 424x439 with
|
||||
the seed's eight destinations, the body is scrollHeight 412
|
||||
against clientHeight 373, and eleven items at 48px would be
|
||||
528 -- the count is the user's since #25. So the sheet says
|
||||
where the fold is, with styles/sheet-scroll.css's two layers
|
||||
rather than a second answer to the question #207 settled for
|
||||
the context sheet. The colour is the local half: the sidebar
|
||||
paints --yj-bg-surface, so the cover does too, or the fade
|
||||
draws the menus' grey across the bottom of this one. */
|
||||
wa-drawer::part(body) {
|
||||
padding: 0;
|
||||
/* A scroll that reaches the end of this list must not
|
||||
@@ -177,6 +187,23 @@ export class BottomNav extends LitElement {
|
||||
on a gesture-navigation phone -- the same allowance the
|
||||
bar itself makes above. */
|
||||
padding-bottom: env(safe-area-inset-bottom, 0);
|
||||
--yj-sheet-surface: var(--yj-bg-surface, #212529);
|
||||
${sheetScrollFade}
|
||||
}
|
||||
|
||||
/* And the sheet paints that surface once. The sidebar's host
|
||||
paints the same grey -- which in the shell is the sidebar's
|
||||
own background and here is a second, opaque copy of the
|
||||
sheet's, drawn *over* the body's layers. So the fade was
|
||||
painted and then covered: measured at 424x439 before this
|
||||
rule, the last 32px read a flat 52,58,64 with 39px still
|
||||
below. menu-surface meets the same requirement from the
|
||||
other side, where .context-menu-panel[data-sheet] is
|
||||
background-color: transparent; nothing changes visually
|
||||
here, because the colour underneath is the one being
|
||||
removed. */
|
||||
app-sidebar {
|
||||
background-color: transparent;
|
||||
}
|
||||
|
||||
/* A sheet is dragged at with a thumb, so it says where its top
|
||||
|
||||
@@ -65,6 +65,7 @@ import '@awesome.me/webawesome/dist/components/popup/popup.js';
|
||||
import '@awesome.me/webawesome/dist/components/dialog/dialog.js';
|
||||
import type WaPopup from '@awesome.me/webawesome/dist/components/popup/popup.js';
|
||||
|
||||
import { sheetScrollFade } from '../../styles/sheet-scroll.css';
|
||||
import { PHONE_QUERY } from '@utils/breakpoints';
|
||||
import { nameDialogsIn } from '@utils/name-dialog';
|
||||
|
||||
@@ -164,46 +165,17 @@ export class MenuSurface extends LitElement {
|
||||
and worse when the cut lands on a row boundary, where the
|
||||
sheet ends in a clean edge that reads as the end of the list.
|
||||
|
||||
Two layers, and the *order* is what asks the question: a
|
||||
shadow pinned to the bottom of the box (attachment scroll),
|
||||
and over it a cover of the sheet's own colour painted at the
|
||||
end of the *content* (attachment local), which therefore
|
||||
scrolls up over the shadow and hides it exactly when there is
|
||||
nothing more to see. So the affordance 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, no
|
||||
measurement, and nothing reaching into wa-dialog's shadow
|
||||
root for the scroller. background-attachment is Chrome 4;
|
||||
the reference device is Chrome 113.
|
||||
|
||||
**The curve is steep because the rows under it stay live.**
|
||||
A scrim over a menu item is that item's text surface, and
|
||||
this app's rule is that text clears 4.5:1 on every surface it
|
||||
can sit on -- which the light ramp, whose bgElevated is
|
||||
#e9ecef, is what makes non-theoretical. A row is 48px with
|
||||
its label centred, so 32px of scrim that is already down to
|
||||
a quarter strength at 14px reaches y-centre at about 0.06 and
|
||||
spends its weight on the strip below the last legible label.
|
||||
Measured on the dark ramp at x=300, flat 52,58,64 throughout
|
||||
before: 50,56,62 at y=330, 33,37,40 at y=350 and 22,24,27 at
|
||||
the bottom edge, and flat again at the end of the list. The
|
||||
light ramp puts 9.9:1 on the last label. */
|
||||
The two layers that say it live in styles/sheet-scroll.css
|
||||
(#210), because the phone has a second sheet -- bottom-nav's
|
||||
"More" -- which overflows for the same reason and must not
|
||||
arrive at its own answer for what a fold looks like. What is
|
||||
local to this sheet is the colour the cover is painted in:
|
||||
the menus' elevated grey, handed over as --yj-sheet-surface
|
||||
on the same box. */
|
||||
wa-dialog::part(body) {
|
||||
padding: 0;
|
||||
overflow-y: auto;
|
||||
background:
|
||||
linear-gradient(
|
||||
var(--yj-bg-elevated, #343a40),
|
||||
var(--yj-bg-elevated, #343a40)
|
||||
)
|
||||
bottom / 100% 32px no-repeat local,
|
||||
linear-gradient(
|
||||
to top,
|
||||
rgba(0, 0, 0, 0.6) 0%,
|
||||
rgba(0, 0, 0, 0.25) 45%,
|
||||
rgba(0, 0, 0, 0) 100%
|
||||
)
|
||||
bottom / 100% 32px no-repeat scroll;
|
||||
--yj-sheet-surface: var(--yj-bg-elevated, #343a40);
|
||||
${sheetScrollFade}
|
||||
}
|
||||
|
||||
/* A sheet is dragged at with a thumb, so it says where its top
|
||||
|
||||
Reference in New Issue
Block a user