2 Commits

Include renames

Author	SHA1	Message	Date
logan	2be6fb3066	feat(player): draw no volume control where there is no volume ... volume-control asks the player whether there is a volume of ours to control, and renders nothing when there is not. The decision is in the control rather than at either mount point because there are two, and one of them -- the bottom bar's -- lives in index.html, which has no module scope to make it conditional. It could not have been a width, and that is the whole design decision. Every other stand-down rule in this app is keyed on a viewport, because a width is what a browser can answer and what every tier can test. This one is a property of the build: keyed on width, an Android tablet at 600px or more draws the bar's slider over a level the backend has pinned -- a control that cannot act, on exactly the platform the rule exists for, which library-status-indicator settled is worse than none. The same rule is wrong the other way below 600px, where a narrow desktop window has no hardware keys to fall back on. index.css keeps its phone rule, which is now about room and says so. Rendering nothing and hiding the host are both needed and are separate assertions: an empty shadow root is what stops a by-role or positional query finding a button that cannot act, and :host([hidden]) is what stops the element taking a flex item's worth of the transport. The host rule has to be written down, since :host { display: inline-flex } outranks the UA's [hidden]. Measured at 424x439 by flipping the constant and rebuilding: the album art goes 39px to 68px and the transport 172px to 143px -- 29px, being the 21px control plus the 8px gap a hidden box stops drawing. The bar's centring is unaffected, since #23's outer columns are the same min() expression rather than content-sized. volume-ownership.test.ts is the tier that can exercise the Android rendering, on an ordinary Linux runner, because the predicate is a stubbable backend answer. Both of its tests were confirmed to fail on the build before this. Closes #64 Closes #172	2026-08-21 00:53:36 -04:00
logan	dc8db159f9	feat(player): centre the transport and show the volume inline ... Two issues over one bar, because they are one relayout. #42's own findings say so: giving wa-slider a label grows it 6px to 14px and moves the transport, which is #23's subject, so doing them in sequence means measuring the bar twice and throwing the first set away. The bar was `320px 1fr auto`, so the transport sat in the middle of what the metadata and the queue button did not use — its centre was ~140px right of the window's at every width. The outer two tracks are the same expression now, so the middle is centred by construction. The side width is the metadata's, capped at a quarter of the bar, and the cap was measured as a regression before it was a decision: reserving the full `--now-playing-width` on both sides is perfectly centred and takes the seek bar's track from 257px to 61px at 800px, and to 0 at 200% text. The control you drag was paying for the symmetry. With the cap it is 246, which is parity. It is a `min()` rather than a breakpoint because that variable is user state — the metadata has a drag handle — and tying both sides to it is also what keeps dragging meaningful; a plain `1fr … 1fr` centres just as well and silently makes the handle a no-op. The volume moved out of `audio-player` into the bar because the transport column has to hold the transport and nothing else, and it joins the queue button in one cell rather than a second column, since the centring compares columns. It is a slider by default and a popup by setting. The stored flag names the *popup*, which is this config's polarity rule — the zero value has to be the intended answer, so an existing config.toml gets the new default with no migration. Inline, the icon is the mute toggle and is named after that action rather than the state, because with the slider beside it there is nothing to disclose; the component tier now covers both presentations rather than whichever is default. Three nested rules in this block began with a bare element selector, which Chrome 120 relaxed and the phone's Chrome 113 **silently drops** — including the ellipsis on the bar's own title and artist, which has therefore never truncated on the device. They are `&`-prefixed now. Filed as #154 for the class and for a check. `bottom-bar.spec.ts` pins both halves separately on purpose: an uncapped build is perfectly centred and fails only the seek-bar width, so a spec asserting centring alone would have passed the regression above. Both were verified by mutation. Closes #23 Closes #42	2026-08-20 00:40:52 -04:00