, a sticky sub-navigation of that page's own in-page anchors, and a sequence of anchor-separated sections built from the homepage's band vocabulary. Nothing below forks a homepage band; it adds the chrome around them. The smooth scroll these anchors ride on is NOT declared here. `html { scroll-behavior: smooth }` and its prefers-reduced-motion override have been at the top of this file since phase 2, which is where they belong — they are document behaviour, not a component's. -------------------------------------------------------------------------- / / `.sarir-innerhead` and `.sarir-innertitle` are DELETED, not commented out beside their replacement — phase 9e, and the same rule the 7c statement column was removed under: two contradicting instructions in a file is how the next session picks the wrong one. What they were: a full band, 185.59px tall, holding a 64px

. Measured on the reference, every inner page's

is `sr-only` and the visible name at the start of the sticky bar is a different element that is not a heading. The

now carries `.screen-reader-text`, the same class the homepage's has always used, and `.sarir-subnavtitle` below is the visible name. The consequence, measured at 1440: the bar moves from y=257.59 to y=72, directly under the header, which is where the reference puts it. The gap between the bar and the first content band was 0 before and is 0 after — that relationship is untouched. / / ---- The sub-navigation -------------------------------------------------- Sticky, not fixed. Sticky participates in layout, so the content below it does not need a compensating margin that would then have to be kept in sync with the bar's height — the class of bug --scroll-offset exists to prevent. / .sarir-subnav { position: sticky; inset-block-start: var(--header-h); z-index: 9; / under the header, which is 10 / / The token IS the rendered height, not a guess about it. --scroll-offset is built from this value, so if the bar were allowed to size itself to its content, every anchor on the page would land a few pixels off. / block-size: var(--subnav-h); background: var(--color-bg); border-block-end: var(--rule-width) solid var(--color-rule); overflow-x: auto; overflow-y: hidden; / Three brands fit. Fourteen sustainability anchors will not, and the bar must scroll rather than wrap — wrapping would make it two rows tall and silently invalidate --scroll-offset. / overscroll-behavior-inline: contain; / Room for the focus ring when subnav.js scrolls a focused entry into view. The global :focus-visible ring is 2px wide at a 3px offset, so it reaches 5px beyond the link's box; scrollIntoView honours scroll-padding, and 8px keeps the whole ring inside the bar rather than flush against its edge. Phase 9 measured the ring cut off at 400px without this. / scroll-padding-inline: var(--space-2); / Hidden, not absent: the bar still scrolls by touch, trackpad and by tabbing through it. A visible horizontal scrollbar inside a 56px bar eats the height the links need. / scrollbar-width: none; } .sarir-subnav::-webkit-scrollbar { display: none; } / The page's name at the start of the bar — phase 9e. `position: absolute` IS THE MECHANISM, NOT A DETAIL, and this is the one line in this block that must not be changed for tidiness. It earns its place on BOTH axes, and the second reason was found by trying to break the first. HORIZONTAL — the reason the specification gives. The track carries `justify-content: safe center`, and centring distributes the FREE SPACE of the flex container. Move this title INTO `.sarir-subnavinner` and it eats some of that space, so every link shifts off-centre — and it would look almost right, which is the worst kind of wrong. Measured by doing it: the links move by (title + one flex gap) / 2, which is 72.74px on `/group/our-story/` and 98.23px on `/group/vision-approach/`, matching the prediction to 0.01px on all six pages that have a title. VERTICAL — and this one is ours, because our markup is not the reference's. The title is a SIBLING of the track, not a member of it, so simply removing `position: absolute` does NOT move the links sideways at all; the first negative control asserted it would and reported six false failures. What it actually does is make the title a block ABOVE the track inside a bar that is exactly `--subnav-h` tall: measured, the track drops 19.8px (LTR) and 22.19px (RTL) and the bar's contents no longer fit its own height — which would silently invalidate `--scroll-offset`, since that token is built from this bar's height. So a later session tidying this away breaks the layout one way or the other depending on where it moves the element, and criterion 6 now measures both. NOT the reference's own 20px/16px insets. Its bar is a different height, so copying a padding would misalign the title with our links; `inset-block: 0` plus centring derives the position from our bar instead. Same reasoning as --scroll-offset: derive it, never type the number. The type is not a new object. `--fs-xs` is 12px and `--tracking-subtle` is 0.04em — 0.48px at that size — which are the reference's measured 12px and 0.48px exactly, and they are already what a sub-nav link uses. Only the colour differs: the title is full Midnight Black, an inactive link is the 60% token. / .sarir-subnav__title { / HIDDEN BELOW 40rem, and the breakpoint is a measurement — see the media query at the end of this block. / display: none; position: absolute; inset-block: 0; inset-inline-start: 0; align-items: center; / The same gutter the track uses, so the title and a start-aligned first link land on one vertical line rather than two a few pixels apart. / padding-inline-start: var(--gutter); font-size: var(--fs-xs); letter-spacing: var(--tracking-subtle); color: var(--color-text); white-space: nowrap; / It is aria-hidden and it is not a link. Letting it swallow pointer events would make the start of the bar dead to a click that was aimed at the track behind it. / pointer-events: none; } / THE NARROW-WIDTH RULE, CHOSEN FROM A MEASUREMENT — phase 9e §4.1, which is the one thing the reference does not answer. An absolute title over a centred link row collides at narrow widths, and the collision is text on text, not box on box. Measured across eight widths, in all three languages, as the overlap of the title's own text rect with the nearest link's: 400px Our Story 12.48 · Vision & Approach 49.53 · fa 50.11 · ar 24.33 480px 0 · 44.30 · fa 50.11 · ar 0 560px 0 · 6.10 · fa 30.25 · ar 0 640px 0 · 0 · fa 0 · ar 0 Zero from 640px up, in every language and on every page that has a title. So the breakpoint is 40rem because that is where the measurement says the overlap ends, not because it is a round number. TWO REJECTED ALTERNATIVES, both of which the specification offered first: - Reserving the title's width in the track's `padding-inline-start`. The reservation is a NUMBER THAT CANNOT SEE THE TITLE'S LENGTH: 56.5px of text for "Our Story", 107.47px for "Vision & Approach", 94.48px for its Persian. Size it for the longest and the links sit off-centre on the shortest; size it for today and the overlap returns silently the day somebody renames a page. It also shifts the centre the moment the links fit, which is what criterion 6 exists to protect. - Making the title a flex item in the track at narrow widths. No magic number and no overlap — but it puts a non-link, at link size, in a row of links, and the one thing that tells a reader it is not a link is that it sits apart from them. The cost, stated because it is a real loss: BELOW 640px THE PAGE HAS NO VISIBLE NAME. The

is still in the document, so assistive technology is unaffected, and the header's menu still says which section you are in — but a sighted phone reader does not see "Our Story" anywhere on the page. That is the price of the bar staying one row tall, and it is Sarir's to overturn. This is the file's SECOND breakpoint. The note at the top of the stylesheet said "One breakpoint" and has been corrected rather than left to contradict this one. / @media (min-width: 40rem) { .sarir-subnavtitle { display: flex; } } .sarir-subnavinner { display: flex; align-items: center; gap: var(--space-6); block-size: 100%; padding-inline: var(--gutter); / Keeps the last link clear of the edge when the bar is scrolled to its end under both directions. / inline-size: max-content; min-inline-size: 100%; / SAFE centre, and the `safe` is the whole point. When the links fit, the inner is 100% wide — its min-inline-size — there is free space, and they centre. When they do not fit, the inner is max-content, wider than the bar, there is no free space to distribute, and they sit at the leading edge while the bar scrolls. Plain `center` breaks the second case: centred overflow spills equally in BOTH directions, and the first items become unreachable because you cannot scroll into negative space. `safe` falls back to `start` at exactly that point. Three Latin brand names will not overflow at 1440px; fourteen anchors at 400px will, and so might three Persian names. The narrowest viewport sets the constraint, not the widest. / justify-content: safe center; } .sarir-subnavlink { flex-shrink: 0; font-size: var(--fs-xs); letter-spacing: var(--tracking-subtle); / NOT uppercase, unlike every other small label on this site. Measured that way on the reference, and it is right: a table of contents is read, not scanned, and these are proper nouns. / color: var(--color-text-dim); white-space: nowrap; / The border is ALWAYS present and only its colour changes — transparent when inactive, the text colour when active. Giving the border only to the active link would add a pixel to that link's height and nudge the whole row every time the highlight moved. The reference avoids it the same way, with white rather than transparent; transparent is the same trick and survives a change of ground colour. / border-block-end: var(--rule-width) solid transparent; transition: color var(--dur-menu) var(--ease-menu), border-color var(--dur-menu) var(--ease-menu); } / The site-wide 60% rule, third appearance: active is full Midnight Black, everything else is the same 60% alpha as the nav bar and the rail links. See CLAUDE.md — this is a rule, not a component style. / .sarir-subnavlink[aria-current="true"], .sarir-subnavlink:hover, .sarir-subnavlink:focus-visible { color: var(--color-text); border-block-end-color: var(--color-text); } / ---- The anchor ---------------------------------------------------------- / / The one property this whole mechanism turns on. Without it an anchor jump puts the section's first line underneath the header and the sub-nav, and the reader lands on text they cannot see. Logical, not scroll-margin-top: it is the one that stays correct if a page ever scrolls in another direction. The second selector is phase 7c: on a PAGE, a section is an

the editor gave an HTML anchor to, and it carries no class of ours. Rewriting the rendered content to add one would mean rewriting an editor's markup on every request to set a property a selector can reach for free. / .sarir-anchor, .sarir-pagecontent h2[id] { scroll-margin-block-start: var(--scroll-offset); } / THERE IS A LINE BETWEEN BRANDS, and phase 7 recorded that there was not. Phase 7 measured a 33px wrapper and concluded 33px of nothing. Inside that wrapper is an
: 1px, full bleed, with 16px of its own margin. The same error as the statement typography — reading a container and reporting its contents — in a different place on the same day, which is what makes it a pattern rather than a slip. Our page grammar forbids rules between BANDS and that still stands. This line is not between bands, it is between BRANDS: a boundary between two long stories, which is exactly what a hairline is for. The grammar is amended with that distinction rather than the line being treated as a breach of it. NOTE the deleted `.sarir-anchor + .sarir-anchor` rule. Putting a separator element between two anchors breaks adjacent-sibling selectors — the same trap the zero-height anchor marker hit in phase 7 — so the boundary spacing moved onto the separator itself and nothing competes to space the same joint. / .sarir-brandsep { margin-block: var(--band-gap); / flow-root, and it is load-bearing rather than tidy. Without it the
's own 16px margins COLLAPSE THROUGH this wrapper — the wrapper has no padding or border to stop them — and merge with the 160px outside, which wins because collapsed margins take the larger. Measured: the boundary came to 321px instead of 353, and the rule sat hard against the space rather than in the middle of its own 33px. flow-root establishes a block formatting context, which is the one-property way to contain them. / display: flow-root; } .sarir-brandsep hr { margin-block: var(--space-4); border-block-start: var(--rule-width) solid var(--color-text); } / Blocks INSIDE one brand sit at half the distance. The eye reads the tighter spacing as "still the same brand", which is the whole reason for the pair — see --band-gap-tight, which is derived from --band-gap rather than typed. / .sarir-brandpage > .sarir-band + .sarir-band { margin-block-start: var(--band-gap-tight); } / ---- A brand on the brands page ------------------------------------------ / .sarir-brandpagename { font-size: var(--fs-xl); font-weight: var(--fw-light); } .sarir-brandpageline { margin-block-start: var(--space-3); font-size: var(--fs-2xs); letter-spacing: var(--tracking-kicker); color: var(--color-text-muted); } :lang(en) .sarir-brandpageline { text-transform: uppercase; } .sarir-brandpage__body { margin-block-start: var(--space-5); } / ---- The media band ------------------------------------------------------ In the SAME 992px column as the text, not merely contained and not full-bleed. That is what makes a brand read as one object rather than as text interrupted by pictures. The homepage hero is the exception; inside a brand nothing is full-bleed. / / THE RATIO HAS TWO CONSUMERS AND ONE SOURCE — phase 9h. A FIELD slot writes the ratio into its own style attribute (since 9d), and an inline declaration beats any stylesheet, so those slots ask sarir_ratio() in PHP. A BLOCK slot has no inline ratio and is sized here. Both read the same setting; the fallback below is the token file's value and the acceptance run checks the two paths compute the same number. / .sarir-media img, .sarir-media video, .sarir-media .sarir-weave { inline-size: 100%; aspect-ratio: var(--ratio-media, 16 / 9); object-fit: cover; } / THE ONE !important OUTSIDE THE REDUCED-MOTION BLOCK, and it is here because it is overriding an INLINE style rather than another rule. core/video's render callback writes `style="aspect-ratio: W / H"` onto the