Move between images with the arrow keys - #3
Merged
Merged
Conversation
A mouse has no swipe. A desktop browser can drag, but swipeOutcome's thresholds are written for a finger — a fifth of the viewport, or a flick at a finger's speed — and a mouse produces neither reliably, so the viewer reads as inert on a desktop. ← and → draw another image, ↓ returns to the entry screen: the same two outcomes a swipe produces, deliberately, so keyOutcome returns swipeOutcome's vocabulary and both routes run through the new Viewer.commit rather than each building its own dismissal. ↑ stays unbound. Not for the reason swipe-up is — a keyboard collides with no system gesture — but because ← and → already mean "another image". Two smaller things fall out of it. dismiss() now takes the outcome immediately when there is no photo on screen, because a display:none element never fires transitionend and would otherwise sit through the full 400 ms timeout; that also gives the error state a way out that is not a page reload, which it did not have before, since onPointerDown refuses to start a gesture on a hidden photo. And modified or auto-repeating arrows are left alone: a held key would abort each load to start the next. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01T4oAqvh4CPXFK2uWJnSXpa
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.
←and→draw another image,↓returns to the entry screen — the same two outcomes a swipe produces.A mouse has no swipe. A desktop browser can drag, but
swipeOutcome's thresholds are written for a finger (a fifth of the viewport, or a flick at a finger's speed) and a mouse produces neither reliably.keyOutcomeincore.jsreturnsswipeOutcome's vocabulary, and both routes now run throughViewer.commit, so a key press and a gesture cannot drift into different behaviour.↑stays unbound — not for the reason swipe-up is (a keyboard collides with no system gesture) but because←/→already mean "another image".Cmd/Ctrl/Alt/Shift) and auto-repeating arrows are left alone; a held key would abort each load to start the next.dismiss()now takes the outcome immediately when no photo is on screen. Adisplay:noneelement never firestransitionend, so it would otherwise sit through the full 400 ms timeout. This also gives the error state a way out that is not a page reload — it had none, sinceonPointerDownrefuses to start a gesture on a hidden photo.Four tests in
core.test.mjscover the mapping, including that every outcome a key produces is onecommitalready handles. The DOM wiring (guards,preventDefault, which edge the image leaves by, the hidden-photo path) was checked against a stub DOM outside the repo;core.test.mjsstays DOM-free by design.Not verified in a real browser — no automation on this machine, and the repo has no npm.
🤖 Generated with Claude Code
https://claude.ai/code/session_01T4oAqvh4CPXFK2uWJnSXpa