This is the first in a series of four posts (archives; paid subscriptions and monetization; email delivery; data and analytics) about some of the work we have planned for 2026. It's meant to be a little more informal and technical than our usual blog posts; if you're just interested in how it impacts you, we'll have changelog entries as these changes are shipped!
If I'm being totally honest, I've been unhappy with the state of the archives for a while now. It's a one-two punch:
- We have—or had—two separate themes, "classic" and "modern," each with completely different HTML and CSS.
- We also allow users to supply custom CSS to tailor their archives however they wish, and we always will.
This combination makes iterating on the archives tremendously difficult. We're not just dealing with two separate themes; we're cross-referencing every change to make sure we don't break anyone's custom CSS.
All of this has resulted in a bit of learned helplessness. It's felt like an uphill battle to clean up, modify, or tweak the design of any archive page. As a result, any changes we've made over the past few years have been purely additive. This culminates in archives that look disjointed—some pages, like comments pages, have designs or styles incongruous with the emails on which they reside.
Internally, we've had a project for a while to solve this problem once and for all. Inspired by the CSS Zen Garden (which perhaps dates me as a developer), our end state looks something like this:
- A single set of HTML templates chock-full of semantic CSS classes, making it easy to confidently overwrite a given rule or page.
- A well-structured core CSS theme handling responsiveness, accessibility, a basic color palette, typography scale, and so on.
- Multiple CSS themes that sit atop that core theme to provide an opinionated look for your archives.
- Surfacing certain CSS variables like font or background color as design inputs so non-technical users can make changes without having to ask Google what CSS is.
- As always, a break-glass-in-case-of-emergency CSS override for folks who really know what they're doing.
This allows a sliding scale of customization: non-technical users can choose a theme and be done with it, more persnickety users are armed with knobs and dials to tweak the design to their liking, and developers are armed with a single, consistent set of HTML and CSS to build on top of.
We've started making these changes, and you might already notice some of the benefits. Both themes are going to suddenly look a little more cohesive and coherent—and a little less, well, janky. Our goal is to not break any existing functionality or CSS, but I'm sure we're going to end up doing so anyway. Please let us know if and when we do. Full documentation and more themes will be coming soon. This is just the groundwork.
So that's the look and feel of the archives. But what about the actual experience of using them?
Fundamentally, the archives were built on an assumption that they're largely static. It's just email content preserved in amber. While this is true for many use cases, it's increasingly untrue for a larger proportion of our users who use interactive content such as comments, surveys, or embeds. We never really thought cohesively about how to build multiple pieces of interactive content within the archives, and as a result, things like authentication or entitlement are built ad hoc, and the user experience suffers as a result.
Our plan is to add the good parts of a more interactive application without sacrificing the performance, stability, and accessibility that our current implementation excels at. Specifically, we'll likely continue to render a more inert version of interactive forms, like the comments section, then progressively enhance them to feel more modern. For instance, you should be able to reply to a comment in a thread without leaving the page.
Lastly: none of this is indicative of any strategic change. We joke a fair amount internally about making sure that we don't accidentally end up becoming WordPress. There exists a Venn diagram between what we can offer and what a more full-fledged CMS can offer; Our goal is not to increase the amount of overlap so much as it is to make sure that the CMS-shaped bits that we do offer are as good as they can (and should!) be.