Live-production verification pass, driven against deployed commit 425fab94 (merge of PR #737) on https://proxyprints.ca/whatsthat, in both Chromium and Firefox at 390px/800px/1600px viewports, Level 1 and Level 2. Chromium and Firefox produced byte-identical rect measurements on this claim.
Symptom. The white/gradient overlay title bar on the subject card's artwork (observed live on e.g. "Masako the Humorless" and "Lotus Petal (2)") sits inside the artwork's own bounding box, directly over its bottom edge, rather than below the image.
Measured. Live: the title bar's top edge is at y=403px; the artwork <img> extends to y=458px. The label's full 55.5px height sits inside the image's own box, covering its bottom ~55px.
Source confirmation. frontend/src/features/questionFeed/QuestionFeed.tsx:
SubjectArt (:220-229) is the artwork's own box: aspect-ratio: 63/88 (card ratio), position: relative.SubjectArtTitle (:231-243) is positioned position: absolute; left:0; right:0; bottom:0; z-index:2; with background: linear-gradient(transparent, rgba(0,0,0,0.72)) — its containing block is SubjectArt itself (the nearest position: relative ancestor), so it is laid out INSIDE the artwork's box at rest, not below it, and not conditional on any hover state.- Rendered at two call sites:
:1287-1290 (Level 1 hero reveal — <SubjectArt data-testid="question-feed-subject-art">...<SubjectArtTitle>{item.card.name}</SubjectArtTitle></SubjectArt>) and :1795-1810 (the Level 2 pinned Subject sidebar). Both render {item.card.name} as the overlay text — i.e. exactly the "Masako the Humorless"/"Lotus Petal (2)" labels observed live.
This is NOT fixed and predates PR #737; #737 never touched SubjectArt/SubjectArtTitle.
Important correction to the issue history. #708 originally reported this exact symptom. It was subsequently mis-diagnosed as a duplicate of #705's hover-zoom clipping. That diagnosis was wrong. #705's hover-clipping fix shipped in #737 and works (confirmed live, no clipping observed on hover in either browser) — but this label overlay is a separate, independent, still-live defect that has nothing to do with hover or clipping: the gradient sits over the bottom of the image at rest, with no interaction required.
Doc-correction flag (not actioned here). docs/proposals/mockups/wtc-rebuild/SPEC-wtc-rebuild.md, amendment A3 (lines 72-79), records: "§1c binding table confirmed — no amendment needed... On re-examination the gradient is not the defect. The actual symptom is #705's hover-grow clipping... The binding table stands." This conclusion is contradicted by the source evidence above: the gradient overlay's position (SubjectArtTitle, absolute/bottom:0 inside SubjectArt) is unconditional on hover and independently reproduces the reported symptom. This needs revisiting — flagged here as a finding only; per this pass's scope, the spec file itself is not being edited as part of this issue.
What done looks like. The subject card's title label does not sit over the artwork's own visible content — e.g. rendered below the image in its own row, or with enough contrast/positioning that it no longer covers the bottom of the art.
Cross-reference: #708 (original report, mis-diagnosed), #705 (the separate, correctly-fixed hover-clipping issue), #737 (shipped #705's fix, did not touch this).
Audited sha: 425fab94.
Live-production verification pass, driven against deployed commit
425fab94(merge of PR #737) onhttps://proxyprints.ca/whatsthat, in both Chromium and Firefox at 390px/800px/1600px viewports, Level 1 and Level 2. Chromium and Firefox produced byte-identical rect measurements on this claim.Symptom. The white/gradient overlay title bar on the subject card's artwork (observed live on e.g. "Masako the Humorless" and "Lotus Petal (2)") sits inside the artwork's own bounding box, directly over its bottom edge, rather than below the image.
Measured. Live: the title bar's top edge is at y=403px; the artwork
<img>extends to y=458px. The label's full 55.5px height sits inside the image's own box, covering its bottom ~55px.Source confirmation.
frontend/src/features/questionFeed/QuestionFeed.tsx:SubjectArt(:220-229) is the artwork's own box:aspect-ratio: 63/88(card ratio),position: relative.SubjectArtTitle(:231-243) is positionedposition: absolute; left:0; right:0; bottom:0; z-index:2;withbackground: linear-gradient(transparent, rgba(0,0,0,0.72))— its containing block isSubjectArtitself (the nearestposition: relativeancestor), so it is laid out INSIDE the artwork's box at rest, not below it, and not conditional on any hover state.:1287-1290(Level 1 hero reveal —<SubjectArt data-testid="question-feed-subject-art">...<SubjectArtTitle>{item.card.name}</SubjectArtTitle></SubjectArt>) and:1795-1810(the Level 2 pinned Subject sidebar). Both render{item.card.name}as the overlay text — i.e. exactly the "Masako the Humorless"/"Lotus Petal (2)" labels observed live.This is NOT fixed and predates PR #737; #737 never touched
SubjectArt/SubjectArtTitle.Important correction to the issue history. #708 originally reported this exact symptom. It was subsequently mis-diagnosed as a duplicate of #705's hover-zoom clipping. That diagnosis was wrong. #705's hover-clipping fix shipped in #737 and works (confirmed live, no clipping observed on hover in either browser) — but this label overlay is a separate, independent, still-live defect that has nothing to do with hover or clipping: the gradient sits over the bottom of the image at rest, with no interaction required.
Doc-correction flag (not actioned here).
docs/proposals/mockups/wtc-rebuild/SPEC-wtc-rebuild.md, amendment A3 (lines 72-79), records: "§1c binding table confirmed — no amendment needed... On re-examination the gradient is not the defect. The actual symptom is #705's hover-grow clipping... The binding table stands." This conclusion is contradicted by the source evidence above: the gradient overlay's position (SubjectArtTitle, absolute/bottom:0 insideSubjectArt) is unconditional on hover and independently reproduces the reported symptom. This needs revisiting — flagged here as a finding only; per this pass's scope, the spec file itself is not being edited as part of this issue.What done looks like. The subject card's title label does not sit over the artwork's own visible content — e.g. rendered below the image in its own row, or with enough contrast/positioning that it no longer covers the bottom of the art.
Cross-reference: #708 (original report, mis-diagnosed), #705 (the separate, correctly-fixed hover-clipping issue), #737 (shipped #705's fix, did not touch this).
Audited sha:
425fab94.