- Shipped
- August 15, 2026 at 5:30 AM UTC
- Author
- kamo
- Commit
- f999f91
Adds "Home Page Logo Overlay" to Branding on **************** directly above Background Watermark: No Overlay, White, Black, and every step of the org's own primary and secondary ramps. Set it and the masthead logo at the top left of the home page renders as a solid silhouette in that colour. Default is No Overlay, so nothing changes for an org that never opens the field. What is stored is a TOKEN, not a hex — PRIMARY_DARKER, never #004ba0 — resolved against the org's palette at render time. An org that rebrands keeps an overlay that still matches its colours, instead of a hex frozen at the moment somebody picked it out of a dropdown. logoOverlay.ts owns that vocabulary and the resolution, the same way watermark.ts owns the watermark's. Three details worth knowing: - The dark shades already existed on the wire. The backend has sent all five steps of each ramp for as long as EmbColorPalette has, but Organization.fromJSON only ever mapped three, so colorDark/colorDarker fell on the floor here. They are carried now, which is what gives the darker tokens a colour to resolve to. - ThemeLogo does this with a CSS mask, not a filter. A filter can only push the existing colours around and cannot reach an arbitrary target, so the logo's own alpha becomes a mask and the colour is painted behind it. The <img> stays mounted and merely invisible: it is the only source of the naturalSize the sizing block depends on, and it keeps occupying its exact normal box so the masked layer can fill it. Callers that pass no overlayColor render byte-identically to before. - A brand token whose shade the org never set resolves to no overlay rather than falling back to a neighbouring shade. Seeing the logo you already had beats seeing a colour nobody chose. Requires the home_logo_overlay column (KamoInitializer, applied) and a SecurityService rebuilt against the shared-lib entity; until that lands the field reads and saves as No Overlay rather than erroring.