Three families, a ten step ramp with eight fluid sizes above it, three named weights and six leadings. Every specimen below wears the token by name. The weights are measured by ink rather than by the number in the declaration, because a weight that has no face behind it renders as the nearest one that does and says nothing about it.
Three is the ceiling. A fourth family would have to name a job the other three cannot do, and there is not one.
Will it happen?
The question, the heading, the number a person came for. Never a paragraph: its tighter fit and its wider counters are read as voice at 24px and as noise at 13.
Will it happen?
Everything a person reads rather than scans: prose, labels, buttons, rows. It is the root family, so anything that does not say otherwise is this.
38% $84,200
A number that has to line up with the number under it: odds, volume, an amount, a wallet address, a timestamp. Mono is a promise that the figure is exact, so it is never used for a word that is not a value.
The families do not overlap and that is what makes them readable as roles. A display face on a paragraph reads as a typo; a mono face on a sentence reads as code. Every crossing of that line in this product is a bug, and there are none.
Every face is a woff2 in assets/fonts/, declared
once in fonts.css. No page may call a font host: the request carries a
visitor's IP and User-Agent to a third party before the consent banner this product ships has
asked them anything, which the Munich district court ruling of 20 January 2022 treats as a
transfer of personal data. It is also three round trips on the critical path, two of them DNS
and TLS to a host that serves nothing else. Latin and latin-ext only,
font-display:swap on every face.
And since 2026-08-14 the four faces the product uses are not fetched at
all: they are data: URIs inside fonts.css. A font is fetched in
CORS mode even from its own origin, and file:// gives every file its own opaque
origin, so from a page opened off the disk there was nothing for the fetch to match. Chromium
refused the preload, said so in the console, and loaded the face through
@font-face anyway; WebKit refused both and drew the whole product in a fallback
face. Measured with a probe string at 40px from disk: 'DM Sans',serif came back
at 369px, the serif fallback to the pixel, against 410 in Chromium, and 410 in both
after. Only four of the eight files were ever requested by anything (163, 163, 109 and
104 times across the 163 documents, and 0 for each of the four latin-ext cuts), which is
what made inlining small enough to take: +105,980 bytes of base64 against 68,725 of font
requests, and the 326 <link rel="preload"> lines deleted. Layout shift
re-measured at 400 Kbps over 27 screens: 0.0000 mean before and after.
18 files, 373 KB, and 131 KB of unique typeface. Checksums say why:
400, 500,
600 and 700 latin are byte for byte the same 36,980 bytes, and the
four latin-ext the same 18,192.147,920 shipped for 36,980 of dataDM Sans and Space Grotesk were fetched as variable fonts and then copied
once per weight. One file carries the whole weight axis; the repository holds four and three
copies of it and declares each copy at a single weight. It works, because a browser given a
variable font with a single font-weight descriptor pins the axis to that value, and
the ink measurements in the next section prove it works. What it costs is 242 KB of
duplication, 65 per cent of the font payload, and a cache that has to hold seven copies of
two typefaces.
The repair is one @font-face per family with
font-weight:400 700 as a range and one file behind it. That is a value change, so
it belongs to the consolidation and not to this page.
A declared weight with no face behind it does not fail. It renders as the nearest face that exists, silently. So the reading below is not the number in the CSS: it is the count of dark pixels the browser actually paints for one string at 48px, which is the only thing that can tell a real weight from a fallback.
--weight-bold is 700 and IBM Plex Mono has no 700. Every
mono element that reached for bold would render semibold and never say so. Today none does: all
five mono declarations in components/ use --weight-medium or
--weight-semibold, so this is a trap rather than a defect, and it is the kind
that is only found by measuring the paint.
And the most used weight in the product has no name
The ramp is --weight-medium:500,
--weight-semibold:600, --weight-bold:700. 400 is not a token,
and 400 is what 192 of 260 text elements on the feed render at, because it is the root
default and nothing overrides it. One component already needs it and had to type it:
betpanel.css writes font-weight:normal, the single weight literal in
the whole system. A step of a scale that the scale does not name is a step somebody will type.
The ramp steps by 1 up to 14, then by 2 and by 4. 10px is the floor a mobile product should set. The half pixels it used to carry, 9.5 and 10.5 and 11.5, were rem arithmetic inherited from the grey wireframe rather than sizes anyone chose; they were rounded up, so no line got smaller.
The ramp is bottom heavy and that is the product. 200 of the 218 size declarations are 10 to 14. This is a dense screen of odds, volumes and dates, not an article, and the four steps above 16 exist for one heading each.
Eight fluid sizes, and each is one token rather than a size plus a rule
A display size is fluid, so it is declared as a clamp and not as
a size with a media query beside it. Resize this window and the eight below move; the ten above
do not.
A correction to the census, and it retires a finding
census.md lists seven font sizes on the anchor screens and calls
19.2px "the only value on the list that no one typed", the cheapest fix in the pass.
Nobody typed it and it is not a defect. It is
--display-hero: clamp(19px, 1.5vw, 23px) on the featured hero question, and 1.5vw of
a 1280 viewport is exactly 19.2. There are two more of them at that width, 23.68 and
29.44, from --display-quote and --display-tagline, and the census
did not report those only because no control wore them. A fluid size lands where the viewport
puts it; that is the whole point of declaring it fluid. The item is closed here rather than
carried into the consolidation.
Unitless, so a line box scales with its own size and not with the root. Fifty nine declarations, all six tokens live, and not one raw value in a component.
Family, size, weight and leading are all tokens and all are held. Letter
spacing is not. 59 declarations across components/, 13 distinct values,
and zero tokens:
-.03em 4 -.02em 9 -.01em 5display headings, where a large size closes upnormal 3 0 3two spellings of the same thing.01em 4 .03em 12 .04em 3 .05em 3 .06em 5 .07em 3 .08em 5 .1em 2small uppercase labels, where a small size needs the airEight opening values between .01 and .1 is not a scale, it is a series of separate afternoons. The three groups above are real and a set of three or four tokens would hold all 59 declarations: a tightening for display, a neutral, and two or three opens keyed to size. It is the same finding the census made about padding and height, on the axis nobody thought to count.
Tracking is also the axis where 0 and normal both
appear. They compute the same and they are two ways of saying it, which is how an axis with no
token ends up with two spellings of nothing.
And no size literal left
Of 238 font-size declarations in the system,
238 read a token: 222 through the --text-* ramp, 10 through
--display-*, 5 that are font-size:0, and one through
--logo-size, which is itself set from the ramp. Re-counted 2026-08-16 from the
source with comments stripped.
This section said 217 of 218, and the exception is
chart.css: .chart-svg text{font-size:7px} until that count.
The rule it named was deleted on 2026-08-15 and the page went on documenting it, which
is the vitrine describing a system that had moved. The argument was worth keeping and
chart.css keeps it in the comment where the rule stood: 7 was a USER UNIT inside a
viewBox="0 0 300 100" drawn with preserveAspectRatio="none", so it was
never 7 screen pixels and rem would have made it follow the reader's browser
setting while the plot went on following the viewBox. What retired it was not the argument but
a reading taken in the DOM instead of the source: the chart SVG carries no
<text> node on any of the 106 painted screens or the 57 kit pages.
The column a person reads. Measured on the feed at 1280: the card's why line runs 40 characters at 13px with 19.5px of leading, and a card paragraph runs 26. Both are short, and deliberately: a card is scanned in a grid, not read in a column, and 40 characters is what a three-across grid at 1120 leaves.
The reading columns are the ones to hold to a measure, and they are the
SEO plate and the how-it-works prose, not the cards. This page holds itself to
74ch, which is the value the deleted kit arrived at after finding a bare paragraph
running at 99 characters while the footnote beside it was held to 76: the block a reader
came for was the one with no max-width at all.
Funding talks have stalled twice this quarter, but past deadlines settled late.
A market resolves against a source named on the page before the first bet is taken, and the source cannot be changed after that. If the source does not publish by the close date, the market voids and every stake is returned.
A method note, and this page tripped over its own subject. The three
family cards in section 01 rendered in DM Sans at 12px on the first build: all three of them,
one typeface shown three times. _page.css carried .tk-card p,
specificity 0-1-1, and the .tk-f-display and .tk-s-30 utilities beside it
are 0-1-0, so the descendant selector won every specimen in the same stylesheet. It is the
exact failure the @import order in components/index.css exists to
prevent, met inside the stand file, and looking at the page would not have caught it: a
heading in the wrong sans at the wrong size still looks like a heading. It was found by asking
the browser which family each specimen had actually resolved to.
font-weight:400 700 on one @font-face removes it
without changing a single rendered glyph.normal for it.--weight-bold is documented as unavailable in mono, or
the mono 700 face is added. Nothing asks for it today; the next thing that does will get
semibold and no warning.19.2px item is closed, not carried. It is a
clamp resolving at 1280, and two more fluid tokens do the same thing at that
width. A fluid size lands where the viewport puts it.