#56 named 44px and the queue header keeps it; nothing else was resized.
So the controls a user meets on every screen were between a third and
two thirds of the app's own floor. On the device at 424x439: page-sort 99x23, page-sort-direction28x21, page-actions-more
38x27, search-trigger 40x40.
Both open questions, answered by one measurement
The issue leaves two things "to decide rather than assume". The header
is 63px tall with 20–23px controls, so the vertical room was already
there; the select and its arrow are 6px apart, so the horizontal room
was not.
That makes this min-size, not padding with a negative margin — which
is what the seek bar needed in #187, and the difference decides the
rest. There the painted track had to stay thin, so the target grew past
its own box and had to be checked against its neighbours. Here the
control is the target: the boxes are flex items, so the gap keeps
them apart and no two targets can overlap by construction.
Not phone-only. A 44px control on a desktop is merely large, and
a second declaration of what a phone shows is a second thing to keep
in step — which is why this component has never had one. It also
avoids a media query no tier renders, which is exactly how the seek
bar's phone rule came to be dead for months (#187).
#69's fit does not move. That pass measures inline size, so the
height costs it nothing; only the two square controls grow the
content, by 22px total. header-action-overflow.spec.ts passes
unchanged at all four widths — the check, not the assumption. I also
verified on the device that the count is still shown at 424px, so
nothing has started yielding. (It is absent on Playlists for an
unrelated and documented reason: the count is null until there is
an answer.)
search-trigger is the sharpest case
#57 created it as the phone's replacement for the header search box, so
it exists only where there is a thumb — and it shipped at 40x40 under
a comment calling that "the smallest a touch target should be". That
was the floor restated four pixels short rather than a second opinion
about it. Both the number and the comment are fixed.
Verification
On the device: every control in the header is now ≥44x44 — page-sort 99x44, page-sort-direction 44x44, page-actions-more
44x44, the action buttons 168x44, search-trigger 44x44.
make ui-test (1014, +3), make e2e (236, chromium — webkit is
CI's), make css-check, make bindings-check, make skill-check, tsc --noEmit in both packages. make lint/make test are
formalities: no Go changed.
All three assertions proved to bite, failing with the device's own
numbers — page-sort-direction 29x21, 38, 40.
Unlike #187, this is measured rather than inferred from the stylesheet:
the controls are plain elements and the rule is a min-size, so it
holds at every width and a real Chromium rendering a real page-header
gives the actual answer.
What is deliberately not here
#186 stays open. This is the Direction's first step — the one it
says "covers five views at once and is the obvious place to start". config-field's 93 Settings controls and explore-view's search row
are the second pass. Settings is a form with one shape for every row,
so it is close to a one-rule change, but it makes every row on a long
page taller on a 439px screen — a density argument that deserves its
own pass and the visual suite, not a footnote in this one.
One thing found on the way that is not in the issue's tables: the skip link is 147x35. It is keyboard-only and unreachable by touch,
so it is not a touch-target defect — noted so the next pass does not
spend time rediscovering it.
| commit | issue |
|---|---|
| `fix(shell): raise the page header's controls to the touch floor` | #186 (first pass — **stays open**) |
#56 named 44px and the queue header keeps it; nothing else was resized.
So the controls a user meets on *every* screen were between a third and
two thirds of the app's own floor. On the device at 424x439:
`page-sort` 99x23, `page-sort-direction` **28x21**, `page-actions-more`
38x27, `search-trigger` 40x40.
## Both open questions, answered by one measurement
The issue leaves two things "to decide rather than assume". The header
is **63px tall with 20–23px controls**, so the vertical room was already
there; the select and its arrow are **6px apart**, so the horizontal room
was not.
That makes this `min-size`, not padding with a negative margin — which
is what the seek bar needed in #187, and the difference decides the
rest. There the painted track had to stay thin, so the target grew past
its own box and had to be checked against its neighbours. **Here the
control *is* the target**: the boxes are flex items, so the gap keeps
them apart and no two targets can overlap by construction.
1. **Not phone-only.** A 44px control on a desktop is merely large, and
a second declaration of what a phone shows is a second thing to keep
in step — which is why this component has never had one. It also
avoids a media query no tier renders, which is exactly how the seek
bar's phone rule came to be dead for months (#187).
2. **#69's fit does not move.** That pass measures *inline* size, so the
height costs it nothing; only the two square controls grow the
content, by 22px total. `header-action-overflow.spec.ts` passes
unchanged at all four widths — the check, not the assumption. I also
verified on the device that the count is **still shown at 424px**, so
nothing has started yielding. (It is absent on Playlists for an
unrelated and documented reason: the count is `null` until there is
an answer.)
## search-trigger is the sharpest case
#57 created it as the phone's replacement for the header search box, so
it exists *only* where there is a thumb — and it shipped at 40x40 under
a comment calling that *"the smallest a touch target should be"*. That
was the floor restated four pixels short rather than a second opinion
about it. Both the number and the comment are fixed.
## Verification
- **On the device**: every control in the header is now ≥44x44 —
`page-sort` 99x44, `page-sort-direction` 44x44, `page-actions-more`
44x44, the action buttons 168x44, `search-trigger` 44x44.
- `make ui-test` (1014, +3), `make e2e` (236, chromium — webkit is
CI's), `make css-check`, `make bindings-check`, `make skill-check`,
`tsc --noEmit` in both packages. `make lint`/`make test` are
formalities: no Go changed.
- **All three assertions proved to bite**, failing with the device's own
numbers — `page-sort-direction 29x21`, `38`, `40`.
Unlike #187, this is measured rather than inferred from the stylesheet:
the controls are plain elements and the rule is a `min-size`, so it
holds at every width and a real Chromium rendering a real `page-header`
gives the actual answer.
## What is deliberately not here
**#186 stays open.** This is the Direction's first step — the one it
says "covers five views at once and is the obvious place to start".
`config-field`'s 93 Settings controls and `explore-view`'s search row
are the second pass. Settings is a form with one shape for every row,
so it is close to a one-rule change, but it makes every row on a long
page taller on a 439px screen — a density argument that deserves its
own pass and the visual suite, not a footnote in this one.
One thing found on the way that is not in the issue's tables: the
**skip link is 147x35**. It is keyboard-only and unreachable by touch,
so it is not a touch-target defect — noted so the next pass does not
spend time rediscovering it.
#56 sized the playback transport for a thumb and named 44px; the queue
header keeps it. Nothing else was resized, so the controls a user meets
on *every* screen sat between a third and two thirds of the app's own
floor. Measured on the reference device at 424x439: page-sort 99x23,
page-sort-direction **28x21**, page-actions-more 38x27, and
search-trigger 40x40.
**Both questions the issue left open are answered by one measurement.**
The header is 63px tall and its controls are 20-23px, so the vertical
room was already there; the select and its direction arrow are 6px
apart, so the horizontal room was not.
That makes this min-size rather than padding with a negative margin,
which is what the seek bar needed (#187), and the difference decides
everything else. There the painted track had to stay thin, so the
target was grown past its own box and had to be checked against its
neighbours. Here the control *is* the target: the boxes are flex items,
so the gap keeps them apart and **no two targets can overlap by
construction**.
From which:
**There is no phone branch.** A 44px control on a desktop is merely
large, and a second declaration of what a phone shows is a second thing
to keep in step -- which is why this component has never had one. It
also avoids a media query no tier here renders, which is exactly how
the seek bar's phone rule came to be dead for months.
**#69's overflow fit does not move.** That pass measures inline size,
so the height costs it nothing, and only the two square controls grow
the header's content -- by 22px in total. header-action-overflow.spec.ts
passes unchanged at all four of its widths, which was the check rather
than the assumption. Verified on the device that the count is still
shown at 424px, so nothing has started yielding.
search-trigger is the sharpest case and is fixed in the same pass: #57
created it as the phone's replacement for the header search box, so it
exists *only* where there is a thumb, and it shipped at 40x40 under a
comment calling that "the smallest a touch target should be". That was
the floor restated four pixels short rather than a second opinion about
it, and the comment now says so.
Unlike #187 this can be measured rather than inferred: the controls are
plain elements and the rule is a min-size, so it holds at every width
and a real Chromium rendering a real page-header gives the actual
answer. The tests fail with the device's own numbers -- 29x21, 38, 40.
Verified on the device: every control in the header is now at least
44x44, and so is the phone's search button.
**This is the Direction's first step, not all of it.** config-field's
93 Settings controls and explore-view's search row are the second pass;
Settings is a form with one shape for every row and wants its own
argument. #186 stays open for them.
The first pass grew the two square controls to 44px as boxes, which
added 22px to the header. That fit at every width Chromium was checked
at and **clipped the overflow trigger at 320x600 in WebKit** -- the
engine closest to what ships, and the one no machine here can run:
every action is reachable at 320x600 (400% zoom)
- Array []
+ Array [ "more" ]
Two things were wrong, and only one of them was the code.
**The claim was checked on one engine and stated as a property.** The
previous commit said #69's fit "does not move ... the check rather than
the assumption", on the strength of running that spec against chromium
alone. CI runs both browsers precisely because they are not the same
answer.
**And the box was the wrong thing to grow**, which the issue already
said: "reached by growing the *hit* area rather than the visual weight
where the two can differ -- padding on the control, not size on the
icon". #69's pass measures inline size, so a taller control is free and
a wider one is not.
So height stays a box -- the header has the room and nothing measures
it -- and width is padding with a negative margin handing the space
back, which is the seek bar's shape from #187. Measured in the
component tier at 320px: the arrow's rect is 45x44 and it occupies 29,
the overflow trigger 44x44 occupying 38, the search button 44x44
occupying 40. Those three occupancies are what they were before any of
this, so the fit pass sees a header identical to main's and the
320px case cannot regress.
The arrow's target is lopsided for #187's reason: the select is 6px to
its left and there is open space to its right, so it takes the side
with nothing to steal from. The overflow trigger's can be symmetric,
the actions row having an 8px gap.
`search-trigger` is border-box, so its 44px min-width is the whole
target and the margin alone gives the four pixels back.
The new assertion is the one that would have caught this: every grown
control must carry negative inline margins, because that is what keeps
the box out of the fit. The rect assertions stay -- getBoundingClientRect
includes padding, so the target is still measured directly rather than
inferred.
logan
merged commit 52038dc5ae into main2026-08-22 00:32:08 +00:00
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.
fix(shell): raise the page header's controls to the touch floor#56 named 44px and the queue header keeps it; nothing else was resized.
So the controls a user meets on every screen were between a third and
two thirds of the app's own floor. On the device at 424x439:
page-sort99x23,page-sort-direction28x21,page-actions-more38x27,
search-trigger40x40.Both open questions, answered by one measurement
The issue leaves two things "to decide rather than assume". The header
is 63px tall with 20–23px controls, so the vertical room was already
there; the select and its arrow are 6px apart, so the horizontal room
was not.
That makes this
min-size, not padding with a negative margin — whichis what the seek bar needed in #187, and the difference decides the
rest. There the painted track had to stay thin, so the target grew past
its own box and had to be checked against its neighbours. Here the
control is the target: the boxes are flex items, so the gap keeps
them apart and no two targets can overlap by construction.
a second declaration of what a phone shows is a second thing to keep
in step — which is why this component has never had one. It also
avoids a media query no tier renders, which is exactly how the seek
bar's phone rule came to be dead for months (#187).
height costs it nothing; only the two square controls grow the
content, by 22px total.
header-action-overflow.spec.tspassesunchanged at all four widths — the check, not the assumption. I also
verified on the device that the count is still shown at 424px, so
nothing has started yielding. (It is absent on Playlists for an
unrelated and documented reason: the count is
nulluntil there isan answer.)
search-trigger is the sharpest case
#57 created it as the phone's replacement for the header search box, so
it exists only where there is a thumb — and it shipped at 40x40 under
a comment calling that "the smallest a touch target should be". That
was the floor restated four pixels short rather than a second opinion
about it. Both the number and the comment are fixed.
Verification
page-sort99x44,page-sort-direction44x44,page-actions-more44x44, the action buttons 168x44,
search-trigger44x44.make ui-test(1014, +3),make e2e(236, chromium — webkit isCI's),
make css-check,make bindings-check,make skill-check,tsc --noEmitin both packages.make lint/make testareformalities: no Go changed.
numbers —
page-sort-direction 29x21,38,40.Unlike #187, this is measured rather than inferred from the stylesheet:
the controls are plain elements and the rule is a
min-size, so itholds at every width and a real Chromium rendering a real
page-headergives the actual answer.
What is deliberately not here
#186 stays open. This is the Direction's first step — the one it
says "covers five views at once and is the obvious place to start".
config-field's 93 Settings controls andexplore-view's search roware the second pass. Settings is a form with one shape for every row,
so it is close to a one-rule change, but it makes every row on a long
page taller on a 439px screen — a density argument that deserves its
own pass and the visual suite, not a footnote in this one.
One thing found on the way that is not in the issue's tables: the
skip link is 147x35. It is keyboard-only and unreachable by touch,
so it is not a touch-target defect — noted so the next pass does not
spend time rediscovering it.
The first pass grew the two square controls to 44px as boxes, which added 22px to the header. That fit at every width Chromium was checked at and **clipped the overflow trigger at 320x600 in WebKit** -- the engine closest to what ships, and the one no machine here can run: every action is reachable at 320x600 (400% zoom) - Array [] + Array [ "more" ] Two things were wrong, and only one of them was the code. **The claim was checked on one engine and stated as a property.** The previous commit said #69's fit "does not move ... the check rather than the assumption", on the strength of running that spec against chromium alone. CI runs both browsers precisely because they are not the same answer. **And the box was the wrong thing to grow**, which the issue already said: "reached by growing the *hit* area rather than the visual weight where the two can differ -- padding on the control, not size on the icon". #69's pass measures inline size, so a taller control is free and a wider one is not. So height stays a box -- the header has the room and nothing measures it -- and width is padding with a negative margin handing the space back, which is the seek bar's shape from #187. Measured in the component tier at 320px: the arrow's rect is 45x44 and it occupies 29, the overflow trigger 44x44 occupying 38, the search button 44x44 occupying 40. Those three occupancies are what they were before any of this, so the fit pass sees a header identical to main's and the 320px case cannot regress. The arrow's target is lopsided for #187's reason: the select is 6px to its left and there is open space to its right, so it takes the side with nothing to steal from. The overflow trigger's can be symmetric, the actions row having an 8px gap. `search-trigger` is border-box, so its 44px min-width is the whole target and the margin alone gives the four pixels back. The new assertion is the one that would have caught this: every grown control must carry negative inline margins, because that is what keeps the box out of the fit. The rect assertions stay -- getBoundingClientRect includes padding, so the target is still measured directly rather than inferred.