When visiting the test site on a normal browser, the prerendered/stale color scheme flashes briefly before the dynamic site loads.
The SSR server correctly injects fresh color CSS custom properties as an inline <style> block before </head>. However, _themes.scss also compiles color defaults on :root into the styles-*.css stylesheet, and that stylesheet loads after the server-injected block, overwriting the correct colors with build-time defaults.
The cascade order:
Server-injected <style> with correct colors from API
Compiled styles-*.css with hardcoded defaults (overwrites #1)
ThemeService.apply() corrects colors after Angular boots (too late)
Fix
Remove all color CSS custom properties from :root in _themes.scss. Non-color properties (fonts, radii, shadows) remain as they do not change between deploys.
Now the server-injected <style> is the sole source of truth for colors at first paint.
## Problem
When visiting the test site on a normal browser, the prerendered/stale color scheme flashes briefly before the dynamic site loads.
The SSR server correctly injects fresh color CSS custom properties as an inline <style> block before </head>. However, _themes.scss also compiles color defaults on :root into the styles-*.css stylesheet, and that stylesheet loads after the server-injected block, overwriting the correct colors with build-time defaults.
The cascade order:
1. Server-injected <style> with correct colors from API
2. Compiled styles-*.css with hardcoded defaults (overwrites #1)
3. ThemeService.apply() corrects colors after Angular boots (too late)
## Fix
Remove all color CSS custom properties from :root in _themes.scss. Non-color properties (fonts, radii, shadows) remain as they do not change between deploys.
Now the server-injected <style> is the sole source of truth for colors at first paint.
The SSR server injects fresh color CSS custom properties as an inline
<style> block before </head>, but _themes.scss also set hardcoded
color defaults on :root at build time. The two :root blocks compete
in the cascade — the compiled stylesheet (loaded after the inline
<style>) overwrites the server-injected colors, causing a visible
flash where wrong colors render briefly before ThemeService.apply()
corrects them.
Removing the color properties from :root in _themes.scss makes the
server-injected <style> the sole source of truth for colors. Non-color
properties (fonts, radii, shadows) remain as build-time defaults since
they don't change between deploys.
The server-injected inline <style> was missing the three derived gradient
variables (--sky-gradient, --sunset-gradient, --mixed-gradient) that
components reference via var(). Without them, components fell back to
SCSS build-time defaults on the first paint, causing a visible flash
before ThemeService.apply() corrected the values.
Additionally, migrate three component SCSS files from hardcoded SCSS
color variables to CSS custom properties so the first paint uses the
server-injected runtime colors:
- login.component.scss: backgrounds, text colors, borders, focus rings
- events.component.scss: event date card background gradient
- about.component.scss: donation CTA background gradient
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
kfj001
Problem
When visiting the test site on a normal browser, the prerendered/stale color scheme flashes briefly before the dynamic site loads.
The SSR server correctly injects fresh color CSS custom properties as an inline <style> block before </head>. However, _themes.scss also compiles color defaults on :root into the styles-*.css stylesheet, and that stylesheet loads after the server-injected block, overwriting the correct colors with build-time defaults.
The cascade order:
Fix
Remove all color CSS custom properties from :root in _themes.scss. Non-color properties (fonts, radii, shadows) remain as they do not change between deploys.
Now the server-injected <style> is the sole source of truth for colors at first paint.