One background, every public page

Until recently, moving between pages on cfin.be meant moving between backgrounds too. The landing page carried its own gradient treatment, the Performance page had a different one, and the sign-in screen was different again. None of it was wrong on its own page — but side by side, a visitor clicking from the homepage into the Performance page, or from a blog post into the FAQ, saw the page underneath visibly change colour and shape around content that otherwise looked identical.

What changed

Every public page now reads its background from one CSS variable instead of drawing its own. The landing page keeps one additional layer on top of that shared base — a quiet, scroll-following glow behind the hero and the pricing calculator — but the flat colour underneath it is the same token every other public page uses, in both light and dark appearance.

The practical effect is easiest to see by comparing two pages that have nothing else in common. The blog index and the homepage serve completely different content — a grid of post cards against a hero and a pricing calculator — but the page itself, the colour you see at the edges and between cards, is identical.

Why one token instead of five

A shared variable means a future change only has to happen once. Before this pass, adjusting the background meant finding and editing it on every template that had its own copy — and a copy that was missed quietly drifted out of step with the rest. One token removes that risk by construction: every public page reads the same value, so there is nothing left to drift.

It also removes a specific kind of visual noise. A page that changes its backdrop on every navigation asks your eye to re-adjust each time, even when nothing meaningful changed. Keeping the base flat and consistent lets the content — a chart, a form, a blog card — be the only thing that actually moves.

What stayed

The landing page's ambient glow is deliberately kept. It is a separate, additional layer — two soft shapes that drift gently as you scroll — and it still only appears on the landing page, where the long scroll and the pricing calculator benefit from a bit of depth. Content cards everywhere stay flat on top of the background regardless; the shared layer never paints inside a card, so nothing is harder to read because of it.

Reduced-motion preferences are respected throughout: if your system is set to minimise animation, the ambient layer simply rests in its start position instead of drifting, on every page that includes it.

Where the inconsistency came from

The flat background colour itself was already unified in an earlier pass, so that html and body resolved to the same token on every public page. What that earlier pass missed were the decorative layers sitting on top of it — a leftover gradient effect here, a particle layer there — carried over individually by pages that had not been revisited since. The Performance page and the login page in particular kept their own older backdrop treatment even after the base colour underneath had already been unified, which is precisely the kind of partial fix that looks correct until you actually place two pages side by side.

This pass closes that gap directly: every public page now force-hides any leftover decorative background layer it might still be carrying, except for the landing page's own ambient glow, which is the one layer deliberately kept. A page is either drawing the shared flat token with nothing extra, or the shared token plus that one explicitly-kept layer — nothing in between.

What to look for

If you compare the homepage, the Performance page, the FAQ and the sign-in screen side by side, the one difference you should see is the landing page's extra glow — everything else, the flat colour behind every card and section, should match exactly, in both light and dark appearance.