This colophon documents the technical and design decisions that underlie the Snoep encyclopedia. The intended reader is someone who has noticed the design choices and wants to understand the reasoning, or who is interested in the technical craft of building an enduring reference site, or who is wondering whether the project is run on a contemporary content-management stack (it is not). The decisions described here are deliberate, not defaults; some of them have non-obvious trade-offs that the editors think are worth being explicit about.

Typography

The site is set in Fraunces, a contemporary serif typeface designed by Phaedra Charles and Flavia Zimbardi, released through Undercase Type and Google Fonts in 2020. Fraunces is a variable-font implementation of a "warmer, beautified" serif, with axes for weight, optical size, softness (SOFT), and "wonkiness" (WONK). The site uses these axes deliberately: large display sizes are set with high optical size and increased softness for the warmth that the design intends; italics use the WONK axis to introduce the slightly sinuous variant strokes that distinguish Fraunces's italics from more conventional serif italic forms. The accent colour for italic emphasis (the deep red of the wordmarks and the inline italic spans) is the editorial counterpart to the typographic warmth.

The typographic decision is not arbitrary. The encyclopedia covers a subject that has, in its Dutch and Belgian incarnation, a strong cultural connection to handcraft, regionalism, and pre-industrial production technique. A flat, modern, sans-serif typeface — the conventional choice for contemporary reference websites — would have been technically correct but tonally wrong. Fraunces sits at a usable point between the older type traditions that the subject suggests and the contemporary digital legibility that the medium requires. The result is a site that reads as a serious reference rather than as a blog or a magazine, which is the editorial intention.

The decision to use a single typeface throughout — with the system sans-serif stack reserved only for small UI labels and metadata — is also deliberate. Multiple typefaces would have produced a more varied visual texture but at the cost of the typographic coherence that the encyclopedia depends on. The reader who reads several entries should experience a continuous typographic environment rather than a sequence of differently-styled pages, and the single-typeface choice produces this continuity.

Technology

Snoep is plain HTML. There is no content-management system, no database, no JavaScript framework, no API, no analytics, and no third-party tracking. Each page is a single HTML file with inline critical CSS, served as static assets from a conventional web host. The pages load in well under a second on a slow connection, work without JavaScript, and will continue to work if the underlying web technologies that deliver them — HTTP, HTML, CSS — remain in something like their current form.

This decision is, in 2026, somewhat unusual. The contemporary norm for reference websites is to build on a content-management framework (WordPress, Ghost, or one of the static-site generators like Eleventy or Hugo), to load content dynamically through JavaScript, and to instrument the site with analytics and tracking that allow editorial decisions to be informed by reader behaviour. None of this is wrong, but all of it introduces dependencies that the project's editors prefer to avoid. A WordPress site requires database backups, security updates, plugin maintenance, and theme compatibility checks; a static-site generator requires a build pipeline that must be maintained alongside the content. Plain HTML requires only that the files be served.

The trade-off is that editorial workflow is more manual. Adding a new entry requires writing the HTML directly (with the design-system CSS reproduced in the page), updating the navigation pages by hand, and regenerating the sitemap.xml and feed.xml files. The editors regard this trade-off as worthwhile for a project intended to remain stable over decades; the alternative — a dependency-rich technical stack that requires continuous maintenance — would have introduced a continuous tax on the project's editorial capacity that, over time, would have outweighed the workflow convenience.

Performance

Each entry page is approximately 25–40 kilobytes of HTML, including the inline CSS and the per-page metadata. The Fraunces typeface is loaded from Google Fonts as a separate request and adds approximately 70 kilobytes (cached on first load). No other external resources are loaded — no images by default (illustrations are inline SVG), no scripts, no fonts beyond Fraunces, no analytics beacons. The total page weight on first load is approximately 100 kilobytes; subsequent pages benefit from font-caching and load at approximately 30 kilobytes each.

The performance characteristics are not the result of optimisation; they are the result of not adding things that would have made the site slower. Reference sites of comparable scope, built on contemporary content-management frameworks, routinely weigh 2–5 megabytes per page and require 30–80 separate HTTP requests to load. Snoep is, in this respect, an old-fashioned web site: it does what is necessary and not much else, and the consequence is that it is fast on essentially any device, on essentially any connection.

Accessibility

The site aims to meet WCAG 2.2 AA standards across all pages. The principal accessibility-relevant decisions are:

  • Semantic HTML5 throughout: article, section, nav, aside, figure, time, with the relevant ARIA labels where additional clarification helps screen readers.
  • Heading hierarchy strictly observed: a single h1 per page, descending through h2 and h3 in proper order without skipping levels.
  • Colour contrast at the AA threshold across all text-on-background combinations, including the accent-red against the cream background (which checks at 6.4:1, well above the 4.5:1 minimum for body text).
  • All non-decorative SVG illustrations carry meaningful aria-label and role="img" attributes; decorative SVGs use aria-hidden="true".
  • The prefers-reduced-motion media query is honoured throughout, with all animation suppressed when the user has indicated a preference for reduced motion.
  • The site works without JavaScript (because there is no JavaScript), and works at high zoom levels without horizontal scrolling.

Readers who encounter accessibility issues are invited to report them through the procedure described in the about page. Accessibility corrections are treated with the same priority as factual corrections.

Versioning and revision

Each entry carries two date stamps in its metadata: a "first published" date and a "last revised" date. Substantive revisions to an entry — those that materially change a published claim — produce a change in the last-revised date and a brief note in the entry's revision log. Cosmetic, typographic, and formatting changes do not produce a revision-date change. The intention is that the date stamps reflect the state of the encyclopedia's editorial confidence in the entry, not just the date of the most recent edit.

The revision logs are not currently published per-entry, but are held in the editorial system and are available on request through the corrections procedure. This may change in a future iteration of the site if reader interest in the revision history justifies the additional editorial overhead. Most readers, the editors expect, will not need it; serious citation users almost certainly will, and the procedure for accessing the revision logs will scale to that demand.

Hosting and resilience

The site is hosted on standard commercial web hosting infrastructure, with the static HTML files served from a conventional web server. The hosting arrangement is deliberately ordinary: any competent web host could serve this site without modification, and the project's continued operation does not depend on any specific hosting provider, content-delivery network, or technical platform. The DNS, the certificate, and the static files are the entire technical surface area of the project.

This arrangement is intended to maximise the project's resilience to the kind of external shocks that have closed many comparable reference sites over the past decade — vendor lock-in, platform deprecation, the failure of a content-management system's commercial maintainer. Snoep can be moved to another hosting provider in approximately twenty minutes; the site can be archived locally by any reader using a standard web-archiving tool; the site can be republished from the archive by any third party who maintains the CC BY-SA licence terms. None of this is theoretical: the editors have rehearsed each of these scenarios as part of the project's design.

The expected service life of the site, in the form described here, is at least a decade and probably substantially longer. The underlying technologies (HTML, CSS, the HTTP protocol, the Fraunces font) are all stable enough that the site should remain functionally unchanged for as long as the modern web continues to exist. Whether the editorial team continues to maintain the encyclopedia for that period is a separate question, but the technical infrastructure is, by design, capable of outlasting the editors.

A closing note on permanence

One of the project's quieter motivations is the observation that the present web is, by historical standards, unusually impermanent. Most popular reference sites from the late 1990s and early 2000s no longer exist; many that survived to 2010 have been substantially altered or have lost their original content; the average lifespan of a hyperlinked URL on the web is, by some estimates, less than five years. Snoep is built, deliberately, against this drift. The site's content, its design, its technical implementation, and its operating model are all chosen with the intention of producing a reference work that will remain accessible, accurate, and citable in 2046 — the encyclopedia's twentieth anniversary, if the project survives that long.

Whether the project survives that long is, of course, beyond the editors' control. But the project is, in the meantime, doing what reference works ought to do: documenting a subject carefully, in a form intended to outlast the editorial team that produced it, in a technical container intended to outlast the platforms that currently support it. The colophon is, in this small sense, also a statement of editorial intent: this is a site built to be read, cited, and trusted, and the design decisions described above all serve that purpose.