/* ========================================================================== Control-F — Design Tokens Single source of truth. Derived from "Brand Design Review 2" and the Figma redesign of the Landing Page / Über uns page. Nothing in this file styles anything. It only declares values. ========================================================================== */ :root { /* ------------------------------------------------------------------ 1. CORE PALETTE — "Hauptfarben" The seven brand colours, exactly as defined in the manual. Lime is the light layer and is used sparingly; CF-Grau is the atmosphere the whole site sits in. ------------------------------------------------------------------ */ --cf-lime: #E1FF00; --cf-glas: #C5EBE2; --cf-sky: #72B0E2; --cf-violett: #7E7FE1; --cf-weiss: #FFFFFF; --cf-grau: #CFCFCF; --cf-schwarz: #000000; /* Schwarz is the dark surface of the system — the footer, the logo plate, the consent banner, the nav plates. The mockups paint those a near-black anthracite (#1B2022); the palette already contains a black, and a second dark that differs from it by 1.2:1 is a colour nobody can name and every component has to remember. The eighth token is gone: --surface-inverse resolves to --cf-schwarz. */ /* ------------------------------------------------------------------ 2. RAMPS — "Schattierungen" Each accent is mixed with white (100–300) and with black (700–900). Step 500 is always the core brand colour. ------------------------------------------------------------------ */ --lime-100: #FAFFD9; --lime-200: #F6FFB3; --lime-300: #EFFF80; --lime-500: #E1FF00; --lime-700: #A8BF02; --lime-800: #4E5901; --lime-900: #222600; --glas-100: #F6FCFB; --glas-200: #EEF9F6; --glas-300: #E2F5F1; --glas-500: #C5EBE2; --glas-700: #94B0A9; --glas-800: #45524F; --glas-900: #1E2322; --sky-100: #EAF3FB; --sky-200: #D5E7F6; --sky-300: #B8D7F1; --sky-500: #72B0E2; --sky-700: #5684A9; --sky-800: #283E4F; --sky-900: #111A22; --violett-100: #ECECFB; --violett-200: #D8D9F6; --violett-300: #BEBFF0; --violett-500: #7E7FE1; --violett-700: #5F5FA9; --violett-800: #2C2C4F; --violett-900: #131322; /* Neutral ramp — the workhorse. CF-Grau (300) is the anchor, not white. 075 is the manual's 70 %-white step. The plate paints it #F1F1F1 but labels it #D9D9D9; the painted value is the arithmetically correct one (0.7·255 + 0.3·207 = 240.6), so the ramp follows the paint. D9D9D9 is kept as 200 because the mockups use it as a UI grey — it is just not a step on this ramp. See foundations/colors.html. */ --grey-000: #FFFFFF; --grey-050: #F8F8F8; --grey-075: #F1F1F1; --grey-100: #E7E7E7; --grey-200: #D9D9D9; --grey-300: #CFCFCF; /* = CF-Grau */ --grey-400: #919191; /* UI-only: mono labels, meta text */ --grey-500: #9B9B9B; --grey-700: #484848; --grey-800: #1F1F1F; --grey-900: #000000; /* ------------------------------------------------------------------ 3. SEMANTIC COLOUR Use these in components — never a raw ramp value. ------------------------------------------------------------------ */ --surface-page: var(--grey-300); --surface-base: var(--grey-300); /* A STEP AWAY FROM THE PAGE IS A RATIO, NOT A GREY, and this token was the grey until it was measured. --surface-sunken was grey-100 (#E7E7E7). The number is only meaningful against --surface-base, CF-Grau — and no page in the system is painted CF-Grau. Every page carries .page-wash, which is --surface-page-wash: CF-Grau to white, `background-attachment: fixed`, `background-size: cover`. Fixed and cover together mean the wash spans the VIEWPORT, not the document, so it does not scroll: the page under any element is a function of where that element currently sits on screen, and it runs the full 207 → 255 every time. The steps were calibrated against a colour that only exists in the top row of pixels. Measured on patterns/landing-page.html at 1280x900, walking .cf-process __note down the viewport in 6 % steps and sampling the wash beside it in the same screenshot row: note at 14 % of viewport height wash 210 #E7E7E7 reads +21 note at 44 % wash 222 #E7E7E7 reads +9 note at 65 % wash 231 #E7E7E7 reads 0 <- note at 86 % wash 241 #E7E7E7 reads -10 So an absolute grey inside the wash's own range is raised at the top of the screen, INVISIBLE at 65 % of it, and sunken below that — one block that changes which way it steps as the reader scrolls past it. Nothing renders wrong; the material simply is not one. A veil is the same declaration made relative. 6 % black removes 6 % of whatever light is there, which is a constant 0.858 ratio in linear light at both ends of the wash, so the step is the same step everywhere: over the wash's CF-Grau end 197 -12 secondary 5.19:1 primary 11.91:1 over its middle 217 -14 secondary 6.48:1 primary 14.88:1 over its white end 240 -15 secondary 8.03:1 primary 18.43:1 THE DIRECTION HAD TO FLIP AND THAT IS THE ONE REAL CHANGE HERE. The old light-theme steps both climbed toward white (see the [data-theme= "inverse"] note below, which says so). Up is not available on this wash: its far end IS white, so a lighter step has nowhere to go and dies at the bottom of every screen. Down works at both ends. Sunken now means sunken. Worst case is the CF-Grau end at 5.19:1, which clears AA for body text with room; --text-muted still must not sit on it, for the same reason it may not sit on CF-Grau itself. --surface-card is RETIRED. It was grey-050, the same value as --surface-raised, and its only two users were .cf-process and .ex-step on patterns/expertise.html — both of which now draw as contour on the wash, which is what foundations/materials.html already said they did and what mockups/landing-page.jpg measures: the card's interior and the page margin beside it read within 0.2 of each other at every row of the plate. Do not reintroduce it; a panel that needs a surface takes the veil, and a panel that needs a boundary takes a contour. */ --surface-sunken: rgba(0, 0, 0, 0.06); /* --surface-lifted is RETIRED, and it lasted exactly one consumer. It was rgba(255, 255, 255, 0.26): the step toward the light, for a panel with another column beside it to be a plate against. The process card's copy half was that panel and was the only one in the system. mockups/landing-page.jpg draws that half as an opaque light plate, +22 to +29 over the page margin beside it, and this token was the honest form of it — a veil rather than the flat #F8F8F8, because a flat grey inside the wash's own range inverts as the reader scrolls and a veil cannot. What the source drew and what the card wanted turned out to be two questions: on the rendered card the plate divides the two halves a second time and more loudly than the hairline that is there to divide them. Both halves are the wash now, and this has nobody left. See .cf-process__panel in components.css and foundations/materials.html#copy-panel-gap. THE DERIVATION IS KEPT, because it is the arithmetic and not the decision, and whoever wants a light veil next should not have to redo it: 6 % black at the wash's opening stop #CFCFD2 removes 0.06 x 207 = 12.42; a white veil has 255 - 207 = 48 to work with there; 12.42 / 48 = 0.2588, and 0.26 takes the same size step in the other direction, within 0.06 of one 8-bit level of the sink it mirrors. Sink and lift were one move with a sign. The measurement that unblocked it stands too — .cf-process sits in a sticky stage and holds viewport rows 54 to 785 identically across the whole pin range, so the objection that a light step "dies at the bottom of every screen" was silent about this one panel. Both were true. Neither was the question the card was actually asking. So the paragraph above --surface-sunken is unqualified again: up is not available on this wash, its far end IS white, and a lighter step has nowhere to go. Do not reintroduce this; a panel that needs a surface takes the sunken veil, and a panel that needs a boundary takes a contour. */ --surface-raised: var(--grey-050); --surface-inverse: var(--cf-schwarz); /* Milchglas has three jobs, so it has three tints. See section 9. */ --surface-glass: rgba(255, 255, 255, 0.46); --surface-glass-thin: rgba(255, 255, 255, 0.30); --surface-glass-veil: rgba(255, 255, 255, 0.04); --surface-glass-solid: var(--grey-100); /* THE PAGE ITSELF IS A SLOW VERTICAL WASH FROM CF-GRAU TO WHITE, and it is the largest gradient in the system by two orders of magnitude — roughly 5,800 px on the original. It used to be the only one with no hue in it at all: two neutral stops, zero chroma, a member of no family. It is the foil, reversed, at the amplitude of atmosphere. The page descends from shadow into light — CF-Grau at the top, Weiss at the bottom — so it runs the foil's own ramp backwards: Violett, Sky, Glas, Weiss. STOP POSITIONS ARE --foil-stops' OWN, SUBTRACTED FROM 100 %, which is what "reversed" means arithmetically and why nothing here is picked by hand. Weiss lands at 100 % by construction, so the bottom of the page is the same #FFFFFF it has always been. THE LIGHTNESS PATH IS UNCHANGED, exactly and by construction. Each chromatic stop is the neutral wash's own OKLab L at that position — 0.8545 + t(1 − 0.8545) — so the interpolated lightness of the four-stop ramp is identical to the two-stop one it replaces. Only the hue moves. That is the brand's own definition of iridescence taken to its limit: hue travel inside a narrow luminance band, with the band held at zero width relative to the ramp that was already there. stop position L C h renders Violett 0.00 % 0.8545 0.005 283.86° #CFCFD2 Sky 43.90 % 0.9184 0.005 243.65° #E1E4E7 Glas 82.93 % 0.9752 0.005 179.38° #F3F8F7 Weiss 100.00 % 1.0000 0 — #FFFFFF The three hues are --foil-stops' three, to the digit. Hue travel across them is 104.5°, which is the lit foil's own figure (see 3c); the band they span is 0.120, against the foil's 0.090 and the ink foil's 0.115. By the family's own defining metric this is a family member. CHROMA 0.005 IS THE WHOLE BUDGET, and the ceiling is set by something already on this surface: no channel may move further from the neutral than the grain does. Worst channel deviation over the whole ramp is 4 of 255, inside the ~5 levels of grain the wash already carries. Black text measures 13.51:1 at the top against 13.48:1 before, --text-secondary 5.88:1 against 5.87:1 — both marginally better, because a stop nudged off the achromatic axis at fixed L loses no luminance. IT IS ALSO WHAT FIXES THE BANDING, and that is the part worth keeping. A NEUTRAL RAMP IS QUANTIZATION-BOUND: #CFCFCF to #FFFFFF is 49 greys and there is no fiftieth, because R, G and B are locked together and cross every 8-bit boundary at the same place. Put chroma on it and they cross at different places, so the ramp has more rungs to stand on. Measured off rendered pixels in Chromium — 4,000 px tall, oklab interpolation, Skia's own gradient dither left on, which is what actually paints rather than what the arithmetic predicts: neutral iridescent distinct colours down the ramp 51 130 widest flat run 40 px 36 px transitions moving all 3 channels 99.8 % 23.6 % Two and a half times the levels, and three quarters of the steps are now one or two channels moving instead of three — a partial contour rather than a full one. The neutral ramp's 51 is not a shortcoming of the renderer; it is the ceiling, 49 greys plus dither noise. --grain still rides on top: this is the layer under it. THE THREE HEXES ARE RE-DERIVABLE, NOT HAND-TUNED — recompute the ramp and you get them back — and they carry the same trap the #DBFC60 waypoint does: they are literals, so they do not follow --cf-grau. Move CF-Grau and these must be recomputed or the wash quietly stops starting where the page starts. At this chroma the 8-bit grid is coarser than the target: each hex lands 2.5–4.2° off its hue and within 0.001 of the chroma. That is the grid, not the arithmetic. The two calc()s below reference --spectrum-*-n and --rake-near-n, which are declared in 3b and 3c, further down this file. That resolves fine — custom properties are substituted at computed-value time, not in source order — and it is deliberate: the wash borrows the foil's geometry rather than restating it, so it has to point forwards at where the foil lives. */ --wash-stops: #CFCFD2 0%, #E1E4E7 calc(100% - (var(--spectrum-cool-n) - var(--spectrum-hot-n)) / var(--spectrum-span-n) * 100%), #F3F8F7 calc(100% - (var(--rake-near-n) - var(--spectrum-hot-n)) / var(--spectrum-span-n) * 100%), var(--grey-000) 100%; --surface-page-wash: linear-gradient(180deg, var(--wash-stops)); --text-primary: var(--cf-schwarz); --text-secondary: var(--grey-700); --text-muted: var(--grey-400); --text-inverse: var(--grey-000); --text-inverse-dim: rgba(255, 255, 255, 0.62); --border-strong: var(--cf-schwarz); --border-default: rgba(0, 0, 0, 0.24); --border-subtle: rgba(0, 0, 0, 0.12); --border-inverse: rgba(255, 255, 255, 0.18); --accent: var(--cf-lime); --accent-ink: var(--cf-schwarz); /* text on lime */ --focus-ring: var(--cf-schwarz); /* The one colour outside the brand palette, and the only one. A form error needs a signal nobody can misread and lime does not do that job — see components/forms.html. Declared once here rather than hard-coded per component, the same way --surface-inverse is. #A72019, not the #B3261E it was: the field error is 12 px, so it is body text and owes 4.5:1. #B3261E measures 4.20:1 on CF-Grau — the top of the page wash, where a form on a short page sits — and passed only against the white end. #A72019 is the same hue two steps darker: 4.71:1 on CF-Grau, 7.33:1 on white. */ --feedback-error: #A72019; /* ------------------------------------------------------------------ 3b. THE LIGHT FAMILY — "Licht-Ebene" Every gradient in the system is the same ramp: lime → Glas → CF-Grau. Lime is the light source, CF-Grau is the surface it falls away to, and Glas is the one free parameter — where the two meet. That position is the RAKE: how steeply the light crosses the surface. Near = a bright, short falloff. Far = a long grazing wash. Three rakes are sanctioned, and all three are measured off the designer's material, not invented. Read every stop below as a percentage of the band from the lime end. near 32 % Figma dump, 132.36° linear · 01-discovery.svg (0.32) mid 51 % Figma dump, 239.25° linear · 03-weniger-ausfaelle.svg (0.51) far 64 % Figma dump, 45.72%/95% radial · 04-mehr-leistung.svg The Figma percentages look different from these because Figma states them across the whole fill box, with flat colour either side of the ramp. Renormalise to the band and they land exactly here: (40.45 − 24.97) / (73.05 − 24.97) = 32.2 % (43.85 − 4.82) / (81.19 − 4.82) = 51.1 % One ramp, three rakes. ONE RAMP, FOUR SOURCES, and this file has under-counted them twice. It said one — "Nothing else is a gradient in this brand" — while .cf-plot__col--fell was already drawing Violett → #8A94E3 → Glas → CF-Grau on the evidence plot's two falling columns, on the Landing Page and not only on the component page. It then said two, and named a third as unsanctioned, while .cf-block was shipping three: a categorical figure needs a face per series, so Glas, Sky and Violett each run down to CF-Grau beside the one lit block's lime. That is on components/block.html and argued in components.css under ONE RAMP, FOUR SOURCES. Every number in every one of them is this ramp's: the near rake's own Glas at 0.32, CF-Grau at the rim, and — where the leg needs one — the waypoint at 19 % measured from the source, computed on the oklab path by exactly the method that yields #DBFC60 from lime. NONE OF THEM IS A SECOND LIGHT, and the distinction is the one the lime rule turns on. Lime is the source in this brand and stays the one thing a screen's single lit moment spends; a cool falloff is the same rake with the warm source swapped for a cool one, on a face that is not lit. What they are is further SOURCES of the same falloff — so the rule that governs the lime leg governs them. AND THE COUNT IS NO LONGER A LIST. Saying "a third source is not sanctioned" was an enumeration of what had been drawn when the sentence was written, which is what it went stale as: the fourth arrived on a component page and the sentence stayed. scripts/check-gradient-family.py no longer holds a set of source colours. It measures the leg — one end chromatic enough to be a source, and an sRGB chord that leaves the oklab path by more than the 0.00148 this file already publishes as the divergence it tolerates — and derives the source from that. A fifth source needs no edit anywhere; a leg that owes a waypoint is caught the first time it is drawn, which the list could not do. → foundations/colors.html#sources The argument for the swap is a chart's and lives with the chart: components.css, THE HUE MOVES TO THE FACE, and components/plot.html. → foundations/colors.html#rakes-and-blooms Each rake is declared twice: once as a bare number and once as the percentage built from it. calc() cannot divide a percentage by a percentage, and the foil below renormalises one stop against another, so that arithmetic needs the unitless form. Change the number and both the rake and everything derived from it follow. ------------------------------------------------------------------ */ --rake-near-n: 32; --rake-mid-n: 51; --rake-far-n: 64; --rake-near: calc(var(--rake-near-n) * 1%); --rake-mid: calc(var(--rake-mid-n) * 1%); --rake-far: calc(var(--rake-far-n) * 1%); /* The signature. Angle and stops are the designer's measured values from the Figma dump and are kept verbatim, inset and all. Note that 132.36° is 2.6° off the sanctioned 135° (90° + 45°) — the material wins, but see foundations/geometry.html before deriving new angles from it. */ --gradient-light: linear-gradient(132.36deg, var(--cf-lime) 24.97%, var(--cf-glas) 40.45%, var(--cf-grau) 73.05%); /* The same ramp mirrored onto a horizontal run — buttons, edges, rules. calc() keeps it provably the mirror of --rake-near rather than a second hand-picked number. Sampling the primary button out of the landing-page mockup puts Glas at 63 %; the mirror puts it at 68 %. */ --gradient-light-90: linear-gradient(90deg, var(--cf-grau) 0%, var(--cf-glas) calc(100% - var(--rake-near)), var(--cf-lime) 100%); /* THE OTHER THREE MEMBERS OF THIS FAMILY ARE NOT TOKENS, and their absence here is deliberate. The grazing linear (the dump's second, 239.25°) and the three radial blooms all used to sit at this point in the file, and nothing in the system ever consumed one of them. Each was a further literal statement of the ramp already stated above, restated a second time in the oklab block at the foot of this file — which is the exact condition .material-rake was created to end. They are now .material-rake--grazing and .material-bloom in base.css, composed on a class so the ramp is written once and the rake, the angle and the shape are the parameters they always were. See base.css, and foundations/colors.html for the table that governs the family. A token cannot do this job. calc() substitutes a custom property at computed-value time on the element that DECLARES it, so a bloom written at :root would resolve its rake against :root's and inherit that literal into every modifier — the same reason --field-stops and --foil-image are composed on their classes rather than here. */ /* ------------------------------------------------------------------ 3b-ii. WHERE ARTWORK MEETS THE PAGE Two gradients that carry no colour of their own. Both are the light family doing the two jobs a wash has to do when a full-bleed image is dropped into a page made of CF-Grau: end, and be read over. THE DISSOLVE. The landing-page hero was cut off with a knife. Measured on the rendered page at 1280 x 1400, the last row of artwork is rgb(42,41,55) at the left and rgb(198,237,167) at the middle, and the next row down is the page wash at rgb(233,237,238) — a step of about 190 levels, in three channels at once, across one pixel. The designer's mockup does not do that. It has no edge at all: the artwork decays continuously into CF-Grau and the page simply carries on. Measured off assets/source/mockups/landing-page.jpg as the mean absolute channel deviation from #CFCFCF over each full row — which is what alpha is, when the thing composites onto CF-Grau: y 604 647 701 755 804 a 1.000 0.712 0.386 0.132 0.000 The hero ends at y 804 and the decay is already running at 642, so extrapolating the top of it back to a = 1 puts the band at 598 → 804: the last 25.6 % of an 804 px hero. Fitting a = (1 − t)^k over the band gives k = 1.31, 1.43, 1.46, 1.46 at the four quartiles — call it 1.45, which is a plain ease-out and not a curve anybody would have to justify. The four stops below are that power law sampled at the quartiles of the band; between them the mask interpolates linearly, which departs from the curve by at most 0.018 of alpha. It is a MASK and not an overlay, and that is the whole reason it can be one token. An overlay has to be painted the colour of whatever is behind it, so it would have to know that the hero sits on the page wash and at what point of the ramp. A mask hands the question back to the page: the artwork stops being there, and whatever the page is at that height is what you see. Move the hero, restyle the wash, put this on a dark page — the dissolve still lands. THE READING SCRIM. The hero sets black display type, a black hairline and a 12 px mono line over a loop nobody controls the frames of. Sampled off the rendered page in the text column, the artwork behind the headline reaches rgb(48,55,59) — 1.74:1 against black — and behind the kicker rgb(70,70,81), 2.26:1. The floors are 3:1 for the display line and the rule and 4.5:1 for the kicker, so the hero was failing both, on the page as shipped. The still frame the designer composed does not fail, because in the mockup the left column is pale grey-blue the whole way down and the colour is all on the right. The loop drifts a dark violet plane under the type instead. So the scrim is not a correction applied over the designer's composition — it restores it, and the amount of it is set by what the mockup already looks like rather than by the contrast target. CF-Grau and nothing else. The page's own surface, bleeding up into the artwork exactly where the type sits: the light layer of the material stack, doing the one thing it is for. White would frost it and black would bruise it; both would read as a plate laid on top, which is the failure mode this has to avoid. 63.43° — --angle-a, the steep isometric — so it rises from the bottom-left corner where the text block is and is gone by the top right, where the artwork is at its best and the glass button needs something complicated behind it to be worth being glass. A horizontal ramp would have taken the button's backdrop with it; a vertical one would have greyed the top of the picture for no reader. 0.42 at the corner is a measured floor, not a chosen weight. Sampled on the rendered page with the type hidden, the worst backdrop pixel anywhere inside each element's box — ACROSS ALL 360 FRAMES OF THE LOOP, which is the part that had never been done: 375 768 1280 1440 1920 2560 floor headline 3.28 3.15 3.51 3.41 3.47 3.55 3:1 kicker 6.08 9.64 14.65 15.12 16.41 14.10 4.5:1 THE ROW ABOVE USED TO READ "1.74:1 before, 4.08–6.26:1 after" AND BOTH HALVES OF IT WERE ONE FRAME. It was frame 61 of 360 — the frame that ships as hero-poster.jpg, which is the only one a browser will hand you with the loop paused, and the reason the sample was taken there. This paragraph said so itself, in the sentence that used to follow: "Every number above is one frame of a loop, and the next frame is not obliged to be as kind", and closed by pricing that risk at "about 36 % over its floor". Decoded and measured, all 360 of them, the loop is not as kind and the margin was not 36 %: headline, worst frame of the loop, before the reach was fixed below 375 3.28 768 3.15 1280 3.51 1440 3.41 1920 2.91 2560 1.65 — two failures against a 3:1 floor, and the published figure for 1920 was 6.26 against a true 2.91, wrong by a factor of 2.15. The un-scrimmed artwork is understated by the same single-frame error: the note above records it reaching rgb(48,55,59) behind the headline, and across the loop it reaches rgb(8,8,16) at 768 — 1.05:1, not 1.74:1. Both failures are one geometric fault and neither is about the weight, which is why 0.42 is unchanged and every figure at and below the 1440 frame is byte-identical to what it was. See --scrim-reach. AND THE TABLE IS STILL A REGISTER OF WIDTHS, which is the next thing it was short by. The reach is a horizontal displacement, so widths are all it can depend on; the ARTWORK under the type is not, because .cf-hero__media covers with a square and the box's aspect decides which part of that square lands under the type. Re-sampled at frames instead of widths, the kicker's 6.08 at 375 is a 375 x 896; at 375 x 812 it is 4.03 and at 768 x 800 it is 4.37, both under the 4.5:1 floor. That is the weight and not the reach, and it is what --scrim-depth below answers. The headline is still the binding one and 768 is now the tight width at 3.15, on 5 % rather than 36 %. That is a fact about this artwork at that crop, not about the reach — 768 takes the 39rem plateau whole — so the only lever there is the weight, and much past 0.42 it starts taking the picture instead of the risk. Held by scripts/check-hero-scrim.py, which re-derives the reach from --angle-a and the layout tokens rather than trusting this table: a table measured with a decoder nothing in CI has is exactly the kind that rots quietly. THE "after" COLUMN WAS RE-MEASURED when .cf-hero__body stopped clamping itself to 44ch. That clamp resolved in the wrapper's own 14 px font, so the column had been 342.59 px wide and four display lines tall; it is now as wide as the longest line the display face sets and three lines tall, which is what the markup and the plate both say. Wider and shorter moves the far corner outward along the axis and downward off it at the same time, and on this artwork the second wins: every figure above is equal to or better than the one it replaces. The rule no longer has a row of its own because it is no longer an element — it is the kicker's border-top, so it is measured inside the kicker's box. THE STOPS ARE LENGTHS AND NOT PERCENTAGES, and that is the one thing here that had to be got right rather than merely chosen. A percentage stop is a percentage of the gradient LINE, and the line's length is 0.894·W + 0.447·H — so the same 38 % is 587 px in a 1280 x 896 hero and 402 px in a 768 x 828 one. The scrim has to cover a text column that does not scale with the line: the column is anchored to the left gutter and capped by the type, so it stays about the same size while the line grows by 0.894 of every pixel of viewport. A fixed reach, then. Projecting the column's corners onto the 63.43° axis puts its far corner — the top right of the headline, the point furthest from the light — at 485 px at 375, 693 px at 768, 720 px at 1280 and 943 px at 1920. The plateau does NOT cover all four, and is not asked to: 39rem = 624 px is where the scrim is still at full strength, and past it the falloff is shallow enough that the corner still sits at 0.37 of full alpha at 768 and 0.21 at 1920. It is the contrast column that is binding here, not the projection; the projection only says which corner to go and sample. AND THE PROJECTION IS THE PART THAT GOES WRONG, above the crossover. 943 px at 1920 is not the corner moving because the viewport is wider — it is the corner moving because the COLUMN is, by half of every pixel past --container-max. Carry the same arithmetic one width further and the corner projects past 1248 px, which is 2 × 624: the far end of the falloff, where the scrim is not weak but ZERO. Measured at 2560 with the old fixed reach, the headline read 1.65:1 — the artwork with nothing on it at all. That is what the second term of --scrim-reach answers. Measured with percentage stops in place instead, the headline read 4.46:1 at 1280 but only 3.58:1 at 768 — the same column and the same artwork, failed by a shorter gradient line. min(39rem, 62 %) rather than 39rem flat, because on a phone the line is 623 px end to end and a 624 px plateau would lay a flat 42 % sheet over the entire picture. Below about 1000 px of gradient line the percentage wins and the artwork keeps its top corner. The falloff is the plateau again, doubled — the scrim is out at twice the distance it is full. ------------------------------------------------------------------ */ --dissolve-start: 74.4%; --hero-dissolve: linear-gradient(180deg, #000 0 var(--dissolve-start), rgba(0, 0, 0, 0.659) 80.8%, rgba(0, 0, 0, 0.366) 87.2%, rgba(0, 0, 0, 0.134) 93.6%, transparent 100%); /* THE PLATEAU FOLLOWS THE COLUMN, because above --container-max the column stops being anchored to the gutter and the scrim was still assuming it was. See the note above: "the column is anchored to the left gutter … so it stays about the same size while the line grows". That premise is true up to a viewport of 1438.2 and false above it — at exactly the crossover --column-inset's own note names, three tokens down: "once it has hit --container-max the container stops and centres, so the column moves inward while --gutter stays put … 80 px at the 1440 frame, 240 at 1920, 560 at 2560". The hero's CTA and its pause switch already take --column-inset for that reason. The scrim is the third full-bleed layer that has to line up with the column and the one that did not take it. The second term is that displacement projected onto the axis: the column slides right by (100vw − --container-max) / 2 − --gutter, and sin(63.43°) = 0.8944 of every pixel of that lands on the gradient line. 100vw and not 100 %, because a percentage inside a gradient stop is a percentage of the LINE — the trap the note above is about. It is zero at and below 1438.2, so nothing at or under the 1440 frame moves. */ --scrim-reach: calc(min(39rem, 62%) + 0.8944 * max(0px, (100vw - var(--container-max)) / 2 - var(--gutter))); /* How deep the scrim is across the plateau. A token rather than a literal typed twice, so the narrow value below cannot lift one end of the plateau and leave the other — which would turn the flat run into a ramp with nothing in the diff that says so. See the block after --hero-scrim for why it is viewport-conditional, and for why both values went up four points when the artwork was replaced on 2026-08-03. */ --scrim-depth: 0.46; /* THE TINT IS THE PAGE'S OWN GREY, AND FOR A WHILE IT WAS THE PAGE'S OLD ONE. The rule above is "CF-Grau and nothing else. The page's own surface, bleeding up into the artwork exactly where the type sits" — and it is the second sentence that decides the number, not the first. This layer is not a grey chosen to sit over artwork; it is THE SURFACE THE PAGE ALREADY IS, continued upward under the type. So it has to be whatever the wash is at the height the hero occupies, and it stopped being that. --wash-stops used to open on #CFCFCF. It opens on #CFCFD2 — the Violett-tinged stop the wash acquired when it was given the foil's own ramp reversed, at chroma 0.005, for the reasons set out in full up at the wash. The scrim was not part of that change and kept painting rgb(207, 207, 207): the anchor colour the page had BEFORE the wash moved. Every pixel of the plateau was therefore a flat sheet of a grey the page no longer has anywhere, laid over the artwork at 46 %, at the top of a page whose first painted row is three levels of blue away from it. Nothing caught it, and the two things that could have both had a reason not to. check-gradient-family.py exempts a stop carrying alpha, correctly, because "what such a stop renders as depends on what is behind it". check-hero-scrim.py asks that the scrim be ONE TINT — which it was, and which was the wrong question by itself: one tint is what stops this reading as a plate, and it says nothing about WHICH. That check now asks both, and derives the answer from --wash-stops rather than from a literal of its own, so the next time the page's grey moves this cannot silently fail to follow it again. WHAT MOVED, MEASURED. #CFCFCF to #CFCFD2 is +3 levels of blue and nothing else: OKLab L 0.854514 to 0.855402, a rise of 0.00089, and chroma 0 to 0.0041 — inside the 0.005 ceiling --wash-stops sets and gives the reason for ("no channel may move further from the neutral than the grain does"), and inside the ~5 levels of grain the page already carries. The alpha path is untouched to the digit: both plateau stops still carry --scrim-depth, the third is still zero at twice the reach, so check-hero-scrim.py's geometry is the geometry it was. Re-run after this, all 16 element/frame pairs in check-hero-contrast.py's register hold, and they hold with more room than before rather than less — a hair more of the scrim's own luminance is a hair more separation for the black type on top of it. Those figures cost a decoder and 360 frames per viewport; this does not spend them. MEASURED ON THE RENDERED PAGE, 1280 x 900, this change against the commit before it, so the claim is about pixels and not only about the token: band max delta mean signed R / G / B hero, y 0–300 4 0.00 / 0.00 / +1.25 hero, y 300–620 2 0.00 / 0.00 / +1.22 below the hero, y 700+ 1 0.00 / 0.00 / +1.00 (2.3 % of px) R AND G ARE ZERO TO TWO DECIMALS ACROSS THE WHOLE PAGE. Only blue moves — the token's own +3, laid on at --scrim-depth — and it decays to nothing past twice the reach exactly as the alpha ramp says it should. A mean of 1.2 levels sits under the ~5 levels of grain the page already carries, which is the ceiling --wash-stops sets and the one this had to meet. AND NO FOIL CAN ENTER THIS BOX — worth stating here, because the hero is the obvious place to want one and the answer is measured rather than cautious. check-hero-contrast.py holds the headline to 3:1 and the kicker AND THE RULE THAT IS ITS BORDER-TOP to 4.5:1, against a 12-second loop whose worst backdrops sample at relative luminance 0.108–0.154. Black clears those at 3.15–4.08:1 with little to spare. Every stop of --gradient-foil-ink measured against the same three backdrops: Glas 800 1.22 – 1.59:1 Sky 800 1.66 – 2.16:1 Violett 800 1.99 – 2.58:1 The LIGHTEST stop of the shadow foil is the worst of them, and the best case of the best stop is still under the 3:1 floor for the headline, let alone the 4.5:1 the kicker and its rule owe. The lit half is further out again — it is light-on-dark and this backdrop is neither. So the hero takes its light from the scrim underneath the type, not from the type, and that is a property of the artwork rather than a gap to be closed. */ --hero-scrim: linear-gradient(var(--angle-a), rgba(207, 207, 210, var(--scrim-depth)) 0, rgba(207, 207, 210, var(--scrim-depth)) var(--scrim-reach), rgba(207, 207, 210, 0) calc(var(--scrim-reach) * 2)); /* ------------------------------------------------------------------ 3c. THE FOIL The same light, carried far enough to split. Lime → Weiss → Glas → Sky → Violett is the brand's own spectrum: it is the order of the column on Farben > Dosierung, and it is what the hero artwork does across a single isometric plane — lime at the lit edge, a white hot spot, then cyan, blue and violet in the falloff. Iridescence is hue travel inside a narrow luminance band, not more saturation. Sky and Violett are taken at their 300 tints so the four chromatic stops sit between OKLab L 0.820 and 0.945 — 166° of hue (118° → 284°) across 0.125 of lightness. At their 500 values that band opens to 0.31 and the ramp reads as a fade, not a foil. Weiss is the exception and is meant to be one: at L 1.000 it sits deliberately *above* the band, which is what makes it read as a specular hot spot rather than as one more step in the ramp. Counting it, the full span is 0.180. Both numbers matter — the band is what keeps the ramp iridescent, the hot spot is what makes it catch. ------------------------------------------------------------------ */ /* The spectrum's own stop positions, named so the foil below can be derived from them instead of being hand-picked a second time. Same number-plus-percentage pairing as the rakes, and for the same reason. */ /* THESE TWO ARE THE ONLY POSITIONS IN THE FAMILY WITH NO DERIVATION, and the plate this section cites has now been read rather than merely named. scripts/check-spectrum-plate.py samples the ramp column on assets/source/manual/colour-dosage.jpg — the spectrum drawn as one continuous material, highlight to shadow — and every stop on it is a palette value: --cf-weiss 0.00 % the head, and it is BEFORE lime --cf-lime 21.29 % --cf-glas 44.41 % --cf-sky 64.47 % CORE Sky, not sky-300 --cf-violett 81.16 % CORE Violett, not violett-300 --violett-900 98.93 % the tail. Schwarz is 0.1518 away and never lands TWO DISAGREEMENTS WITH THE PLATE, both deliberate and neither closed here. The plate opens on Weiss and lime is its first COLOURED stop; the hot spot below sits after lime instead, on the authority of the hero artwork rather than of this plate. And renormalised onto the family's own axis (lime = 0, Violett = 100) the plate puts Glas at 38.6 % and Sky at 72.1 %, where the two stops below take --rake-near and --rake-far, measured off the process-card Figma dump. Two of the designer's sources disagree, and moving the ramp onto the plate's figures would move --gradient-spectrum, both foils and the three literals in --wash-stops in one step. That is a brand decision with a page-wide blast radius, not a correction to make in passing. → foundations/colors.html#plate AND 64 IS TWO NUMBERS AT ONCE, which is why it is worth naming rather than quietly binding: it is --rake-far-n exactly, and it is also Sky's position read from the TOP of the plate's column (64.47 %). The family's axis starts at lime, so those are different readings that happen to agree. The Glas stop below is written as var(--rake-near) and this one as its digits; coupling them would assert that the spectrum's cool stop IS the far rake, and the plate is the reason that cannot be assumed. */ --spectrum-hot-n: 18; /* the white hot spot */ --spectrum-cool-n: 64; /* where Sky takes over from Glas */ --spectrum-hot: calc(var(--spectrum-hot-n) * 1%); --spectrum-cool: calc(var(--spectrum-cool-n) * 1%); /* The band the foil renormalises onto: everything above the hot spot. */ --spectrum-span-n: calc(100 - var(--spectrum-hot-n)); /* THE ARC WAYPOINTS. #B9E3EB and #B8CCF3 are not new colours and not picked by eye: each is the OKLCH midpoint of the leg it sits in the middle of, and it is there because a straight line between two chromatic stops is not the path this brand's own definition of iridescence asks for. The full argument, the measurements and the reason the family is not simply switched to `in oklch` are at THE ARC below --foil-stops. Recompute them if either endpoint moves; they are literals, like the #DBFC60 waypoint, and they do not follow the palette on their own. */ --spectrum-stops: var(--cf-lime) 0%, var(--cf-weiss) var(--spectrum-hot), var(--cf-glas) var(--rake-near), /* arc waypoint, Glas -> Sky */ #B9E3EB calc((var(--rake-near-n) + var(--spectrum-cool-n)) / 2 * 1%), var(--sky-300) var(--spectrum-cool), /* arc waypoint, Sky -> Violett */ #B8CCF3 calc((var(--spectrum-cool-n) + 100) / 2 * 1%), var(--violett-300) 100%; --gradient-spectrum: linear-gradient(132.36deg, var(--spectrum-stops)); /* The cool half — the spectrum with lime removed and the remaining band renormalised onto 0–100 %, so it can be used on a screen that has already spent its one lime moment. Nothing here is hand-picked: every stop is the spectrum's own, re-based off the white hot spot. Weiss ( 18 − 18) / 82 = 0 % Glas ( 32 − 18) / 82 = 17 % Sky ( 64 − 18) / 82 = 56 % Violett (100 − 18) / 82 = 100 % That arithmetic is written as calc() rather than pasted in as literals, so moving --rake-near or --spectrum-cool moves this gradient with it. Weiss and Violett are 0 % and 100 % by construction — they are the ends of the band being renormalised, so they cannot be anything else. Keeping the hot spot is the point. The earlier three-stop version started at Glas and read as a flat mint tint; starting at Weiss gives the letterform an edge for the light to land on, and lands much closer to the near-white the designer actually painted this headline (see README, "Decisions that differ from the source material"). 116.57° = 90° + 26.57°, the shallow isometric rake, not the 132.36° of the spectrum. A headline is a wide, short box: at 132.36° the ramp completes inside the first two or three letters. The shallow angle spreads it across the whole line. This is the type foil: on black its worst sample — Violett 300 — is 11.9:1, well past AA at any size. STOPS AND RAKE ARE DECLARED APART, and that split is what lets the foil move. The stop list is the material — which colours, in which order, at which positions — and the rake is the angle light happens to be crossing it at. Written together, the material had to be restated in full every time the angle changed, which is how it came to exist twice already (once here and once in the oklab block at the foot of this file). Written apart, the material exists once and anything that wants a different angle asks for one: see base.css, THE RAKE SWINGS. */ --foil-rake: 116.57deg; /* The two renormalised positions as bare numbers, so the midpoint between them can be arithmetic rather than a third hand-picked figure. Same number-plus-percentage pairing as the rakes and the spectrum's stops, and for the same reason: calc() cannot average two percentages. */ --foil-glas-n: calc((var(--rake-near-n) - var(--spectrum-hot-n)) / var(--spectrum-span-n) * 100); --foil-sky-n: calc((var(--spectrum-cool-n) - var(--spectrum-hot-n)) / var(--spectrum-span-n) * 100); --foil-stops: var(--cf-weiss) 0%, var(--cf-glas) calc(var(--foil-glas-n) * 1%), /* arc waypoint, Glas -> Sky. Recompute if either moves. */ #B9E3EB calc((var(--foil-glas-n) + var(--foil-sky-n)) / 2 * 1%), var(--sky-300) calc(var(--foil-sky-n) * 1%), /* arc waypoint, Sky -> Violett. Recompute if either moves. */ #B8CCF3 calc((var(--foil-sky-n) + 100) / 2 * 1%), var(--violett-300) 100%; --gradient-foil: linear-gradient(var(--foil-rake), var(--foil-stops)); /* ------------------------------------------------------------------ THE ARC The foil's whole claim is HUE TRAVEL INSIDE A NARROW LUMINANCE BAND. Every stop above is a palette value and every stop is right. What was wrong was the path between them. Interpolating in oklab draws a STRAIGHT LINE across the a/b plane. Two stops of similar chroma and different hue sit on roughly the same circle about the neutral axis, so the straight line between them is a CHORD and the middle of it falls INSIDE that circle. Chroma sags where no stop asked it to: leg chord arc midpoint Glas -> Sky 0.0383 0.0452 +17.9 % Sky -> Violett 0.0553 0.0588 + 6.3 % Glas800 -> Sky800 0.0254 0.0289 +13.6 % Sky800 -> Violett800 0.0484 0.0513 + 6.0 % A ramp that loses a sixth of its chroma halfway through its longest leg is greying out exactly where it is supposed to be turning, which reads as a fade with a colour cast at each end rather than as one material seen at an angle. THIS IS NOT AN ARGUMENT FOR MORE SATURATION — the brand's own rule forbids that and this does not do it. Peak chroma on both ramps is unchanged (0.0686 lit, 0.0620 ink); both peaks are still the endpoints' own, and no point on either ramp is more chromatic than the palette value it is travelling between. The sag is removed, nothing is added. THE CORRECT PATH IS POLAR — oklch, shorter hue, which interpolates L, C and h each linearly and therefore holds chroma across the turn. `in oklch` IS NOT USED, and the reason is measured rather than cautious: CHROMIUM DISCARDS THE HUE OF A LOW-CHROMA STOP. Rendered and sampled at 1x, a two-stop `linear-gradient(90deg in oklch shorter hue, #45524F, #283E4F)` — Glas 800 to Sky 800, the ink foil's first leg — comes out with hue pinned flat at Sky's 242.5 for its whole length. Glas 800's own 179.95 never appears, at t = 0 or anywhere else. Sweeping the start stop's chroma in steps of 0.004 at fixed hue puts the threshold between 0.016 and 0.020: at or above ~0.018 the declared hue renders, below it the neighbour's hue is carried forward. Glas 800 is C 0.0171. So the one ramp with the most to gain from a polar path is the one a polar path silently flattens — it would ship 39.7 of its 102.2 degrees of hue travel. Writing the stops as oklch() literals renders correctly and was rejected for a different reason: it takes the three ramps off the palette tokens. SO THE ARC IS PUT INTO THE RAMP INSTEAD, as one waypoint per chromatic leg at that leg's midpoint. This is the system's own idiom one level up: an inline SVG cannot interpolate in oklab, so each lime -> Glas leg there carries #DBFC60 to put the sRGB path back on the oklab one. Same move, same reason, one space further out — a waypoint puts the oklab path back on the polar one. It is exact where it sits and it is engine-independent, which `in oklch` is not. Max deviation from the true polar arc, measured over 2,001 samples: before after lit, chromatic legs 0.00722 0.00212 ink 0.00741 0.00257 EVERY MEASURED FIGURE IN THIS FILE SURVIVES, and by construction rather than by luck. Polar interpolation moves C and h and leaves L alone, so each waypoint's lightness is the mean of its leg's endpoints and sits on the linear L path already there — within 9.2e-4, which is the 8-bit grid rather than the arithmetic. The band depths (0.090 lit, 0.115 ink, 0.180 counting the specular), the hue travel (104.5 / 102.2 degrees) and the endpoints are all untouched. Re-measured over the whole ramp anyway: 11.900:1 on black, 5.239:1 on CF-Grau, 8.162:1 on white — the same three numbers to three decimals. A LEG TURNS WHEN ITS TWO ENDS SIT AT SIMILAR CHROMA, and that is the boundary this stops at. It was written here as two rules — no waypoint on a leg that ends in grey, and no waypoint on a leg carrying lime — and they are one rule counted twice. The premise above is that two stops of similar chroma sit on roughly the same CIRCLE about the neutral axis, so a leg whose ends sit at very different RADII is moving radially, and a radial move has no corner to cut. --gradient-light, --gradient-light-90, the rakes, the blooms and the page wash all run into CF-Grau or out of Weiss, whose chroma is zero: oklab's straight line from the neutral axis to a chromatic stop already is the constant-hue radial, and it is the correct path. The lit foil's own Weiss -> Glas leg is the same case. leg ratio of the two ends' chroma Glas -> Sky 300 1.19 turns Sky 300 -> Violett 300 1.40 turns Sky 800 -> Violett 800 1.53 turns Glas800 -> Sky 800 2.37 turns ------------------------- 2.88 -------------------------- Violett -> Glas 3.50 falls off, bows to #74C1E6 lime -> Glas 5.32 falls off, bows to #A8FFB6 lime -> Weiss inf falls off Glas -> CF-Grau inf falls off 2.88 is the geometric mean of that gap — a ratio's midpoint is geometric — and scripts/check-gradient-family.py measures it rather than reading a list of endpoint names. Naming lime was a proxy that held only while lime was the only source drawn: it would have demanded #74C1E6 the first time a Violett falloff reached CSS, which is a vivid sky blue at twice the chroma of the stop that leg travels to and is in no palette in this brand. Only a leg that turns can cut a corner, and this is what turning means. ------------------------------------------------------------------ */ /* THE SHADOW HALF OF THE FOIL. The foil above is light-on-dark and cannot be anything else: every stop in it is above OKLab L 0.82, so on the page's own CF-Grau it lands between 1.1:1 and 1.5:1. That left the two designed pages — which are a CF-Grau-to-white wash almost end to end — with no gradient type at all, and the only foil moment on either of them down in the black footer. This is the same material seen from the other side: not a second gradient, the other half of the one that already exists. It is built by the same rule the foil is, because iridescence is hue travel inside a NARROW LUMINANCE BAND — so the band moves and the hue travel does not. The ramps are white-mixes and black-mixes of one palette, so the dark mirror falls straight out of them: light foil ink foil Δ stop 1 Glas 500 L 0.910 Glas 800 0.426 h 179.4 / 180.0 stop 2 Sky 300 L 0.865 Sky 800 0.353 h 243.6 / 242.5 stop 3 Violett300 L 0.820 Violett800 0.311 h 283.9 / 282.2 band 0.090 0.115 hue travel 104.5° 102.2° Two decimal places of hue apart across three stops, and a band 0.025 wider. It reads as the same material because it is. NO HOT SPOT, and that is the one place the mirror is not symmetric. The foil's Weiss sits deliberately above its band as a specular. The ink mirror of that would be a stop deliberately BELOW L 0.311, and there is no room for its opposite either: the lightest ink that still clears 4.5:1 on CF-Grau is about L 0.44, which is where Glas 800 already sits. So the ink foil is the falloff without the highlight — which is what the shadow side of a foil actually looks like. Do not "complete" it by adding Schwarz at 0 %: that puts a 0.426 span on a ramp whose whole claim is a 0.115 one, and it reads as a fade to black. DO NOT use the 700 tints instead. They are the obvious choice for a lighter, prettier ink and they fail: Glas 700 is 1.5:1 on CF-Grau. The 800s are the lightest rung of the ramp that clears AA on the page's own grey, which is why the band sits exactly where it does. Stops are the spectrum's own again, renormalised onto the band above the near rake — the foil drops Weiss and rebases off the hot spot, so the ink drops Weiss and the hot spot both and rebases off the rake: Glas ( 32 − 32) / (100 − 32) = 0 % Sky ( 64 − 32) / (100 − 32) = 47 % Violett (100 − 32) / (100 − 32) = 100 % Same 116.57° shallow rake, for the same reason. Worst sample on CF-Grau — Glas 800, the light end — is 5.24:1; on white it is 8.16:1. AA at any size across the whole ramp, and the worst case is the top of the page wash, not the bottom, because this ink darkens as it travels. */ --foil-ink-sky-n: calc((var(--spectrum-cool-n) - var(--rake-near-n)) / (100 - var(--rake-near-n)) * 100); --foil-ink-stops: var(--glas-800) 0%, /* arc waypoint, Glas 800 -> Sky 800. See THE ARC above. */ #33494E calc(var(--foil-ink-sky-n) / 2 * 1%), var(--sky-800) calc(var(--foil-ink-sky-n) * 1%), /* arc waypoint, Sky 800 -> Violett 800. See THE ARC above. */ #273650 calc((var(--foil-ink-sky-n) + 100) / 2 * 1%), var(--violett-800) 100%; --gradient-foil-ink: linear-gradient(var(--foil-rake), var(--foil-ink-stops)); /* Dither. 8-bit sRGB cannot resolve a 5,000 px ramp between two colours this close, so the page wash bands into visible steps. One tile of static, greyscale fractal noise breaks the step edges up. Pure SVG, no request, no build step, `stitchTiles` so the 140 px tile has no seam. IT IS NO LONGER THE ONLY THING WORKING ON THAT PROBLEM. --wash-stops decorrelates the three channels' step positions, taking the wash from 51 rendered levels to 130 and dropping full-strength band edges from 99.8 % of transitions to 23.6 % — see the note on the wash above. That is the ramp itself being given more rungs; this is grain laid over what is left, and the two are not substitutes. Nor is the first trick free to apply anywhere: it costs a hue budget, and the wash could afford one only because it had 104.5° of the foil's own travel going spare. 8 % is measured, not guessed: it puts about five 8-bit levels of grain on the wash — a band edge is one level, so that is plenty — while shifting the mean by 0.9 of a level, i.e. CF-Grau still rounds to #CFCFCF. Louder than this and the brand's anchor colour moves. */ --grain: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='140' height='140'%3E%3Cfilter id='g'%3E%3CfeTurbulence type='fractalNoise' baseFrequency='0.9' numOctaves='2' stitchTiles='stitch'/%3E%3CfeColorMatrix type='saturate' values='0'/%3E%3C/filter%3E%3Crect width='140' height='140' filter='url(%23g)' opacity='0.08'/%3E%3C/svg%3E"); /* ------------------------------------------------------------------ 4. TYPEFACES Publica Sans → the face of the company (logo, display headlines) Geist → the communicator (body copy, section headings) Geist Mono → the analytic one (labels, numbers, data, nav) ------------------------------------------------------------------ */ --font-display: "Publica Sans", "Geist", "Helvetica Neue", Arial, sans-serif; --font-sans: "Geist", "Helvetica Neue", Arial, sans-serif; --font-mono: "Geist Mono", ui-monospace, "SF Mono", Menlo, monospace; --weight-light: 300; --weight-regular: 400; --weight-medium: 500; --weight-semibold: 600; --weight-bold: 700; /* ------------------------------------------------------------------ 5. TYPE SCALE Sizes are the rendered values from the 1440 px Figma frame. Display sizes are fluid so they hold their proportion on small screens. ------------------------------------------------------------------ */ --text-display-1: clamp(2.5rem, 1.4rem + 4.9vw, 4rem); /* 40 → 64 */ --text-display-2: clamp(2rem, 1.3rem + 3.1vw, 2.5rem); /* 32 → 40 */ --text-h1: clamp(1.75rem, 1.3rem + 2vw, 2.5rem); /* 28 → 40 */ --text-h2: clamp(1.375rem, 1.1rem + 1.2vw, 2rem); /* 22 → 32 */ --text-h3: 1.5rem; /* 24 */ --text-h4: 1.25rem; /* 20 */ --text-lg: 1rem; /* 16 */ --text-md: 0.875rem; /* 14 — smallest size allowed for prose */ --text-sm: 0.75rem; /* 12 */ --text-xs: 0.6875rem; /* 11 — mono labels only, never prose */ --leading-tight: 1.02; /* display headlines, set solid */ --leading-snug: 1.15; --leading-normal: 1.3; /* brand default — headings and mono */ --leading-relaxed:1.45; /* body copy */ /* Line length. Prose wants roughly 55–65 characters; a display line wants far fewer, so it breaks where the eye expects rather than where the column happens to end. */ --measure: 56ch; --measure-tight: 26ch; /* Running text is a different problem from a paragraph inside a layout. 56ch is right for a block of copy that sits beside something else; an article is read for minutes at a time, and the readable band there is 45–90 characters (USWDS measure tokens, and the reading research behind them). THE UNIT IS NOT THE TARGET. `ch` is the advance width of the shipped font's "0", and Geist's zero is 0.6875em — 11 px at 16 px, measured as the resolved .cf-prose grid track (66ch computed to 726 px, 726 / 66 = 11 exactly). The average glyph of German running text on these pages is ~0.47em, so every "Nch" here holds about 1.45 × N characters. 66ch was chosen with the fallback font's arithmetic — Helvetica's zero is 0.556em, 66 × 8.9 = 587 px, the figure the prose-track comment in components.css glosses — and Geist drew 726 px from the first day: 90 measured characters per line at a 768 viewport, 100.5 on datenschutz at 1280, both at or past the band's top. 53ch × 11 px = 583 px: the column the design documents, now actually drawn, measured at 77–80 characters of running German — inside the band and level with .cf-value-row__body's capped 56ch. If the body font ever changes, re-measure the zero before trusting any ch figure here; scripts/check-measure-gloss.py holds the copies of this arithmetic together. Only .cf-prose and the excerpt rows use it. */ --measure-prose: 53ch; /* THE TWO MONO TRACKINGS ARE THE TWO RUNGS OF THE LABEL RAMP, and neither is free to pick. --text-xs (11) takes --tracking-label; --text-sm (12) takes --tracking-wide. Two sizes one step apart are told apart by their tracking before they are told apart by their size, so a rule that takes one rung's size and the other's tracking reads as neither — which is what three rules in the tree were doing when this comment was written. scripts/check-label-ramp.py holds the pairing now, the same way it already held the sizes. "e.g. buttons, footer meta" is what this line used to say about --tracking-wide, and .cf-footer__meta has never used it: it is 11 px, so it is on --tracking-label with the other forty-seven. The users are .t-label-lg and the two rules that restate it, .cf-btn and .cf-prose h4. → foundations/typography.html#scale */ --tracking-display: -0.02em; --tracking-normal: 0; --tracking-label: 0.01em; /* Mono/Label as specced in Figma. --text-xs. */ --tracking-wide: 0.08em; /* The 12 px label: .t-label-lg, .cf-btn, .cf-prose h4. --text-sm. */ /* ------------------------------------------------------------------ 6. SPACE — 4 px base unit Every multiple of 4 up to 24, then the doubling run. The step number is the multiple, so --space-6 is always 6 × 4 px. Nothing in between. ------------------------------------------------------------------ */ --space-1: 0.25rem; /* 4 */ --space-2: 0.5rem; /* 8 */ --space-3: 0.75rem; /* 12 */ --space-4: 1rem; /* 16 */ --space-5: 1.25rem; /* 20 */ --space-6: 1.5rem; /* 24 */ --space-8: 2rem; /* 32 */ --space-12: 3rem; /* 48 */ --space-16: 4rem; /* 64 */ --space-20: 5rem; /* 80 */ --space-24: 6rem; /* 96 */ --space-30: 7.5rem; /* 120 — --section-gap's ceiling, reached at the 1440 frame */ --space-40: 10rem; /* 160 — the vacancy register's picture square */ /* Vertical rhythm. Both are one fraction of the frame, clamped to a scale step at each end, so the endpoints land on real device widths rather than somewhere off the edge of the range: --section-gap 100vw / 12 64 at 768 · 120 at 1440 (capped) --section-gap-sm 100vw / 18 32 at 576 · 80 at 1440 (capped) BOTH CEILINGS ARE REACHED AT 1440, AND THE LARGE ONE USED TO RUN ON TO 160 AT 1920. That was the one fluid measure in the system still growing after every other one had stopped: --container-max caps at 1438.2, --section-gap-sm and --section-header-gap at 1440.0, --gutter at 1454.5, and --section-gap arrived 466 px later. From 1454 to 1920 the page was a fixed 1280 column with 80 px gutters whose vertical air kept loosening by a further 40 px — measured as a share of content width, 9.4 % flat from 768 to 1440 and then climbing to 12.5 % at 1920, against a column that no longer grew. Nothing in the designer's material reaches past the 1440 frame, so the 160 was never a measured value; it was where 100vw / 12 happened to land on the next common monitor width. The ceiling is now the frame's own value. --space-30 is 120 by construction — 1440 / 12 — so the rhythm freezes on the same width the column freezes on, and the step that used to be a landmark with no consumer is the ceiling that stops it. Nothing at or below 1440 moves by a pixel. Above it, sections stand 240 apart instead of up to 320. One twelfth of the FRAME is what 100vw / 12 is, and that is why the reference frame resolves it to exactly --space-30 (120). It is NOT one column of the 12-column grid, which this comment used to claim: measured at 1440, a real column is 84.67 (content 1280, less 11 gaps of 24, over 12) and a column pitch — column plus gap — is 108.67. Neither is 120. The unit is the frame divided by the column count, which is a coarser thing than a column because it still carries both 80 px gutters. That is a sound unit and the designer's own frame is the thing it divides; it just is not the grid. See foundations/layout.html, where the claim was load-bearing for a note about what changes above 1438. The 2:3 ratio between them (1/18 : 1/12) holds exactly where BOTH are fluid, and from 768 up it holds everywhere. Measured: 2.00 below 576 where both sit on their floors, sliding 2.00 → 1.50 across 576–768 as -sm leaves its floor first — 1.80 at 640, 1.64 at 704 — then a flat 1.50 from 768 to 1440 and, now that both ceilings are 1440's, a flat 1.50 beyond it: 120 / 80. It used to open back out to 2.00 by 1920 as -sm capped and --section-gap climbed on alone; that was the ceiling drift described above, and it is gone with it. This used to say the slide STARTS at 1.80, which put the ratio below 2.00 at 576 where -sm is still exactly on its floor and the ratio is still exactly 2.00. foundations/layout.html had it right; this comment was the copy that drifted. These are padding on `.section`, applied to both edges — so the air BETWEEN two adjacent sections is twice the token. See foundations/layout.html. */ --section-gap: clamp(var(--space-16), calc(100vw / 12), var(--space-30)); --section-gap-sm: clamp(var(--space-8), calc(100vw / 18), var(--space-20)); /* The air between a section header's hairline and the content it opens. Measured off both mockups: 88 px at the 1440 frame, so 80 px on the scale. A section whose content is a ruled box is the exception — there the box's own top border IS the header rule. See .cf-section-header--flush. THIS IS THE THIRD VERTICAL RHYTHM TOKEN AND IT WAS THE ONLY ONE THAT WAS A CONSTANT. The chapter next door opens "two fluid tokens carry all vertical air between sections", and the table under it — four tokens and the width each stops growing at — had no row for this one, because it never started. 80 px at 320 and 80 px at 2560, while everything it is measured against moves. What that costs is a RATIO, not a number, and the number was only ever right at the frame it was measured on. The air ABOVE a section header is the section's own padding-block-start; the air below it is this. Measured as below ÷ above, every pattern page, before: 320 375 768 900 1024 1280 1440 1920 .section 1.25 1.25 1.25 1.07 0.94 0.75 0.67 0.50 .section--tight 2.50 2.50 1.87 1.60 1.41 1.13 1.00 1.00 A 5x swing across the range on one relationship, and at the left-hand end it is INVERTED: at 375 a header on a --tight section stands 32 px under the thing before it and 80 px above the thing it introduces, so proximity says the header belongs to the section above. Four pattern pages open that way — karriere, news, kontakt, and the confirmation pages behind them. Nothing about a screenshot at 1440 says so; at 1440 the numbers are the designer's and the ratio is 0.67. THE FIX IS THE FRACTION THE SYSTEM ALREADY OWNS. 80 at the 1440 frame is 100vw / 18 — the same fraction --section-gap-sm is built on, and exactly 2/3 of --section-gap's 100vw / 12 wherever both run fluid. So the designed value is not re-derived or traded away: the ceiling IS 80 and the fluid term reaches it at exactly 1440, the frame the mockups were drawn on. The token stops growing where the column does, which is the coordination the chapter's own note asks for and the reason no ceiling above --space-20 was considered. THE FLOOR IS THE PROXIMITY CONSTRAINT, WRITTEN AS A NUMBER. It has to sit under --section-gap's own 64 px floor or the inversion survives at every width where both are floored. 48 is the scale step that does, it is what 100vw / 18 resolves to at 864 — between the two device widths either side of it — and it lands the ratio at 0.75 below 768 and a flat 2/3 from 864 up. After: 320 375 768 900 1024 1280 1440 1920 .section 0.75 0.75 0.75 0.67 0.67 0.67 0.67 0.67 .section--tight 1.50 1.50 1.12 1.00 1.00 1.00 1.00 1.00 The 1920 column read 0.50 while --section-gap's ceiling was --space-40: the air above kept growing to 160 after the air below had capped at 80. Both cap at 1440 now, so the 2/3 holds at every width from 864 up. --tight is still over 1.00 at the phone and that is deliberate: it takes the small rhythm precisely BECAUSE a page header above it has already spent the air, so its 32 is not the whole distance a reader sees and 1.50 there is not the inversion 2.50 was. The plain section — the one both mockups show — is the case that had to stop being upside down, and it is 0.75 or tighter at every width now. Nothing above 1440 moves by a pixel, and neither does the reference frame. → foundations/layout.html#rhythm */ --section-header-gap: clamp(var(--space-12), calc(100vw / 18), var(--space-20)); /* ------------------------------------------------------------------ 7. LAYOUT 1440 frame, 80 px gutters, 1280 content. 12 columns, 24 px gap. The gutter is proportional on purpose: (1440 − 1280) / 2 / 1440 = 5.5556 %, rounded down to the 5.5vw below. Above that the container caps and the outer margin grows instead. Below 364 px the 20 px floor takes over. What lands content on exactly 1280 is --container-max, NOT the gutter. At 1440 the gutter is 79.2, so the gutter alone leaves 1281.6; the cap binds because .container's max-width is calc(1280 + 2 * gutter), and the padding subtracts back to 1280 precisely. The two decouple at the top, which is the tell: 5.5vw does not reach 80 until a viewport of 1454.5, while content reaches 1280 at 1438.2. See foundations/layout.html. THE FLOOR IS CAPPED, AND THAT IS THE ONE THING IN THIS TOKEN THAT IS NOT ABOUT THE 1440 FRAME. A clamp() floor written in rem grows with the reader's text size while the viewport it is spent on does not, and the gutter is the one fluid token in the system that is subtracted from the measure rather than added to it. At a 32 px browser default — 200 % text, which is WCAG 1.4.4 at level AA — 1.25rem is 40 px, so the two gutters took 80 px of a 320 px viewport and left a 240 px content column for type that had just doubled. Measured across all eighteen pattern pages at a 32 px default, 320–480 px: 27 (page, width) pairs scrolled sideways against 0 at a 16 px default. min(1.25rem, 6.25vw) is that floor with a ceiling of its own: 20 px, or a sixteenth of the viewport, whichever is smaller — so the two gutters can never take more than an eighth of the screen. 6.25vw is not a chosen number. It is 20 / 320: the rem floor and the cap meet exactly at 320 px, the reflow width WCAG 1.4.10 measures at, which makes the cap PROVABLY INERT at a 16 px default for every viewport the record documents. Every figure on foundations/mobile.html is unchanged to the last hundredth, and check-fluid-record.py re-derives the crossover and holds the cap to that proof rather than to this paragraph. It does not fix everything it was measured against, and it was not supposed to: the residue at 320 px is the nav bar's own row (325 px of content in a 286 px bar, which no gutter reaches) and a handful of component-level strings. Those are named in the PR that landed this and belong to the lanes that own them. What this token owed was the 40 px it was taking off the column, and that is now the 40 px the column keeps. ------------------------------------------------------------------ */ --container-max: 80rem; /* 1280 */ --gutter: clamp(min(1.25rem, 6.25vw), 5.5vw, 5rem); /* 20 → 80 */ /* THE DISTANCE FROM THE VIEWPORT EDGE TO THE CONTENT COLUMN'S EDGE. --gutter is not that distance, and the difference is the whole point of this token. While the container is still growing the two are equal; once it has hit --container-max the container stops and centres, so the column moves inward while --gutter stays put. Past that crossover an element positioned at --gutter is no longer on the column — it is on the window, and the gap between them opens without limit: 80 px at the 1440 frame, 240 at 1920, 560 at 2560. Anything full-bleed that has to line up with the column takes this instead: the hero's CTA and its pause switch, the values section's counter and progress bar. All four were on --gutter and all four are drawn on the column in the mockups. The Über uns page header takes it for the other reason a full-bleed box needs the column: not to line up with it, but to MEASURE it. The header reserves room below the rule for the object hanging there, and how much room is a fraction of the column's width — which the header cannot read off its own 100 %, because its own 100 % is the window. The object itself needs no inset at all: it stops two columns short of the column edge, so it lives inside .container. → foundations/layout.html#column-inset The crossover is exact rather than approximate, because .container's own max-width is calc(--container-max + 2 * --gutter): at that width the centring margin is exactly --gutter and the two arms of the max() meet. The percentage resolves against the USER's containing block, so this only means what it says on an element whose containing block spans the page. That is the same condition under which --gutter was ever correct here. */ --column-inset: max(var(--gutter), (100% - var(--container-max)) / 2); /* The floating nav's own height: 2 × --space-5 plus the 44 px logo plate. The hero pulls itself up by exactly this so the bar overlays the artwork instead of sitting on a band above it. */ --nav-height: 5.25rem; /* 84 */ --grid-columns: 12; --grid-gap: var(--space-6); /* THE 12-COLUMN TRACK SET ITSELF, written once and read by everything that lays out on it. --grid-columns is the COUNT and --grid-tracks is the track list; the two are the same pair .subdivide already keeps as --subdivide-count and --subdivide-cols, and for the same reason it gives: a track set declared in more than one place is a track set two rules can disagree about. It had already been written three times. base.css's .grid is the primitive; components.css declares the identical repeat() twice more for .cf-values__frame and .cf-values__item, which are the pinned values section's own 12-column frame and the five items stacked in it. Those two are not a component reinventing the grid — they are the one place in the system that genuinely needs the page's column set inside a component, and they could not reach for .grid because they are set inside an @supports block on markup that carries no utility class. So the fix is not to move the markup; it is to give all three one declaration to read. minmax(0, …) rather than a bare 1fr, and that is the load-bearing half of this token. 1fr is minmax(auto, 1fr), and auto floors a track at its content's MIN-CONTENT width — so one long German compound in any cell widens its own track past its share and pushes the page sideways. overflow-wrap: break-word does not save it: the reset sets it on everything, and it does not enter intrinsic track sizing at all. Measured on .cf-progress, the one grid in the system that carried a bare 1fr: a 61-character compound in its label took the document from 320 to 469 px wide at a 320 px viewport, and from 375 to 469 at 375. → foundations/layout.html#intrinsic-minimum */ --grid-tracks: repeat(var(--grid-columns), minmax(0, 1fr)); /* ------------------------------------------------------------------ THE BREAKPOINT REGISTER A threshold cannot be a custom property: var() is not allowed in the prelude of @media or @container, and @custom-media needs a build step this system does not have. So every threshold is a literal, and the only way to keep them from multiplying is to write them all down in one place and add to the list deliberately. The rule: a component asks its CONTAINER. Only page furniture that is genuinely pinned to the viewport — the nav bar, the hero, the footer, the consent banner — may ask the viewport. EVERY THRESHOLD IS IN rem, AND THAT IS THE SECOND RULE. It used to be true of the container thresholds and false of the viewport ones, which were px — so half the register answered to the reader's default font size and half did not. That is not a style preference; it is where the page broke. A media query's rem resolves against the BROWSER's default font size, not against anything an author writes on :root — so a rem threshold is the only kind that tracks the reader's own preference. Every query in this register is a "does this still fit" decision, and what fits depends on how big the type is. A px query answers that question at a text size the reader may not be using. Measured, before the conversion, on the two designed pages with the browser default set to 24 px (150 %, a common low-vision setting and well inside what WCAG 1.4.4 asks for): browser default viewport widths that scrolled sideways 16 px 0 24 px 12 — 320–380, and a band at 792–820 The 792–820 band was the nav: it collapses to a toggle below 780 px, but at a 24 px default the expanded links need 823 px, so between the threshold and the fit there were 43 px of horizontal scroll on every page in the system. 48.75rem is 780 px at a 16 px default — the same number, to the pixel — and 1170 px at a 24 px one, which is where the nav actually needs to fold. The band is gone at every default font size, and nothing moves at 16 px. The 320–380 band was a different fault entirely; see the note on overflow-wrap in base.css. The conversion is arithmetic, not a re-measurement: 780 / 16 = 48.75, 900 / 16 = 56.25, 560 / 16 = 35. Each renders identically at the default. If you ever need to change one of these numbers, change it as a rem figure — reverting one to px silently opts it out of the reader's preference, which is the exact bug this paragraph exists to prevent. CONTAINER thresholds — the width of the component's own container: 21rem / 336 .cf-pie's labels stop riding the ring and become the ruled list under it — the base tier the component already ships for a browser without CSS trig, which is the same figure a box without room needs. The number is the component's own arithmetic and not a taste: 6u of ring plus half a cell and a --pie-label-w cap on each side is 7u + 10rem, which at the --pie-u floor and a 16 px root is 328 px. Eight px of slack over that, on the container it is measured on — cf-pie, the figure itself. SAME SHAPE AS 28rem BELOW AND DELIBERATELY NOT THE SAME NUMBER: reusing it would drop the working 446 px figure the landing page draws at 1024 to the legend to save a row here. → components/pie.html 28rem / 448 .cf-annot stops being a callout and becomes a legend: the notes flow under the figure as a row of marks and words, and the leaders go with the label rules. The threshold is on the FIGURE — cf-annot-fig, its own named container — because what decides whether a callout fits is the width of the drawing, never the viewport. → components/annotation.html 30rem / 480 .cf-breadcrumb keeps only the last two crumbs; whatever is now first drops its divider. Same shape as 34rem below — a row of parts that has stopped being one row — and 3 rem away from it. It is a SEPARATE number because a trail truncates from the head while a route folds in place, and they are measured on different containers; it is registered rather than merged so the adjacency is visible rather than hidden. Also .lp-flow-sources, the flow tier's canopy beads, querying sp-root: below this rung the tightest pair of entries (15 viewBox units) cannot hold a bead and a pixel of air — check-canopy-sources.py re-derives the arithmetic. A second consumer, same argument — and the third gate this layer wore; the two rungs above it each stranded a real reader, see acts.css. 34rem / 544 .cf-error__route folds — the 12 rem label drops above its description and the arrow keeps the right edge. .cf-pagination hides the page numerals and keeps the prev/next pair and the status line. Two consumers, one shape: a row of parts that has stopped being one row. The number is measured — 34rem is the width the routes' two-column form needs, and it is why .cf-error carries no measure cap (see the note there). The same figure is .cf-error__figure's max-width — one number the whole component is built around, so it is a threshold with a reason and not a fifth arbitrary one. (34.625rem / 554 stood here until 2026-09-01: the card width where .cf-process__figure's height cap stops binding, behind which the trace kept a second constant. It was the register's only fractional entry and its own text called it "a question rather than an answer". The answer was that a derived geometric crossover is a min() and not a query: the trace weight is now a ratio of the three lengths the figure already declares, with 100cqw standing for the card, and the crossover falls out of it at every root font size. → components.css, PROCESS CARD) 42rem / 672 .cf-team-grid's cell takes its second column, and with 63rem below it is the ONE PAIR IN THIS REGISTER THAT DECIDES NOTHING — the grid already changes column count here on its own, by auto-fill, and has since it was written. What these two rungs carry is the count as a NUMBER, because the cell's 15 % inset needs one and cqi cannot supply it: gap is 0 in this grid, so auto-fill lays floor(container / --tile) tracks, and 2 x and 3 x the 21rem tile are 42 and 63rem exactly. They are therefore not a second opinion about where the field folds; they are the same arithmetic, and if --tile moves they both move with it. Measured on cf-team, the grid's own content box, and not on the enclosing `layout` — one element out is one border wide, which is a 1 px window at each rung where the two would disagree. Why the inset needs a length at all rather than the percentage it was: Gecko measures this card with its inline size indefinite, every percentage inside it resolves against nothing there, and the two that land in the block axis reached the grid as 364.03 px of dead band per row under the last person. → components.css, over .cf-team-grid__item 44rem / 704 .subdivide folds; the blog axis goes with it, and now goes with it structurally — the axis is a .subdivide__row of the same grid, so both queries measure one element. Reached at a viewport of 792 inside a .container; binary-searched, folded at 791 and open at 792. Also .grid--early, the row that takes its spans here instead of at 56rem — see base.css. A second consumer for an existing number, not a second number. AND IT IS THE NUMBER FOR THREE COLUMNS. A fold width is a property of the column count, not of the primitive: blog-artikel.html runs the grid at three and three columns of 44rem are 234 px each, which reads. Five columns of the same container are 141 px. A five-column subdivision takes .subdivide--late and folds at 56rem below. .cf-logo-wall WAS THE THIRD CONSUMER HERE AND HAS MOVED TO 64rem BELOW. It sat at 44rem behind a one-line width of 617.0 px, and that width was seven MONO WORDS — the wall was still carrying stand-in text. The wordmark files landed and the marks are wider: 988.52 px, measured, which no longer fits above this fold. The row moved with the number rather than the number with the row, because 44rem is already three columns of .subdivide and .grid--early's opt-down and neither of those has anything to do with a logo. WHAT THAT ROW USED TO SAY ABOUT ITSELF IS WORTH KEEPING HERE, because it was right and it is now spent: it called itself "THE REGISTER'S ONE THRESHOLD WHOSE TRIP POINT IS A STRING rather than a box ... no script can hold it, because the width is a rendered word in a font this repository does not ship", and it warned that "minting a threshold two pixels above a string is how a mark gets stranded the day the wordmark files land". The day came. What it bought was that nothing was stranded: the marks arrived, the width went up by 371 px, and the only edit needed was moving the rule to a number the register already had. The successor entry is a box and can be counted. → 72rem, the last row of this list 48rem / 768 .cf-value-row splits into icon + copy. 56rem / 896 the two-column threshold: .col-*, .cf-statement, .cf-process. Inside a .container this is reached at a viewport of about 1007, because a size query measures the CONTENT box and the gutter is 5.5vw. It was measured for the two illustration components; .col-* inherited it, and a row that does not hold an illustration can opt down to 44rem with .grid--early. ALSO .subdivide--late, and the blog axis with it — the fold a FIVE-column subdivision needs, opting UP the same way .grid--early opts down. Measured on the landing page at the pixel after the 44rem fold, a container of 705: .cf-blog-card--compact is one line with an ellipsis, so its cell must hold the headline's first word plus the ellipsis or it labels nothing, and the cell gives C/5 - 1 - 2 x --space-3 of text — 116 px there against the 130 px "Smart-Home-Systeme" needs. Two of the twelve tail headlines rendered as a fragment of one word and an ellipsis; six showed under two whole words; one pixel earlier, folded, all eighteen were complete. The floor solves to a 775 px container, binary-searched to 773. 48rem misses it by 5 px — the wrong side of a window too narrow to build on, since the next real headline can have a longer first word — and this clears it by 121, on the width where .cf-statement and .cf-process already change shape, so the page folds once rather than twice. A second consumer for an existing number, not a second number. 60rem / 960 .cf-article splits into rail + body and the rail goes sticky. Reached at a viewport of about 1079. It is the only container threshold that is not derived from anything — see the note in foundations/layout.html before adding another. THIS ENTRY HAS BEEN RENUMBERED TWICE AND NOW CARRIES NO NUMBER AT ALL. It said FOURTH while 34rem was live with two consumers, then FIFTH while 28rem, 30rem and 34.625rem were live with one each. An ordinal in a register kept by hand is a second thing to remember that says nothing the list above does not, and it went stale both times the list did. The count is whatever scripts/check-breakpoints.py prints. 63rem / 1008 .cf-team-grid's cell takes its third column — the upper half of the pair described at 42rem above, and 3 x the 21rem tile. The grid stops here: the content column is capped at 1280 and four tiles are 1344, which is the same fact the sweep in components.css records as "4 and 5 do not occur at any width". If that cap ever moves, this ladder needs an 84rem rung on the same day. 72rem / 1152 .cf-logo-wall justifies its marks to the measure at or above this width and centres them below it. A NEW NUMBER, which this register does not hand out, so here is the arithmetic that earns it: the seven partner marks at the wall's 2.5rem are 132.70, 86.14, 174.61, 60.72, 150.89, 99.41 and 94.27 px, six --space-12 gaps are 288, and the wall therefore holds one line at 1086.73 px — 67.92rem. A size query measures the CONTENT box and .container's content box IS the wall's width, so 1086.73 is the number the query has to clear. 60rem above is 960 and would strand a mark on a justified last line. 68rem WOULD ALSO CLEAR IT, BY 1.27 px, AND THAT IS THE REASON THIS IS 72. The old 44rem row called minting a threshold two pixels above a measurement the way a mark gets stranded, and the objection is weaker here than it was there — the trip point is a sum of DECLARED BOXES now, not a rendered string, so every browser gives the same figure. Weaker is not gone: those widths are fractional, sub-pixel rounding differs between engines and zoom levels, and 1.27 px is inside that. 72rem clears by 65.27 px and costs the 1086.73-to-1152 band — a viewport of about 1223 to 1294 — centred where it could have been justified, at most 32.6 px an end. Cheap half of an asymmetric error. Binary-searched on the shipped page: one line from a viewport of 1222, and the query engages at 1295 where the container's content box reaches 1152.56. IT WAS 64rem FOR ONE RELEASE and the 98.21 px that moved it are two marks the first pass got wrong: Azure shipped as the glyph ALONE, a bare A 15.19 px wide beside six marks that each say their own name, and Spark shipped at the normalisation rule's own answer, which is the one place that rule under-reads (it assumes upright stems; Spark's wordmark is a script). Naming the brand and matching its neighbours cost 84.22 px and 14.00 px. This is exactly the event the row says to re-measure for — the SET of marks changed — and it is the second time in two releases, which is what a wall of third-party artwork is like. IT SHARES NO NUMERAL WITH ANYTHING IN THE VIEWPORT LIST BELOW, which the 64rem it replaces did. That was a coincidence and it was flagged as one; it is gone now, and nobody has to be told twice that two lists asking two questions may agree on a figure. MOVED HERE FROM 44rem ORIGINALLY, AND THE OLD ROW EXPLAINS WHY. The wall sat there behind a one-line width of 617.0 px, and that width was seven mono WORDS — the marks were stand-in text, and the row said of itself that it was the register's one threshold whose trip point was a string rather than a box, that no script could hold it, and that it would move the day the wordmark files landed. It did. What is different now is that this row can be counted: the marks are SVGs with declared boxes, normalised to a shared optical height before they were committed (assets/img/partner/README.md), so the sum above is the same in every browser and does not move when a font lands or a type scale is edited. Re-measure it when the SET of marks changes — that is the only event left that moves it. → components.css VIEWPORT thresholds — page furniture only: 48.75rem / 780 nav collapses to a toggle; the accordion loses its indent; the footer CTA folds 56.25rem / 900 the page-header figure is dropped; the consent banner goes single column; the hero action drops into the flow, and the hero's reading scrim goes to --scrim-depth 0.54 — the same reflow that moves the action is what puts the artwork's dark band under the kicker. THE HERO ACTION MOVED HERE FROM 48.75rem ABOVE, and the move is the reason to read this row twice. It was folded with the nav because it was written with the nav, and 48.75rem measures the NAV's links — nothing about the hero's own bottom row. The action floats at the column inset over a kicker that is `width: fit-content` on the same band, and between the two numbers the kicker's last words sat under the glass: 70 px of them at a 16 px default, 109 px at a 24 px one, across a band that widens with the reader's type because the kicker is rem and the gutter is vw. A second consumer for an existing number, not a second number — the way 44rem carries .grid--early and 48rem carries .cf-logo-wall. → components.css .cf-hero__action 51.25rem / 820 the Über uns values section takes its pinned, scroll-scrubbed form. Below it the values stack and read straight through. THIS ENTRY IS THE FOURTH TIME THIS REGISTER HAS BEEN CAUGHT SHORT, and the first time the missing threshold was hiding behind a correct statement about a different file: the SCOPE list below has always named 820 as prototypes/werte-scroll.html's, which is true, out of scope, and a different query — so the figure looked accounted for while a live one in components.css was not. Reading "820 is listed" as "820 is registered" is the mistake; the register is a list of QUERIES, not of numbers. 64rem / 1024 the pinned track — .cf-pin, the stage Expertise's fields and the landing page's process both scrub their builds on. Adopted from the landing page, which derived it: the stage is only habitable once the step has its two columns, and that fold is the container 56rem above, reached at a viewport of about 1007. A px gate cannot track a rem fold — the 820px this replaced pinned a stacked step into 100vh of clip and cropped it worst for the reader with the largest type. 95.999rem / 1536 the act rail is paint at rest only above this. The rail's row needs 108 px and the page margin holds it only once --column-inset reaches its 128 px arm, which is 96rem — below that the rail hides at rest (`opacity: 0` off focus) and :focus-within still lifts it, plate and titles and all. Written as 95.999 so the off tier ends where the fit begins instead of both matching at exactly 96rem. Lives in acts.css, the landing page's own sheet — the first registered threshold outside the three shared stylesheets, and the reason the register's scope names the sheet rather than assuming the three. → scripts/check-rail-margin.py holds the arithmetic 45rem / 720 (height) a pinned track's other gate: a stage that must also clear the nav band cannot hold a card worth reading under 45rem of viewport. The card is width/2 high plus its copy — measured on the landing page, adopted by Expertise unchanged. THIS ENTRY WAS "one mechanism, one gate" UNTIL A THIRD CONSUMER SHOWED THE CLAIM WAS OPTIMISTIC: the Über uns values section (51.25rem, above) shares the same pinned/scrubbed construction and had never asked this question, so a phone turned sideways — 932 x 430, 915 x 412, both real device sizes, both engines — cleared the width gate and ran the scroll hijack the height gate exists to stop. Same term, same reasoning, third component. → components.css .cf-values__track 78rem / 1248 with 60rem below, the pair that decides whether act 5's map key stands beside the drawing or under it. They are one decision and are registered as two entries only because a media query cannot state a ratio. Inside the pin gate the map row is what the copy and the key leave of one viewport, and preserveAspectRatio="meet" fits a 1.7943 drawing into it: on a WIDE, SHORT stage that box is far wider than tall, the drawing scales to the short axis and leaves a letterbox down both sides — 203 px each at 1440 x 900 — which is dead ground the key can occupy for free, and the row it gives back becomes scale. Above 60rem of height the drawing is already width-limited, there is no letterbox to move into, and a 14rem column would be taken out of the only axis still binding: measured 1225 stacked against 1024 beside at 1920 x 1080. 78rem is where the stage can afford the column at all — 1024 x 768 clears the height term and fails this one, and the table in acts.css says to leave it stacked. → acts.css, .map-stage 60rem / 960 (height) the other half of 78rem above, and the term that actually names the letterbox: above this much viewport height the map row is deep enough that the drawing is limited by the stage's width instead of by its own, so the dead ground the key was going to stand in does not exist. Written as a MAX and not a min for that reason — it is the only height gate in this register that turns a layout OFF as the screen grows, because what it guards is a shape and not a fit. → acts.css, .map-stage 35rem / 560 (height) the consent banner takes its short-screen form: the ghost rejoins the accept/reject row and the block padding drops a rung. It exists because a tall banner on a short screen hides the page it is asking about. Both remaining declarations are landscape's answer to landscape — a screen with width to spend and no height — and the banner's max-height backstop is no longer one of them; it stands on .cf-consent itself, ungated. → components.css AND THE UNIT DOES NOT DO WHAT THIS ROW SAID IT DID. This entry read "in rem for the same reason as the widths, and it is the case where the unit matters most: enlarged type makes the banner taller while a px threshold holds the screen it is measured against still." The first half is the finding and the second half does not follow from it. rem in a MEDIA QUERY resolves against the root's INITIAL font size and never against the reader's — see check-rem-floor.py, which is written about that exact distinction — so 35rem here is 560 px at a 16 px default, at a 24 px default and at every setting in between. The unit buys consistency with the widths and nothing else, and the one thing this row claimed it bought was the one thing it cannot. Measured at 320 x 812 with a 24 px default, this query not matching: 644 px of banner, 41.6 px of clear band, a 72 px call to action that has no scroll offset at which it can be pressed. THE ROW ABOUT THIS ROW. For as long as this entry existed the block held one declaration — a 70vh cap with an inner scroll — and a cap only does something where the banner is already taller than it. The banner is 253 px at every width from 375 to 900, so across the whole band this threshold governs the cap never engaged: 68 % of a 375 px screen, 32 px left between the nav and the banner, both of them fixed. A threshold that is registered, live and inert is the one kind this register cannot catch, because every copy of it agreed. → components.css The px figure after each slash is what the threshold resolves to at a 16 px default and nothing more — the same convention the container thresholds above use. It is not a second number to keep in sync. Two viewport tiers rather than one is a live question — they govern different objects and neither was measured off the mockups. Flagged for a designer rather than reconciled here. 51.25rem sits between them and 64rem above them, which does not settle the question but does mean any answer now has four widths to reconcile rather than two. There is no fifth viewport width. There was a candidate: .cf-error--page split its two columns at @media (min-width: 62rem), a figure that appeared once in the whole repository and in neither copy of this register. It was not converted to a container query, it was folded onto 56rem — 62rem of viewport is 55.18rem of container, so the two were the same threshold wearing different units. See components.css. This register is only worth having if it is complete, and kept by hand it was never complete for long. It was caught four times. First: 60rem and the height threshold were live in components.css while this list claimed three container thresholds and two viewport ones. Second: 34rem was live with two consumers, and the 62rem above with one, while the corrected list claimed four and three. Third: 51.25rem, hiding behind a true statement about a different file. Fourth: 28rem, 30rem and 34.625rem — three live container queries, one of them added the same day the sweep that found them ran. Every one of those fixes ended with the same instruction to the next person: grep the preludes, and do not trust the previous fix to have been exhaustive. Four times is enough evidence about that instruction. NOTHING RAN — which is the same sentence the space scale, the light family, the isometric assembly, the glass budget and the grid tracks each turned out to be one script short of. scripts/check-breakpoints.py is that script. It reads every prelude in the three shipping stylesheets and holds the three copies of this rule to each other in both directions: a query with no entry is a finding, an entry with no query is a finding, and this comment disagreeing with the table on foundations/layout.html is a finding. It keeps the rem rule above, and it re-derives every px gloss rather than comparing it against itself. So the instruction is shorter now. Add a threshold to a shipping stylesheet and add it here in the same commit; CI says so if you do not. SCOPE: the stylesheets that ship — this file, base.css and components.css, and acts.css, the landing page's own sheet. A page stylesheet is page-local by ownership but its thresholds are folds a reader meets on control-f.de, so they register here with everything else that ships; acts.css spent its first weeks outside every literal gate precisely because this list used to say "three" and mean it. Everything else is out, and "everything else" is three distinct things, so none is safe to leave implicit: docs.css the documentation chrome. Does not ship to control-f.de. Carries one query, @media (max-width: 56.25rem), which collapses the sidebar. Same figure as the 56.25rem above and unrelated to it — do not reconcile them. IT IS STILL OUT OF THIS REGISTER AND IT IS NO LONGER OUT OF THE REM RULE. Those are two rules: this list decides which thresholds are written down, and the rem rule decides whose font size a threshold answers to. The second question is about a reader rather than about who owns a file, and this query was the last px answer to it in front of one. It read 900px on the argument that converting it would make this register look like it governs the chrome; the sidebar track beside it is 17rem, so the two drifted apart as the reader's default rose — 492 px of horizontal scroll at 200 % text, measured, against none at 16 px, where the two spellings are identical. 900 / 16 = 56.25 is this register's own arithmetic. → foundations/layout.html#outside-register inline