Skip to content

feat(ui): fade the HUD while a full screen view is open (fixes #2092) - #3217

Open
woahwhattheheck wants to merge 1 commit into
FreezingMoon:masterfrom
woahwhattheheck:feat/2092-dim-hud-behind-views
Open

feat(ui): fade the HUD while a full screen view is open (fixes #2092)#3217
woahwhattheheck wants to merge 1 commit into
FreezingMoon:masterfrom
woahwhattheheck:feat/2092-dim-hud-behind-views

Conversation

@woahwhattheheck

@woahwhattheheck woahwhattheheck commented Sep 6, 2026

Copy link
Copy Markdown

Fixes #2092

Opening the dash, scoreboard or music player left the queue, the side panels and the unit hover panel sitting at full strength behind the view, so they kept pulling the eye while you were reading something else.

Approach

One block in styles.less, no JS:

#ui:has(#dash.active),
#ui:has(#scoreboard:not(.hide)),
#ui:has(#musicplayerwrapper:not(.hide)) {
	#unit-hover-panel,
	#bottompanel {
		opacity: 0.12;
	}
}

I went this way rather than toggling a class from interface.ts because the views are opened and closed from a lot of places — toggleDash, closeDash, toggleScoreboard, closeScoreboard, toggleMusicPlayer, closeView, closeOpenInterfaceViews, the signal handler, and the Escape path. Keying off each view's own open state means every one of those routes is covered without touching any of them, and there's no way for a close path to leave the HUD stuck dim.

#bottompanel covers the queue and the left/right panels since they nest inside it; #unit-hover-panel is a sibling so it's listed too.

Purely visual — I left pointer-events alone so nothing about interaction changes — and the fade is dropped under prefers-reduced-motion.

Worth knowing

  • :has() is what makes the JS-free version possible. It's in every current browser (Chrome 105+, Safari 15.4+, Firefox 121+) and the codebase already leans on comparable things — backdrop-filter, inset, WAAPI commitStyles. If you support something older than that, say so and I'll switch it to a class toggled from interface.ts instead.
  • 0.12 is a guess at "very transparent". It's one number if you want it nearer 0.05 or 0.25.
  • The dash fades out over dashAnimSpeed while .active is still on it, so the HUD comes back up as the dash goes down rather than snapping.

Testing

No unit test — it's a stylesheet rule with no JS surface to assert against, and the repo's UI tests drive Queue directly rather than rendering the interface. Worth eyeballing: open each of the three views and check the HUD fades and comes back, including the dash's animated close.

Opening the dash, scoreboard or music player left the queue, side panels and
unit hover panel at full strength behind the view, competing with it for
attention.

Fade those panels back while any of the three is open. The rule keys off each
view's own open state (#dash.active, #scoreboard:not(.hide),
#musicplayerwrapper:not(.hide)) rather than a class set from JS, so no close
path can leave the HUD stuck dim, and every route that opens or closes a view
is covered without touching interface.ts.

Purely visual: the panels keep their existing pointer-events, and the fade is
dropped under prefers-reduced-motion.

fixes FreezingMoon#2092
@vercel

vercel Bot commented Sep 6, 2026

Copy link
Copy Markdown

@woahwhattheheck is attempting to deploy a commit to the FreezingMoon Team on Vercel.

A member of the Team first needs to authorize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

less distracting HUD when in the background [bounty: 8 XTR]

1 participant