What's That: reference image title overlays the bottom corner of the image

[WilfordGrimley]

Part of #704.

Reported symptom

Owner: "The reference image has it's title blocking the bottom corner."

Code evidence

SubjectArtTitle (QuestionFeed.tsx:220-232) is styled with position: absolute; left: 0; right: 0; bottom: 0; z-index: 2; a dark linear-gradient background (transparent to rgba(0,0,0,0.72)); white, 700-weight text at clamp(13px, 3.4cqi, 17px); and padding 22px 10px 8px.

It renders as the last child of SubjectArt (QuestionFeed.tsx:1233-1236: SubjectArt wraps cardArt then SubjectArtTitle), stacked directly on top of the card art via position:absolute + bottom:0 + z-index:2, and is identically reused for the artist/tag question types at QuestionFeed.tsx:1742-1755. It always renders unconditionally - there is no check against the underlying artwork's own bottom-corner content (a mana cost, set symbol, or collector info printed into the scan itself) - so its dark gradient plus the full card name text sits directly over whatever art occupies the bottom of the reference image, matching the reported "blocking the bottom corner."

Confirmed / Refuted / Inconclusive

Confirmed. SubjectArtTitle is an always-on, absolutely-positioned overlay pinned to the bottom edge of the subject art, with no mechanism to avoid overlapping card-art detail there.

Scope

Touches SubjectArtTitle (QuestionFeed.tsx) and its two render sites (SubjectCard, QuestionFeed.tsx:1231-1242, and the artist/tag cardNode, QuestionFeed.tsx:1739-1758). A fix could move the title out of the art entirely into SubjectCap (QuestionFeed.tsx:234-264, the existing caption strip below the art) rather than overlaying it, or shrink/reposition the overlay so it only covers a margin strip instead of a full-width band. Either approach changes the subject-card composition shared by every question type on this page (confirm_suggestion, identify_printing, artist, tag), so it needs one visual pass across all four, not a per-type patch.

Layout-pass coupling

Directly coupled to the "reference card should stay visible while scrolling / page uses vertical space poorly" item - both touch the same SubjectCard/SubjectArt/SubjectCap composition, and moving the title into SubjectCap (this issue's likely fix) changes the vertical space budget that item is trying to reclaim. Should be designed together, not sequenced as independent patches.

[WilfordGrimley]

Owner Re-examination — 2026-08-05

The gradient overlay is NOT the defect.

Owner re-examination: the symptom reported here (title blocking the bottom corner) is actually the hover-grow clipping issue described in #705. The reference card renders in boxes carrying overflow: hidden styling. When the image scales up 1.6× on mouseover (ZoomableThumbnail, deliberately designed to scale), the box's overflow setting crops the scaled edges so they become non-visible — clipping the hover effect.

The binding table at spec §1c (the title overlay's absolute positioning, gradient, z-index, and text styling) is confirmed correct. No amendment to the binding table is needed.

The actual defect is the parent overflow setting. See #705 for the hover-zoom clipping details. Based on the code evidence:

• ZoomableThumbnail (cardPanel.tsx ~:149-173) is deliberately built WITHOUT overflow: hidden
• SuggestedThumb (QuestionFeed.tsx ~:461-469) sets overflow: hidden
• CandidateButton (cardPanel.tsx ~:228-256) sets overflow: hidden

Both ancestors clip the 1.6× hover-scale transform the inner component was designed to let through.

Recommendation: #708 should be narrowed to any residual title-placement concern (if one exists), or closed as a duplicate of #705. The owner will make this call. The gradient overlay itself is working as specified.

See amendment A3 in PR #718 for the full confirmation recorded in the spec.

[WilfordGrimley]

Verification pass against live production (deployed commit 425fab94): the earlier conclusion that this was a duplicate of #705's hover-clipping was WRONG.

#705's hover-clipping fix shipped in #737 and works correctly (confirmed live, no clipping on hover in either Chromium or Firefox). But the title-label-overlay defect this issue originally reported is a separate, independent, still-live bug — the gradient overlay (SubjectArtTitle in QuestionFeed.tsx) is positioned absolutely inside the artwork's own box at rest, with no hover interaction required. Measured live: label top at y=403px, image extends to y=458px — the label covers the image's bottom ~55px unconditionally.

This also means SPEC-wtc-rebuild.md's amendment A3, which concluded the binding table needed no amendment based on the hover-clipping misdiagnosis, needs revisiting. Full source-verified writeup: #741.