/* ========================================================================== 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-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. Nothing else is a gradient in this brand. 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; --hero-scrim: linear-gradient(var(--angle-a), rgba(207, 207, 207, var(--scrim-depth)) 0, rgba(207, 207, 207, var(--scrim-depth)) var(--scrim-reach), rgba(207, 207, 207, 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. */ --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. NO WAYPOINT ON A LEG THAT ENDS IN GREY, and that is the boundary this stops at. --gradient-light, --gradient-light-90, the rakes, the blooms and the page wash all run into CF-Grau or out of Weiss. An achromatic stop has NO HUE, so there is no arc for the chord to be short of: 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 and gets no waypoint for the same reason. Only a leg chromatic at BOTH ends turns, and only a leg that turns can cut a corner. ------------------------------------------------------------------ */ /* 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; --tracking-display: -0.02em; --tracking-normal: 0; --tracking-label: 0.01em; /* Mono/Label as specced in Figma */ --tracking-wide: 0.08em; /* spaced-out mono, e.g. buttons, footer meta */ /* ------------------------------------------------------------------ 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 at the 1440 reference frame */ --space-40: 10rem; /* 160 — --section-gap at 1920, its ceiling */ /* 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 · 160 at 1920 --section-gap-sm 100vw / 18 32 at 576 · 80 at 1440 (capped) 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 — 768 to 1440 — and nowhere else. 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 — a flat 1.50 from 768 to 1440, then opening back out to 2.00 by 1920 as -sm caps and --section-gap climbs on alone. 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. Above ~1438 the "one grid column" rationale stops being literally true: the container caps, so a real column stops growing while 100vw/12 does not. Section rhythm therefore keeps opening on a very wide window even though the content column is frozen at 1280. That is a deliberate-looking choice nobody has actually ruled on — see foundations/layout.html. 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-40)); --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. */ --section-header-gap: 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. ------------------------------------------------------------------ */ --container-max: 80rem; /* 1280 */ --gutter: clamp(1.25rem, 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: 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, the system's one 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 .cf-process__figure's isometric drawing keeps the --trace-weight constant it carried before that property existed. 554 is not a chosen width: it is where the figure's height cap stops being the tighter constraint, so below it the drawing is letterboxed into a box that grows with the card and no fixed multiplier lands the trace on 1 px across the ramp. THE ONLY FRACTIONAL THRESHOLD IN THE SYSTEM, and it sits 10 px from 34rem above — the near-duplicate this register warns about, recorded rather than reconciled. The two never measure the same container, so nothing collides today; whether a derived geometric crossover should be a threshold at all is the illustration lane's question, not this register's. → components/process-card.html 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. 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.5 — 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, the block padding drops a rung, and what is left caps against the nav band and one control rather than against a share of the screen. It exists because a tall banner on a short screen hides the page it is asking about. 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 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: 900px), which collapses the sidebar. It renders at the same width as the 56.25rem above at a 16 px default and is unrelated to it — and it is still px, which is now a visible difference rather than a hidden one. Left as it is deliberately: docs.css is out of scope by the rule at the head of this list, and converting it would make this register look like it governs the documentation chrome. inline