logan
2100f0022f
#56 named 44px and #195 took the page header there. Settings is the other half of #186 and much the larger one: swept on the reference device (TLP301, 424x439) with all eleven config-sections expanded, **120 controls** were under the floor -- not the 93 the issue's table implies, and config-field is eight of them. The bulk is behind the disclosures, which is why nobody had counted it: 36 .column-arrow-btn 16x14 <- smallest in the app 29 .column-toggle 16x16 26 shortcut-capture button 80x25 8 download format checkbox 16x16 7 config-field select 335x30 6 wa-input / wa-button 204x20, 185x21 **The density argument, measured rather than guessed, and it is smaller than it looks.** The rows were already near the floor -- .column-item is 335x36 and .shortcut-row 335x37; it is the controls *inside* them that were 14-25px. So a control grows into the row it already occupies and the row goes 36 to 44. Measured after: the two column lists went 373->447 and 690->850, +234px over the whole page. Half a screen of extra scroll on a page that already scrolls, against 36 targets of 16x14. **Settings is cheaper than the header was, and for a stated reason.** There is no overflow fit on this page, so the header's "only width is contested" rule does not bind at all and nothing here needs padding with a negative margin. Height is a min-size, and the two square controls can simply be square. Three shapes, because one rule does not fit three kinds of control: **A native checkbox is targeted through its label.** It cannot grow its hit area without growing its paint, and a 44px checkbox is not what anyone wants -- so .column-label is a real <label for> now and the column's *name* is the target, 70x44 rather than 16x16. That is the argument config-field already makes one file over ("a real label association also makes the label text a click target, which is behaviour, not annotation"), and here it is the whole fix. The download formats already had the label; they only needed the height. **The arrows take padding, which is invisible.** They carry background: none and a transparent border, so 16x14 -> 44x44 changes nothing anyone can see until hover -- #186's Direction exactly. **Web Awesome's controls come from the library's own API.** Their height is decided inside somebody else's shadow root, and --wa-form-control-height is the variable that decides it. A custom property inherits through a shadow boundary, so a :host declaration reaches them; styles/wa-touch-floor.css.ts is that, once, adopted rather than written at :root in index.css -- a :root rule would be invisible to the component tier, which renders a component and no page stylesheet. **Two controls no sweep can see are fixed by name**, and they are the trap this issue keeps setting. config-field's toggle has an <input> that is opacity: 0; width: 0; height: 0, so a walk of every input skips it as a zero-sized node -- what a finger hits is the <label>, which measured **34x19**, smaller than anything in either of #186's tables and absent from both. It is 44x44 with the pill still painted at 2.5em x 1.4em and negative inline margins keeping it flush with the inputs above. And shortcut-capture's reset button renders only for a shortcut somebody has rebound, so a sweep of a fresh install never meets it. Verified on the device, same method as the sweep that filed it: 120 controls under the floor before, 42 after. All 42 are accounted for -- 37 are checkboxes whose labels measure 70x44 and 57x44, four are wa-input's inner input at 204x**42**, which is the control measured *inside* its own 1px border (part=base is 238x44), and one is the skip link, which #186 already ruled out as keyboard-only. The e2e suite passes, top-bar-fit and header-action-overflow included -- but that is **chromium**, which is half an answer, and saying so is the whole of what #195's second commit was about. What can be argued rather than run: library-filter is the only thing here in a container that measures itself, and its width did not change. The fit measures inline size. Two page-header screenshots are refreshed because they are this issue's own debris -- #195's taller sort control, merged last session, with its references never re-recorded. app-sidebar's and now-playing's are deliberately left: they are unrelated drift, and blessing an unrelated screenshot is how the sidebar reference came to still list a destination #27 retired. That is #196.
49 lines
2.3 KiB
TypeScript
49 lines
2.3 KiB
TypeScript
import { css } from 'lit';
|
|
|
|
/**
|
|
* A Web Awesome form control is at least the app's 44px touch floor.
|
|
*
|
|
* #56 named 44px and #186 found nothing but the transport had reached
|
|
* it. Web Awesome's form controls are the part of Settings this app
|
|
* does not draw: measured on the reference device (TLP301, 424x439),
|
|
* `wa-input`'s control is **204x20** and `wa-button` **185x21** — the
|
|
* shortest controls on the page, and the only ones whose height is
|
|
* decided inside somebody else's shadow root.
|
|
*
|
|
* `--wa-form-control-height` is that decision, and it is the library's
|
|
* own theming variable rather than a part or an internal — the default
|
|
* theme sets it at `:root` and every control that has a height reads
|
|
* it (button, input, select, radio). So this is `wa-slider-label`'s
|
|
* better half: the API first, and no reach into a shadow root at all.
|
|
*
|
|
* Three things about it are load-bearing.
|
|
*
|
|
* **A custom property inherits through a shadow boundary**, which is
|
|
* what lets a `:host` declaration reach a `wa-input` the host renders.
|
|
* That is also why it is a stylesheet a component adopts rather than a
|
|
* `:root` rule in `index.css`: a `:root` rule would cover every wa
|
|
* control in the app in one line and be invisible to the component
|
|
* tier, which renders a component and no page stylesheet. Here the
|
|
* floor is measurable where it is applied.
|
|
*
|
|
* **It is a flat 44px rather than a floor over the library's own
|
|
* expression.** The default is `round(calc(2 * padding-block + 1em *
|
|
* line-height), 1px)` — em-based, so `size="small"` is what produced
|
|
* the 20px above — and a `max(44px, …)` would have to restate that
|
|
* formula here, which is a copy of somebody else's arithmetic that
|
|
* goes stale silently. A flat value is safe because this app uses
|
|
* exactly two sizes, `small` and the default, and both are under the
|
|
* floor; a `size="large"` added later would be pinned down to 44 and
|
|
* should take that as the prompt to revisit this.
|
|
*
|
|
* **Only the height is pinned.** The font size still comes from
|
|
* `size="small"`, so a control grows its hit area without growing its
|
|
* visual weight — which is what #186's Direction asks for and what the
|
|
* page header's second pass had to be corrected to do.
|
|
*/
|
|
export const waTouchFloor = css`
|
|
:host {
|
|
--wa-form-control-height: 44px;
|
|
}
|
|
`;
|