Put the panel for a sound out of reach when there is no sound - #52
Merged
Conversation
Found by looking at the app rather than at the code. The panel for the selected sound says "Nothing selected" and shows its controls dimmed, which is right: they are what you reach for the moment you pick something, and hiding them would make the panel jump. Dimmed was only half of out of reach. Pointer events were turned off, and that part works -- measured, a click does not land and nothing is destroyed. What it does nothing about is the keyboard. Sixteen of the seventeen controls stayed in the tab order, so tabbing across the panel with nothing selected goes through sixteen stops that look available, read as available to anything speaking the page aloud, and do nothing. `inert` says all of it at once: no pointer, no focus, and hidden from assistive technology, which is what "nothing is selected" already means on screen. Measured either side of it: one control takes focus with nothing selected, sixteen once something is, and Delete removes the sound it is pointed at. I said this was a functional fault before I had measured it, and it is not: nothing was broken and no work could be lost. The click really was blocked. What was wrong is narrower than I first put it. Two browser tests, checked by putting pointer events back, which fails the first with eighteen controls reachable. The same pattern is not anywhere else. The only other dimming in the UI is a LUFS readout, which is a div with no controls in it, and every `pointer-events: none` in the stylesheets is on something decorative -- a tick, a band, the playhead, a hint -- or on a transient drag state. 359 unit tests, 90 browser tests, build clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ux1kydvUkLRoMbHp82ofDi
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by looking at the app rather than at the code, during a full audit.
The panel for the selected sound says "Nothing selected" and shows its controls dimmed. That's the right thing to show — they're what you reach for the moment you pick something, and hiding them would make the panel jump.
But dimmed was only half of out-of-reach. Pointer events were turned off, and that part works — measured, a click doesn't land and nothing is destroyed. What it does nothing about is the keyboard:
Sixteen stops that look available, read as available to anything speaking the page aloud, and do nothing.
inertsays all of it at once: no pointer, no focus, hidden from assistive technology — which is what "nothing is selected" already means on screen.A correction
I called this a functional fault before I had measured it, and it isn't. Nothing was broken and no work could be lost — the click really was blocked. What was wrong is narrower than I first put it: a tab-order and assistive-technology problem, not a broken control.
Checking
Two browser tests, verified by putting
pointer-eventsback — the first then fails with 18 controls reachable.The pattern isn't anywhere else. The only other dimming in the UI is a LUFS readout, which is a
divwith no controls in it, and everypointer-events: nonein the stylesheets is on something decorative — a tick, a band, the playhead, a hint — or on a transient drag state.359 unit tests, 90 browser tests (was 88), build clean.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Ux1kydvUkLRoMbHp82ofDi
Generated by Claude Code