marcel/familienarchiv
1
0
Fork 0
Code Issues 119 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

refactor(ui): use bg-surface token instead of bg-white on thumbnail tiles #312

New Issue
Open
opened 2026-04-23 20:31:36 +02:00 by marcel · 0 comments
marcel commented 2026-04-23 20:31:36 +02:00
Owner
Copy Link

Context

Flagged by @leonievoss in the review of PR #311:

ConversationThumbnail.svelte:23 hardcodes bg-white — In dark mode the tile becomes a bright-white rectangle with a dark paper scan on it, held together only by dark:mix-blend-multiply. The mix-blend works for light-colored scans but produces muddy results on high-contrast handwriting. The existing DocumentThumbnail.svelte has the identical pattern, so this is the team's convention.

This pre-existed PR #311 (inherited from DocumentThumbnail.svelte) and affects both thumbnail components consistently. Filing separately so the fix can touch both surfaces in a single sweep without widening the scope of #305.

Affected files

  • frontend/src/lib/components/ConversationThumbnail.svelte
  • frontend/src/lib/components/DocumentThumbnail.svelte

Proposed approach

Replace bg-white with bg-surface (dark-mode-aware token). Re-evaluate whether dark:mix-blend-multiply is still needed after the switch — it may become redundant or need adjustment to dark:mix-blend-screen for scans that were relying on the blend-over-white behavior.

Before shipping the change:

  1. Capture baseline screenshots of a portrait PDF scan, a landscape postcard, and a high-contrast handwriting sample in both light + dark mode
  2. Swap the token
  3. Confirm all three samples render sensibly in both modes; adjust blend-mode if one regresses
  4. Run the axe sweep (briefwechsel-a11y.spec.ts) in dark mode to confirm no contrast regression

Acceptance criteria

  • Neither ConversationThumbnail.svelte nor DocumentThumbnail.svelte contains bg-white
  • Dark mode: paper scans don't produce a bright-white frame around a dark image
  • Light mode: no visual regression from the current appearance
  • axe-core WCAG AA passes in both modes
## Context Flagged by @leonievoss in the review of PR #311: > **`ConversationThumbnail.svelte:23` hardcodes `bg-white`** — In dark mode the tile becomes a bright-white rectangle with a dark paper scan on it, held together only by `dark:mix-blend-multiply`. The mix-blend works for light-colored scans but produces muddy results on high-contrast handwriting. The existing `DocumentThumbnail.svelte` has the identical pattern, so this is the team's convention. This pre-existed PR #311 (inherited from `DocumentThumbnail.svelte`) and affects both thumbnail components consistently. Filing separately so the fix can touch both surfaces in a single sweep without widening the scope of #305. ## Affected files - `frontend/src/lib/components/ConversationThumbnail.svelte` - `frontend/src/lib/components/DocumentThumbnail.svelte` ## Proposed approach Replace `bg-white` with `bg-surface` (dark-mode-aware token). Re-evaluate whether `dark:mix-blend-multiply` is still needed after the switch — it may become redundant or need adjustment to `dark:mix-blend-screen` for scans that were relying on the blend-over-white behavior. Before shipping the change: 1. Capture baseline screenshots of a portrait PDF scan, a landscape postcard, and a high-contrast handwriting sample in both light + dark mode 2. Swap the token 3. Confirm all three samples render sensibly in both modes; adjust blend-mode if one regresses 4. Run the axe sweep (`briefwechsel-a11y.spec.ts`) in dark mode to confirm no contrast regression ## Acceptance criteria - Neither `ConversationThumbnail.svelte` nor `DocumentThumbnail.svelte` contains `bg-white` - Dark mode: paper scans don't produce a bright-white frame around a dark image - Light mode: no visual regression from the current appearance - axe-core WCAG AA passes in both modes
marcel added the refactorui labels 2026-04-23 20:31:45 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-critical
Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.
 P1-high
Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.
 P2-medium
Noticeable improvement; doesn't block anything; schedule opportunistically.
 P3-later
Cosmetic or parking-lot work; fine to stay open indefinitely.
 audit
Read-only audit / assessment work; produces a report rather than changing code
 bug
Something isn't working
 cleanup
Removal of dead code, vague comments, naming violations, and scratch artifacts
 collaboration
We want to extend the family archive to have more collaboration tools
 conversation
descoped
We will do that later
 devops
documentation
README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs
 epic
Marker for epic-level issues that group multiple child issues
 feature
file-upload
legibility
Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction
 notification
person
phase-1: security
Security hygiene — must be done first
 phase-2: container-images
Production-ready multi-stage Docker images
 phase-3: prod-compose
Production compose overlay + Caddy reverse proxy
 phase-4: spring-prod-profile
Spring Boot production configuration profile
 phase-5: backups
Database and object storage backup strategy
 phase-6: deployment-docs
.env.example, DEPLOYMENT.md, runbook
 phase-7: monitoring
Prometheus, Loki, Grafana, Alertmanager
 refactor
Code restructuring without behaviour change
 security
test
ui
UI/UX and accessibility issues
 user
No Label refactor ui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Jens marcel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#312
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?