fix(web): make the space hero edit control legible on any cover (#946) - #969
Merged
Conversation
The ✎ menu on the space hero used ButtonContextMenu's default `ghost` variant, which paints the icon with the *theme's* ink on a transparent background — `text-dark`, i.e. near-black, in the light theme. The hero cover is a photo rather than a themed surface, so that is a coin toss: against a dark cover the icon all but disappeared. Switch it to the `filled` variant with `icon-white-drop-shadow`, the same recipe every other over-image context menu in the app already uses (space album cards, the people pages). A filled chip carries its own background, so it contrasts with itself whatever the photo underneath happens to be, in both themes. Also reported on the same badge row: the role read `Owner` in every locale. It was printing the raw lowercase `SharedSpaceRole` enum dressed up with CSS `capitalize`. Route it through the `owner` / `role_editor` / `role_viewer` keys that already exist in all nine maintained locales, via a `spaceRoleLabelKey` helper shared with `role-badge.svelte` — which had the same mapping inline.
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.
Fixes #946.
The ✎ was invisible on a dark cover
space-hero.svelterendered the edit menu withButtonContextMenu's defaultghostvariant. Ghost paints the icon with the theme's ink on a transparent background —@immich/uiresolvesghost+secondarytotext-dark, which is near-black in the light theme.The hero cover is a photo, not a themed surface, so a theme-tinted control is a coin toss against it. On the reporter's dark green cover the pencil all but vanished. (Dark theme has the mirror-image problem: a near-white icon that would disappear on a bright cover.)
Rather than nudge the opacity, this switches the control to
variant="filled"+buttonClass="icon-white-drop-shadow"— the same recipe every other over-image context menu in the app already uses (space-album-card.svelte, both people pages). A filled chip carries its own background, so it contrasts with itself whatever the photo underneath happens to be, in both themes and on any cover.Verified by rendering the top-right chrome through the app's real compiled Tailwind +
@immich/uitheme over the cover from the issue:ghost)filled)The role badge was untranslated
Reported in the same issue. The badge printed the raw lowercase
SharedSpaceRoleenum (owner), dressed up with CSScapitalize— which is why it readOwnerin every locale.It now goes through the
owner/role_editor/role_viewerkeys, which already exist and are already translated in all nine maintained locales, so no i18n changes were needed.role-badge.sveltehad the same mapping inline, so both now share aspaceRoleLabelKeyhelper. Its return type is the literal key union rather thanstring, so$t()still type-checks the keys againsten.json.Tests
TDD — all seven tests were watched failing first, including the
text-darkassertion that pins the reported bug:spaceRoleLabelKeyunit tests (three roles + unknown-role fallback to the least-privileged label)role_editor/role_viewerrather than the raw enum.$techoes keys back under test, so a badge readingrole_editoris the proof it went through i18n at all. Deliberately not asserted for owner: the key and the raw enum value are bothowner, so that test could not fail.text-darkThe e2e assertions on
hero-role-badge(permission-matrix,spaces-albums-journey,spaces-p1) already matched case-insensitively and stay green — English rendersOwner/Editor/Viewer. Their comments claiming a raw enum are updated.Green: web unit suite 4347 passed,
check:typescript,check:svelte,lint, prettier (web + e2e).Noted, not changed
The role badge itself is
bg-white/20 text-white, which has the same weakness on a bright cover. It is not what was reported and darkening it is a design change rather than a bugfix, so it is left for a follow-up.