Building a Layout‑First Editor for Careers Content

When most people picture a “document editor,” they think about typing words into a blank box and maybe adding some light styling. Our editor flips that idea on its head. Instead of starting with text and trying to make it look good afterward, we start with design. The template (what we call the “chrome”)  is the backbone, and the content flows into it.

This approach makes sense for the kind of work we’re doing. CVs, and cover letters don’t just need to be accurate; they need to be well-composed, visually balanced, and instantly legible. A template defines the layout: where the header lives, how the sidebar sits, where the hero section should be. A theme defines the aesthetic: the colors, typography, spacing, and accents. Together, they form a visual system, and the editor’s job is to let you manipulate the content without breaking that system.

How it works today

Under the hood, every page starts with a skeleton. The skeleton sets the page size and zoom, tracks the header and footer heights, and divides the rest of the space into editable regions. These regions are what we call zones. A zone is a container for blocks, which are the smallest editable units like your name, work experience list, or a call-to-action.

The skeleton also has to deal with a tricky problem: we’ve been migrating from an older, multi-zone layout model to a newer root-canvas model. In the old approach, a page might have half a dozen discrete zones arranged manually. The new approach gives you one full-bleed canvas between the header and footer, making layout logic and stacking much simpler. In the code, you can see this in the conditional that checks for rootCanvasZoneId; if it’s present, we render the single canvas, otherwise we fall back to the older multi-zone path.

On top of that structure sits the template chrome layer. This is where the actual visual layout comes from: the coloured bar across the top, the side panel, the subtle background textures. In CSS terms, it’s often just a .template-page element with a layout class, and its shapes are drawn with ::before and ::after pseudo-elements. The template also applies a theme by setting CSS variables for colours, typography, and spacing.

The recent challenge

When we first wired the chrome into the zones view, we hit a problem. Our theme injector writes its variables to :root, which means they apply to everything in the editor. That’s perfect for export, but in the editor it can turn block text the same colour as the page background, which looks like everything disappeared. It wasn’t actually gone; it was just white-on-white.

Layering was the other culprit. Some templates bring their own z-index values for decorative elements. Without hard rules, those pseudo-elements could end up floating above the zones and footer.

The fixes are straightforward but important: scope the theme variables to the template element instead of :root during editing, and enforce z-index discipline with chrome at the bottom, content above it, header and footer above everything.

Where it's headed

The goal is to finish the migration to the root-canvas model. Once every page uses a single canvas framed by a header and footer, the editor becomes much simpler to reason about. Snapping, guides, and alignment tools all work off the same grid. The content flow is predictable. And we can start layering in smarter features: adaptive spacing that scales with page size, region-aware block behaviour, even template variants like “compact” or “airy” that can be swapped without changing the underlying structure.

Theme handling will also get more deliberate. In edit mode, we’ll scope variables so the interface stays readable; in export mode, we’ll switch to global variables so the output is perfectly branded. Designers will be able to define tokens and layout variants without touching the content logic, and users can swap templates knowing their content will survive the change intact.

Why it matters

In a hiring manager’s inbox, your document has seconds to make an impression. A layout-first editor gives you a head start. Every element has a place, every page feels balanced, and you never have to fight the design to get your point across.

By keeping design and content loosely coupled but tightly aligned, we can move fast on both fronts: new templates can ship without breaking existing documents, and new editing capabilities can arrive without re-engineering the layouts. It’s a system that’s technical under the hood, but it’s all in service of a simple goal: career documents that look as good as they read.

Share the Post:

Related Posts

  • All Post
Load More

End of Content.

Scroll to Top