#54: on the phone, everything the app draws gets a grey box over its
bounding rect when it is tapped — the web view saying what it is — and
the issue additionally asks for user-select, touch-action, overscroll-behavior, press states and motion.
What changed, and why
The highlight is one inherited declaration. -webkit-tap-highlight-color is an inherited property and an
inherited property crosses a shadow boundary, so html { … : transparent } in index.css reaches every shadow root in the app and
no component needs a rule. Measured in the running app on app-sidebar's li button, three shadow roots from the document: rgba(0, 0, 0, 0.18) with the rule removed, rgba(0, 0, 0, 0) with
it. That 0.18 grey is the reported box.
The press state is part of removing it, not a later polish item.
With the highlight gone and no press rule, a row held down measures rgba(255, 255, 255, 0.05) — the hover tint, which on a phone is
synthesised by the hold itself and outlives it. So the four lists'
rows, bottom-nav's tabs, app-sidebar's destinations (which are also
the phone's "More" sheet) and the shared contextMenuStyles item take
a new --yj-press-overlay on :active. The cards already had one
(transform: scale(0.97)) and are untouched.
A press selector carries a state class. A row is .track-row.selected.active, so a bare .track-row:active is one
class short of it and the press would be invisible on exactly the row
a phone is most likely to press — the one it just selected. Measured
both ways: 0.12 while held on a selected row, neighbour unchanged.
And those surfaces' hover tints moved behind (hover: hover) and (pointer: fine) — #68's gate applied to a tint rather than to a
revealed control, for the same mechanism it was introduced for.
Deliberately not done, both argued on the issue:
user-select needed nothing: index.css's first rule is *, *::before, *::after { user-select: none }, which reaches the
shadow roots by the same inheritance. Recorded in NOTES.md so it is
not re-derived.
touch-action: manipulation. The 300ms delay it is offered for
is already absent on a width=device-width viewport, so the stated
benefit is not there to win; what it would change is the gesture
stack #63 tuned by measurement on the device (pan-y plus a
non-passive preventDefault), and that is not measurable from here.
overscroll-behavior on the app's scrollers: body cannot
scroll (overflow-y: hidden), so there is no chaining to contain,
and the one place it does matter — the "More" sheet's body — already
sets it. Nothing to win without a device to measure the glow on.
Motion and view transitions, the other half of the issue's title,
are filed as #213: this codebase already carries a measured
statement that transitions on these lists cost frames under software
rendering, and a view transition is a shell change interacting with
the history stack. Judging either needs the phone.
Verification
tier
result
make ui-test
1103 passed, incl. 11 new in test/components/press-feedback.test.ts
make e2e (chromium, dev-headless SEED=default)
241 passed, incl. 2 new in e2e/specs/native-touch-feel.spec.ts
npx tsc --noEmit, make css-check
clean
measured in the running app
424x439 and 1280x800, values below
screenshot
read, pressed row at 424x439
Both new files were proved non-vacuous. Reducing the press selector
to a bare :active fails the component tier's specificity case;
hoisting a hover tint out of its query fails the gating case. Reverting
the index.css rule and the row's press rule and rebuilding fails both
e2e cases, on rgba(0, 0, 0, 0.18) and rgba(255, 255, 255, 0.05) —
which is where the two measurements above come from.
Measured live: press 0.12 on a track row, on a selected track row, on
a bottom-nav tab and on a context-menu item; hover still 0.05 on the
desktop, where (hover: hover) and (pointer: fine) matches.
No Go, no .sql, no .templ, so make lint, make test, make generate and make bindings were not run. The device is not a
tier here — Chrome 113 on the reference phone is where a finger is,
and this change is only checkable there as pixels.
Commits
commit
issue
feat(android): the tap highlight goes, a press state replaces it
## The issue
#54: on the phone, everything the app draws gets a grey box over its
bounding rect when it is tapped — the web view saying what it is — and
the issue additionally asks for `user-select`, `touch-action`,
`overscroll-behavior`, press states and motion.
## What changed, and why
**The highlight is one inherited declaration.**
`-webkit-tap-highlight-color` is an *inherited* property and an
inherited property crosses a shadow boundary, so `html { … :
transparent }` in `index.css` reaches every shadow root in the app and
no component needs a rule. Measured in the running app on
`app-sidebar`'s `li button`, three shadow roots from the document:
`rgba(0, 0, 0, 0.18)` with the rule removed, `rgba(0, 0, 0, 0)` with
it. That 0.18 grey is the reported box.
**The press state is part of removing it, not a later polish item.**
With the highlight gone and no press rule, a row held down measures
`rgba(255, 255, 255, 0.05)` — the *hover* tint, which on a phone is
synthesised by the hold itself and outlives it. So the four lists'
rows, `bottom-nav`'s tabs, `app-sidebar`'s destinations (which are also
the phone's "More" sheet) and the shared `contextMenuStyles` item take
a new `--yj-press-overlay` on `:active`. The cards already had one
(`transform: scale(0.97)`) and are untouched.
**A press selector carries a state class.** A row is
`.track-row.selected.active`, so a bare `.track-row:active` is one
class short of it and the press would be invisible on exactly the row
a phone is most likely to press — the one it just selected. Measured
both ways: 0.12 while held on a selected row, neighbour unchanged.
**And those surfaces' hover tints moved behind `(hover: hover) and
(pointer: fine)`** — #68's gate applied to a tint rather than to a
revealed control, for the same mechanism it was introduced for.
Deliberately **not** done, both argued on the issue:
- **`user-select`** needed nothing: `index.css`'s first rule is
`*, *::before, *::after { user-select: none }`, which reaches the
shadow roots by the same inheritance. Recorded in `NOTES.md` so it is
not re-derived.
- **`touch-action: manipulation`.** The 300ms delay it is offered for
is already absent on a `width=device-width` viewport, so the stated
benefit is not there to win; what it *would* change is the gesture
stack #63 tuned by measurement on the device (`pan-y` plus a
non-passive `preventDefault`), and that is not measurable from here.
- **`overscroll-behavior`** on the app's scrollers: `body` cannot
scroll (`overflow-y: hidden`), so there is no chaining to contain,
and the one place it does matter — the "More" sheet's body — already
sets it. Nothing to win without a device to measure the glow on.
- **Motion and view transitions**, the other half of the issue's title,
are filed as **#213**: this codebase already carries a measured
statement that transitions on these lists cost frames under software
rendering, and a view transition is a shell change interacting with
the history stack. Judging either needs the phone.
## Verification
| tier | result |
|---|---|
| `make ui-test` | **1103 passed**, incl. 11 new in `test/components/press-feedback.test.ts` |
| `make e2e` (chromium, `dev-headless SEED=default`) | **241 passed**, incl. 2 new in `e2e/specs/native-touch-feel.spec.ts` |
| `npx tsc --noEmit`, `make css-check` | clean |
| measured in the running app | 424x439 and 1280x800, values below |
| screenshot | read, pressed row at 424x439 |
**Both new files were proved non-vacuous.** Reducing the press selector
to a bare `:active` fails the component tier's specificity case;
hoisting a hover tint out of its query fails the gating case. Reverting
the `index.css` rule and the row's press rule and rebuilding fails both
e2e cases, on `rgba(0, 0, 0, 0.18)` and `rgba(255, 255, 255, 0.05)` —
which is where the two measurements above come from.
Measured live: press 0.12 on a track row, on a *selected* track row, on
a `bottom-nav` tab and on a context-menu item; hover still 0.05 on the
desktop, where `(hover: hover) and (pointer: fine)` matches.
No Go, no `.sql`, no `.templ`, so `make lint`, `make test`,
`make generate` and `make bindings` were not run. **The device is not a
tier here** — Chrome 113 on the reference phone is where a finger is,
and this change is only checkable there as pixels.
## Commits
| commit | issue |
|---|---|
| `feat(android): the tap highlight goes, a press state replaces it` | #54 |
Filed while here: **#213** (the motion half, judged on the device).
Closes #54
Worth reading the WebKit number rather than taking the tick: the 2 skips are the pre-existing swipe cases (touch-gestures.spec.ts, no TouchEvent constructor on desktop WebKit) — the same 2 as the previous e2e run on main's baseline, which was 238 passed. So both new cases passed on WebKit too, which answers the one thing this spec hedged on: -webkit-tap-highlight-color is reported and transparent there as well, so the test.skip guard for an engine that does not report the property is unused today. It stays, because the property is a WebKit extension only iOS honours and an engine is entitled not to expose it; nothing this app does can trigger the guard.
**CI is green**, both jobs, on `cfec242`.
- `CI / check` — [run 17762, job 29062](/yonlu/yellowjacket/actions/runs/17762/jobs/29062): lint, tests in all three build configurations, `tsc --noEmit`, `make ui-test` (1103), bindings and skill checks.
- `CI / e2e` — [job 29063](/yonlu/yellowjacket/actions/runs/17762/jobs/29063): **chromium 241 passed**, **WebKit 239 passed / 2 skipped**.
Worth reading the WebKit number rather than taking the tick: the 2 skips are the pre-existing swipe cases (`touch-gestures.spec.ts`, no `TouchEvent` constructor on desktop WebKit) — the same 2 as the previous e2e run on `main`'s baseline, which was 238 passed. So **both new cases passed on WebKit too**, which answers the one thing this spec hedged on: `-webkit-tap-highlight-color` is reported and transparent there as well, so the `test.skip` guard for an engine that does not report the property is unused today. It stays, because the property is a WebKit extension only iOS honours and an engine is entitled not to expose it; nothing this app does can trigger the guard.
The phone drew a grey box over the bounding rect of whatever was
tapped, which is the web view saying what it is. It is gone in one
declaration: `-webkit-tap-highlight-color` is inherited and an
inherited property crosses a shadow boundary, so `html` in index.css
reaches every shadow root in the app. Measured three roots deep,
rgba(0, 0, 0, 0.18) before and rgba(0, 0, 0, 0) after.
Removing it removes the only touch feedback several surfaces had, so
the press state is part of the same change rather than a later polish
item — with the highlight gone a held row measured the *hover* tint,
which on a phone is synthesised by the hold itself and outlives it.
The four lists' rows, the tab bar, the sidebar's destinations and the
shared context-menu item take --yj-press-overlay on :active; the cards
already had scale(0.97). The press selector carries a state class
because a row is .track-row.selected.active, so a bare :active shows
nothing on the row a phone is most likely to press. And those
surfaces' hover tints move behind (hover: hover) and (pointer: fine),
which is #68's gate applied to a tint rather than a revealed control.
user-select, the other half of the Findings, was already done: the
first rule in index.css covers the shadow roots for the same reason.
touch-action: manipulation is declined — the 300ms delay it is offered
for is already absent on a width=device-width viewport, and what it
would really change is the gesture stack tuned by measurement on a
device this session cannot measure.
Closes#54
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The issue
#54: on the phone, everything the app draws gets a grey box over its
bounding rect when it is tapped — the web view saying what it is — and
the issue additionally asks for
user-select,touch-action,overscroll-behavior, press states and motion.What changed, and why
The highlight is one inherited declaration.
-webkit-tap-highlight-coloris an inherited property and aninherited property crosses a shadow boundary, so
html { … : transparent }inindex.cssreaches every shadow root in the app andno component needs a rule. Measured in the running app on
app-sidebar'sli button, three shadow roots from the document:rgba(0, 0, 0, 0.18)with the rule removed,rgba(0, 0, 0, 0)withit. That 0.18 grey is the reported box.
The press state is part of removing it, not a later polish item.
With the highlight gone and no press rule, a row held down measures
rgba(255, 255, 255, 0.05)— the hover tint, which on a phone issynthesised by the hold itself and outlives it. So the four lists'
rows,
bottom-nav's tabs,app-sidebar's destinations (which are alsothe phone's "More" sheet) and the shared
contextMenuStylesitem takea new
--yj-press-overlayon:active. The cards already had one(
transform: scale(0.97)) and are untouched.A press selector carries a state class. A row is
.track-row.selected.active, so a bare.track-row:activeis oneclass short of it and the press would be invisible on exactly the row
a phone is most likely to press — the one it just selected. Measured
both ways: 0.12 while held on a selected row, neighbour unchanged.
And those surfaces' hover tints moved behind
(hover: hover) and (pointer: fine)— #68's gate applied to a tint rather than to arevealed control, for the same mechanism it was introduced for.
Deliberately not done, both argued on the issue:
user-selectneeded nothing:index.css's first rule is*, *::before, *::after { user-select: none }, which reaches theshadow roots by the same inheritance. Recorded in
NOTES.mdso it isnot re-derived.
touch-action: manipulation. The 300ms delay it is offered foris already absent on a
width=device-widthviewport, so the statedbenefit is not there to win; what it would change is the gesture
stack #63 tuned by measurement on the device (
pan-yplus anon-passive
preventDefault), and that is not measurable from here.overscroll-behavioron the app's scrollers:bodycannotscroll (
overflow-y: hidden), so there is no chaining to contain,and the one place it does matter — the "More" sheet's body — already
sets it. Nothing to win without a device to measure the glow on.
are filed as #213: this codebase already carries a measured
statement that transitions on these lists cost frames under software
rendering, and a view transition is a shell change interacting with
the history stack. Judging either needs the phone.
Verification
make ui-testtest/components/press-feedback.test.tsmake e2e(chromium,dev-headless SEED=default)e2e/specs/native-touch-feel.spec.tsnpx tsc --noEmit,make css-checkBoth new files were proved non-vacuous. Reducing the press selector
to a bare
:activefails the component tier's specificity case;hoisting a hover tint out of its query fails the gating case. Reverting
the
index.cssrule and the row's press rule and rebuilding fails bothe2e cases, on
rgba(0, 0, 0, 0.18)andrgba(255, 255, 255, 0.05)—which is where the two measurements above come from.
Measured live: press 0.12 on a track row, on a selected track row, on
a
bottom-navtab and on a context-menu item; hover still 0.05 on thedesktop, where
(hover: hover) and (pointer: fine)matches.No Go, no
.sql, no.templ, somake lint,make test,make generateandmake bindingswere not run. The device is not atier here — Chrome 113 on the reference phone is where a finger is,
and this change is only checkable there as pixels.
Commits
feat(android): the tap highlight goes, a press state replaces itFiled while here: #213 (the motion half, judged on the device).
Closes #54
CI is green, both jobs, on
cfec242.CI / check— run 17762, job 29062: lint, tests in all three build configurations,tsc --noEmit,make ui-test(1103), bindings and skill checks.CI / e2e— job 29063: chromium 241 passed, WebKit 239 passed / 2 skipped.Worth reading the WebKit number rather than taking the tick: the 2 skips are the pre-existing swipe cases (
touch-gestures.spec.ts, noTouchEventconstructor on desktop WebKit) — the same 2 as the previous e2e run onmain's baseline, which was 238 passed. So both new cases passed on WebKit too, which answers the one thing this spec hedged on:-webkit-tap-highlight-coloris reported and transparent there as well, so thetest.skipguard for an engine that does not report the property is unused today. It stays, because the property is a WebKit extension only iOS honours and an engine is entitled not to expose it; nothing this app does can trigger the guard.cfec242e33to3aa2a434b4