The Markup Dialect of app.onepassapps.com: 56 Pages, 33 With Two h1s, One Build Template

I work on OnePassApps, the team behind app.onepassapps.com, so this is our own site. Everything below was measured on 8 November 2026 with plain HTTPS - one GET per URL, no browser, no session, no cookie, no JavaScript - and every number is what the server sent in that window.

We have written about our pages' head, their images, their scripts and their bytes. This one is about the markup dialect itself: the house style our build writes in, the build markers it leaves in the file, and the two places where the same document speaks in two different voices.

One dialect, byte for byte

All 56 URLs in our sitemap answer 200, and the first six lines of every one of them are byte-identical:

<!doctype html> <html lang="en-GB" class="dark" data-theme="dark" data-theme-preset="graphite" style="color-scheme: dark" > 

One <html> opening tag, one distinct version across 56 pages - the language is en-GB, the theme is dark with the graphite preset, and the colour scheme is declared inline on the element itself. The doctype is lowercase, the file is indented in two-space steps, and every one of the 56 documents ends with a trailing newline. The indentation has one blemish: 51 lines across 29 of the pages sit at an odd 7 spaces rather than 8 - two <section> lines on each of the 22 app pages, and one intro paragraph on each of the 7 Studio pages. The 23 guide pages are clean.

We have written about the head contract before - the 27 meta names that ship on every page - in The Head Contract of app.onepassapps.com. That post counted the meta tags. This one is about everything around them.

The build leaves its name in the file

The head block is wrapped in a pair of HTML comments, on 56 of 56 pages:

<!-- Route-aware crawler and social metadata is injected here at build time. --> <!-- TOOLPASS_SEO_START --> <title>MovieMatcherAI — Movies, TV and private watchlists — OnePassApps</title> ... <!-- TOOLPASS_SEO_END --> 

The 33 pages that boot the app bundle - the 22 app routes, the 7 Studio routes and the 4 other routes - carry a second pair around the body, TOOLPASS_SEO_BODY_START and TOOLPASS_SEO_BODY_END. The 23 guide pages do not, because they never boot the bundle at all: 23 of 56 Pages Ship No JavaScript is the measurement of that split.

Counting every HTML comment in the file:

The three extra comments on the 33 app-fleet pages are the two body markers plus a note about the crash fallback, which is the most interesting thing in this post.

33 pages ship two h1 elements

Here is the finding. On 33 of the 56 pages - every page that boots the app bundle - the served bytes contain two <h1> elements. On the 23 guide pages there is exactly one.

The second h1 is not a mistake in the copy. It is the crash fallback, and the file says so itself - one of its seven comments reads:

The shell-crash fallback (§15) is inert until public/shell-fallback.js clones it in, so it is never part of a route document's content. The build fills the support contact from the public configuration.

The markup it wraps:

<template id="shell-fallback-template"> <div class="fallback fallback--shell" data-shell-fallback="" hidden> <section class="fallback__card" role="alert" aria-labelledby="shell-fallback-title"> <img class="fallback__mark" src="/brand/sam-mark.svg" alt="" width="48" height="48" /> <h1 class="fallback__title" id="shell-fallback-title">OnePassApps stopped working in this tab</h1> 

It is inside a <template>, so the browser never renders it, and the hidden attribute plus the stylesheet keep it that way until the shell actually fails - shell-fallback.css shows .fallback--shell[hidden] { display: none; } and only :root[data-shell-failed] .fallback--shell[hidden] { display: grid; } reveals it. So the page renders one heading and the DOM carries two.

The guide pages have no template at all: zero <template> elements on 23 of 23, and the string "stopped working" appears on zero of them. They do link /shell-fallback.css, but they have no fallback markup to style.

The landmark split is the same split

The two page families also disagree about page furniture:

The other four routes - the home page, /voting, /plans and /terms - follow the app pattern (no <header>, no <footer>) but are not uniform: <nav> runs 1 to 2, <article> 0 to 1, and <section> 1 to 13, with /terms alone carrying 13 sections, 12 <h2> elements and a second <nav>.

The app-fleet pages are bare: a nav, a main, some sections, and two ARIA roles that are not the guide pages' - role="alert" on the fallback card, and role="status" with aria-live="polite" and aria-busy="true" on the startup shell that says "Loading OnePassApps". The guide pages are a full document: two headers, a footer, a nav rail, an article and eight or nine sections. The guides index carries 22 <h2> elements - one per guide - and no <section> at all.

There is one more tell. The 23 guide pages put data-public-discovery on their <main> element, and the 33 app-fleet pages put data-onepassapps-seo-fallback on a wrapping <div>. aria-current="page" appears once on each guide page and twice on the guides index, and on zero of the other 33.

The small tells

Three details make the dialect recognisable.

One single-quoted attribute, on all 56 pages. Every attribute value in our markup is double-quoted, with exactly one exception: Cloudflare's own beacon, which arrives as data-cf-beacon='{"version":"2024.11.0",...}'. That is 1 single-quoted attribute per document, against 262 to 1,188 double-quoted ones.

Two conventions for void elements. 35 void elements are written HTML-style with a closing slash - <meta charset="UTF-8" />, <img ... /> - but the bundler-injected <link> tags are not. On the app pages there are 3 modulepreload links and 1 cross-origin stylesheet, all four written without the slash:

<link rel="modulepreload" crossorigin href="/assets/rolldown-runtime-QTnfLwEv.js"> <link rel="stylesheet" crossorigin href="/assets/index-B_evf03w.css"> 

So the hand-written part of the document and the tool-written part of the document use different syntax, in the same file. The guide pages have the same 35 slashed void elements and just 1 unslashed one, because they have no module preloads; the /guides index has 36 slashed, its extra one being the second brand mark - the same /favicon.svg at 56 pixels instead of 32.

Three ways to write an apostrophe. The non-breaking space is always  , on all 56 pages, 74 times in total. & appears on 15 of the 56. But the apostrophe is written two different ways: 23 pages use the decimal ' and 2 pages - /plans and /terms - use the hex '. The same character, two encodings, one build.

What this is not

These are the bytes the server sent on one day, from one network, signed out, with no JavaScript. A browser parses the <template> content into its own inert document, and this post does not claim anything about how any particular browser treats it. It is not an accessibility audit, it is not a recommendation, and it is not a bug report - the fallback heading is deliberate, it is hidden by default, and it only appears when the app bundle fails to mount.

The comments are the build's own words; we are quoting the file. We have described the fallback card in What app.onepassapps.com Sends Before JavaScript Runs, and the miss page in The 404 Page app.onepassapps.com Serves. This post is about the shape of the file itself.

If you write static pages and want the same thing: pick one dialect and hold it. Ours is lowercase doctype, two-space indentation, double-quoted attributes, one <html> tag shared byte for byte across every route, and build markers left in the file so the next person can see where the machine wrote and where the human wrote.

The page this was measured on is app.onepassapps.com, and the 22 guide pages are the other half of the story at app.onepassapps.com/guides.