f841ccf42526b51e33b563f6bcf112497e81bd36
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  jheapsandClaude Opus 5
|
2d80edd513 |
Say how many ways once, in the one control that owns it
"Split between" on Quick Split was two controls for one value stacked on each other: chips 2 3 4 5, and under them a bar reading "2 ways" with a − and a +. The count was written down three times at once — the lit chip, the bar, and "Each of 2 players gets" in the panel above — and two of the three were controls. 134px with its label, against 74px for "Smallest chip in play" right below it, which offers five choices in one row. The bar was never meant to be a bar. `.waysStepper` asked for a 150px min-width inside a wrapping flex row, so on a phone it always wrapped to a line of its own, and `flex: 1 1 auto` then gave it all 358px of that line: 252px of empty readout with the − and + pushed 304px apart, on a screen 390px wide. Now it is 136px with its ends 121px apart, and it only exists once you are through the door — a fifth chip reading "6+", behind which the stepper is where the count is written. Under six ways, which is every chop a home game will run, the field is one row and 74px. Two more things went with it: Neither stepper ever disabled an end, so − at the floor and + at the ceiling looked live and swallowed the tap. NN/G's stepper guidance asks for the opposite. Both ends of both steppers now grey out. The per-pot chop capped its + with `Math.max(contenderCount, MAX_WAYS)`, which is always 12 — a side pot only P1 and P2 were eligible for would happily chop ten ways at $12 each. It is `chopCeiling()` now, and a two-contender pot is offered no stepper at all, that being the common shape. The sweep went straight to the all-in mode and audited only that, so the mode the screen opens in had never been looked at in fourteen rounds, which is how a 358px bar lasted this long. It audits both now — 428 audits, clean — and the first run of it found the step buttons had been 40px wide rather than 44 since they were written. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb |
||
|
jheapsandClaude Opus 5
|
382238e708 |
Tell the browser the page is dark, and stop painting over it instead
Everything in this stylesheet is a colour it paints. `color-scheme` is the half it cannot: the browser draws the checkboxes, the menu a <select> opens, the scrollbars, the caret, the spellcheck underline and the autofill wash, and with no scheme declared it draws every one of them for a light page. Measured, `color-scheme: normal` on a #141414 ground — three checkboxes in Table Setup rendering as bright white squares, the loudest objects on the screen and brighter than the gold, and two more in the seat sheet doing it over the felt. The comment on the pot wizard's hand-painted checkbox called it "the last raw browser control in the tool". Six others were still the platform's, and three of those were still 13x13 against a 24px floor this file had already written down once — in a comment that explains the floor, attached to a rule naming one checkbox by id. One declaration on :root moves all six, and moves them natively, which is the part worth having: a control the browser draws still answers Windows High Contrast Mode, still matches the platform the dealer already knows, and cannot lose its tick to a stylesheet. `accent-color` makes the checked state the green this tool already uses for yes — the same #1e8449 the painted box fills with, so the one drawn checkbox and the six native ones agree rather than nearly agree. The painted one stays painted, because it is not a setting: it is the box a dealer ticks to move money with players watching, and it wants a fill that reads across a table. But it now pays what painting costs. A tick drawn as a `background` on a pseudo-element is not a colour forced-colors mode knows how to replace, so it was simply gone — no visible checked state at all in Windows High Contrast Mode, on the dialog that pays the table. System keywords are the only colours guaranteed to survive, because they are the palette. Three other things fell out of looking: The id-scoped 24px rule existed three times over — once in the open, once under `max-width: 700px`, once under `pointer: coarse` — and still reached one box of six. Said about checkboxes instead, once. A colour swatch declared 32px wide measured 22 with a mouse: flex-shrink, the exact mechanism the coarse-pointer block had already been bitten by and written a note about. It gets the same `flex: none` the touch case got. Quick Split is the darker of the two pages and had never declared a scheme either. It has no checkboxes to go white, but a dealer opening it from the felt should not find a light scrollbar down the side of it. 1104 tests pass; the 418-audit sweep is clean. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb |
||
|
jheapsandClaude Opus 5
|
b9b2237dbe |
Run the two checks the audit had and never used
runAll() did not include the contrast check — it simply wasn't in the list — and
touch targets sat behind an opt-in flag nothing passed. So "the audit is clean"
has meant nine checks rather than eleven for a long run of rounds, and the two
left out are the two whose faults a dealer meets in a dim room with their thumb.
Both were written, tested, and then never called; the contrast checker was built
across two rounds and every sweep since has been silent about colour.
The standalone runner had a second version of the same hole: the 44px rule
stands itself down where `hover: hover` says there's a pointer, and a headless
desktop browser is a pointer, so a single pass had never measured a touch target
at any viewport. It now runs every viewport twice, once with a mouse and once
with a thumb.
A check that decides it doesn't apply now says so, rather than reporting an empty
offenders list — which reads exactly like a pass.
Faded text is measured instead of filed as unchecked. `opacity` on a box fades
the box and its text together onto whatever is behind it, so a dimmed seat is not
grey text on a dark puck: it is a faded puck and faded text both landing on the
page. Both halves are composited that way now. Two exemptions remain and both say
so out loud: a disabled control, which WCAG itself excuses, and a link inside a
sentence, whose size is set by the line it sits in.
What running them found, and this round fixes:
- the chair number on every seat: #8a8a8a at 9px, 3.39:1 once the empty seat's
fade is composited, on the label that answers "which seat is that?";
- Quick Split's amount field at 37px tall and its delete button at 30px across,
on a page whose targets had never been measured;
- and on a 360x640 phone with the bar grown by a side pot, the bottom seat
sitting 38px inside it.
That last one brings back a cap this project measured and rejected once: capping
the felt to the room left fixed the six-seat ring and broke the nine-seat one.
That trade was real then and isn't now — seats are spaced by distance around the
rim rather than by angle, so a shorter felt no longer piles them up. Re-measured
across 30 combinations of five phone sizes and 2 to 12 seats: every one clean
except twelve seats at 360x640, where a 240px felt and a 64px puck cannot both be
true. Where the rim can't give each seat a puck's width, the pucks come down a
size, measured from the rim itself rather than from a media query.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
|
||
|
jheapsandClaude Opus 5
|
3be93cdadf |
Chop a side pot on the screen that worked it out, and fix Quick Split's contrast
Quick Split lists the pots when somebody is all-in — main, sides, uncalled — and then
leaves the dealer there. Two players tying for a side pot is ordinary, and working out
each one's share meant switching to the other mode and retyping an amount the screen
had just calculated. Retyping a number with money on it is a transcription error
waiting to happen, and the number was already on screen.
Each pot with two or more people who can win it now carries a Chop, opening underneath
its own row: as many ways as there are contenders by default, a stepper for a chop
between fewer of them, and the same odd-chip and dust wording the main split uses,
because it is the same rule and the dealer shouldn't have to notice they are reading a
different screen. Per-row state, so opening the main pot's chop doesn't disturb what
the side pot below it says. Not offered on the uncalled row, which goes back to one
player, nor on the total.
Separately, this page had never been through the layout audit the dealer table gets
every round, and it was carrying nine contrast failures:
.unevenCurrency 4.11:1 the $ beside every amount typed
.unevenRemoveBtn 3.66:1 the ✕ that deletes a player's entry
.splitFootnote 3.94:1 the instruction for what to do with the pot list
All under the 4.5:1 small-text minimum, the worst of them on a destructive control.
Lifted to pass. The large $ on the even-mode pot input is left alone: at 1.6rem it is
large text, where 3:1 is the bar and 4.11:1 clears it.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
|
||
|
jheapsandClaude Opus 5
|
6fa4532781 |
Fix the contrast the audit could finally measure
Contrast is the one check I've got wrong twice, both times by being clever about backgrounds. The first version read only background-color, so text on any of the gradient-painted sheets was measured against transparency and the dealer puck's dark "D" was reported at 1.2:1 against nothing. The second over-corrected and treated low-alpha gradient stops as opaque, scoring white-on-dark at 1.0:1. So this one is built to be incapable of false positives rather than exact. Backgrounds composite through alpha; where a gradient is involved every colour stop is tried and the most flattering one used. A finding means the text fails even under the reading most generous to it. It's checked against known answers before being believed: black on white at 21:1, white on white at 1:1, #767676 on white at the 4.54:1 AA boundary, white over a dark gradient, dark text on that same gradient, white over a 6% white wash on a near-black page. Nine cases, all correct — and building them found a real bug in the check, which walked past an opaque gradient and offered the page background as a candidate. That made it too lenient, which is as bad as the old false positives. What it found: Both blind badges failed against their own gradients, in 9px bold text a dealer reads at a glance across a table. At the worst stop: small blind 3.52:1, big blind 2.15:1. The small blind keeps its blue and darkens to 4.77:1. The big blind flips to dark text on brighter gold, 5.84:1 — how a gold chip is marked anyway, and it makes the two badges far easier to tell apart at speed. Quick Split's footnote names a control the dealer is told to reach for, and that name inherited the muted grey of the surrounding aside: 3.39:1. Emphasised text carrying an instruction gets its own colour now. The felt watermark came back at 1.19:1 and is meant to. It's decoration; holding it to a reading threshold would mean making it not a watermark. It's aria-hidden now, which says the same thing where it also does some good, and the audit skips aria-hidden subtrees. 32 contrast passes over the table, all five overlays and Quick Split at five viewports: zero findings, zero unmeasured. Layout audit still clean. 137 tests pass. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb |
||
|
jheapsandClaude Opus 5
|
073ba9a252 |
Make every tap in the dealer land instantly on a phone
Four measured problems, all of which only show up under a thumb. Every tap waited on the browser (53 of 53 controls) Not one interactive element set `touch-action`, so a mobile browser held every tap for ~300ms to see whether a second one was coming that would mean "zoom in". That is on the fold button, the call button, every seat, every card slot. Worse, this tool uses double-tap on a seat as the fold shortcut — which *is* the browser's zoom gesture. The dealer's fastest shortcut was fighting the page zooming under their thumb. A single seat tap cost ~300ms of browser hesitation before the app's own 220ms double-tap window even started. `touch-action: manipulation` everywhere keeps panning and pinch-zoom and drops only double-tap-to-zoom, which is precisely the one that was in the way. Press feedback was the OS grey box (1 `:active` rule in 2385 lines) Only `.actionBtn` had a pressed state. Everything else — seats, header buttons, card slots, picker cards, menu rows, toasts, wizard choices — relied on the translucent grey rectangle the browser paints on tap. So the tap highlight couldn't just be switched off; the controls needed real pressed states first. They press down 1px and brighten, in 0.04s, matching the action bar that already did. Then the grey box goes. Hover stuck after every tap (21 unguarded rules) `:hover` has no meaning on touch, but it still applies — and stays applied until you tap elsewhere. Tapping "Next hand" left it lifted and lightened as though still under a cursor, and it would have fought the new pressed states directly. All of them are behind `@media (hover: hover)` now. The one rule that shared a block with `:focus-visible` was split so keyboard focus survives. The notes field zoomed the page (iOS) `#tableNotes` was 13.3px. iOS zooms the viewport when a field under 16px takes focus, and the dealer is then pinching back out to see the table. Every other input here was already 16px; this was the straggler. Seats deliberately have no `:active` rule Worth writing down because it nearly went in. A seat's `transform` is what positions it around the felt, so a pressed state setting `transform` drops the `translate(-50%, -50%)` and throws every pressed seat ~38px off its spot. Validation caught it: seats already dip via `.seatPressing`, which `pointerdown` adds in render.js — earlier than `:active` resolves, and it restates the translate correctly. Validated with Playwright at 390x844: 53/53 controls off `touch-action: auto` and 0 tap-highlighted across the table, all four overlays and Quick Split; text fields still selectable and buttons not; 14/14 hover rules gated; presses measured live via mouse-down (fold reads translateY(1px)/brightness(1.3), a seat holds its translate with 2px of drift from the shrink alone). Hand played through the UI including a double-tap fold. No console errors. Unit tests 58/58. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb |
||
|
jheapsandClaude Sonnet 5
|
7c64749267 |
Let Quick Split handle the pot it used to send people away for
Quick Split answered the easy half of the question and printed a footnote for the hard half: if somebody was all-in for less, go set up the full table. That's the moment a dealer least wants to be setting up a table. A second mode takes what each player put in and lists the main pot and each side pot with who can win it, plus anything uncalled that goes back. Rows can be marked folded, so dead money lands in the right pot without its owner being able to win it. The running total is shown so the breakdown can be checked against the chips actually on the table. It reuses the same pot maths as the full table rather than growing a second implementation, which means the two screens can't drift apart and Quick Split inherits the uncalled-bet and everyone-folded handling that was fixed there. Also fixes hiding: these sections carry a `display` declaration, which outranks the browser's own [hidden] rule, so toggling `hidden` on them did nothing and both modes' controls showed at once. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb |
||
|
jheapsandClaude Sonnet 5
|
870dee4a29 |
Add a phone-first Quick Split screen for chopping a pot mid-hand
The dealer table is a two-handed, big-screen tool. A dealer standing over a chopped pot with a phone in one hand and players waiting needs an answer in seconds, not a table to set up first — so /casino/texasholdem/quicksplit is the whole job on one screen: type the pot, tap how many ways, tap the smallest chip in play, read the payout. Nothing to configure, nothing saved. It splits in whole chips rather than raw arithmetic, because a dealer can't push half a chip across the felt: everyone gets the same stack and the remainder is called out as odd chips going one at a time to the first players left of the button. A pot that doesn't divide into the chosen denomination says so instead of quietly hiding the difference. Money formatting moves out of render.js into its own file so this screen can use it without pulling in the whole seat/chip UI. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb |