/* Box sizing rules */ *, *::before, *::after { box-sizing: border-box; } /* The sitewide focus ring. Declared here and nowhere else: components retune it through the --outline-* custom properties below rather than writing their own `outline`, so there is exactly one place to change it. --form-focus-ring is Codex's focus colour (#177da9). Despite the name it is not form-only -- Codex's own rule applies it to a, button, input, select, textarea and the [role=] equivalents alongside bare :focus-visible. It replaced --clr-primary-20 (light salmon) sitewide on 2026-10-02. Remaining known divergence from Codex: they use a flat `outline-offset: 2px`, where --outline-size here computes max(2px, 0.15em) and so lands slightly wider at most font sizes. Components that care pin --outline-offset: 2px themselves. Left as-is because changing it sitewide is a separate visual decision, not part of the recolour. */ *:focus-visible { --outline-size: max(2px, 0.15em); --outline-color: var(--form-focus-ring); --outline-style: solid; --outline-width: 2px; outline: var(--outline-width, var(--outline-size)) var(--outline-style) var(--outline-color); outline-offset: var(--outline-offset, var(--outline-size)); /* THE RING IS AN OUTLINE ALONE, which is Codex's, as of 2026-10-25. This rule used to pair the outline with `border: 2px solid var(--form-focus-ring)`, a local addition that had been kept deliberately and audited twice; it is gone now. Joy found it from the symptom: "we have two warring focus-visible styles going on... the #quick-search style is what we want, not what we see elsewhere where we have the extra border showing up." She is right about why #quick-search looked correct and nothing else did, and it is worth knowing because it is how the border hid for so long. The border only *shows* on an element that has no border of its own. Every refreshed form control declares one -- #quick-search's own `:focus-visible` set `border: 1px solid var(--form-border-active)` (css-page-requests.css:428, now narrowed to the `border-color` longhand since there is no width left to overwrite) and overwrote it. So the doubled line appeared on exactly the elements nobody had styled a border onto, which made it look like a cascade problem rather than one declaration doing its job. WHAT THE BORDER WAS FOR, because deleting it is not free: an outline paints outside the padding box and is clipped by an `overflow: hidden` ancestor, while a border paints inside and survives. Five controls in this theme have no border of their own AND sit in a clipped context, so this declaration was their only focus cue: (line numbers re-checked 2026-10-26) - the three `summary` elements in `.sidebar-article-dropdown`, which is `overflow: hidden` CUE RESTORED 2026-10-29 They were the worst of the five, because the row bleeds its border box out to the padding box of both its clippers: on a COLLAPSED panel the summary fills the dropdown, so all four sides of the outline were cut off and the row had no visible focus at all. Joy reported it as the three sections "not accessible by keyboard". They carry the inset ring now -- see `.sidebar-article-dropdown > summary`'s `:focus-visible`. - `.nav-tabs .nav-link` NO LONGER APPLIES css-components.css:427 Two separate reasons, and the row is kept rather than deleted because it was wrong in two ways at once. The selector matches nothing -- the tabs template renders `.tab-link`, never `.nav-link` (contract ยง1c) -- so this entry never protected anything. And the real clipped case it should have named, a ring on `.tab-link` inside an `overflow: hidden` `.nav-tabs`, stopped existing on 2026-10-28: the tab restyle took the clipping off the strip, in CSS and in the template's utility class both, because the active tab's bar overhangs the strip by 1px and was being clipped too. `.tab-link` now takes the sitewide outline below with nothing cropping it. - `.zd-copy-btn` in `.zd-code-wrapper` NO LONGER APPLIES Kept rather than deleted, same as the `.nav-link` row above, because what stopped being true is worth recording. The button was flush to `.zd-code-header`'s full height via `align-self: stretch`, inside a wrapper that is `overflow: hidden` -- and it has to be, since that is what clips the code block to its radius. On 2026-10-29 the copy button became an icon-only control positioned 0.75rem in from the wrapper's bottom and right edges; the sitewide ring reaches 4px (2px wide, 2px offset) against 12px of clearance, so nothing crops it. It takes the outline below, pinning only `--outline-offset: 2px`. The wrapper is still `overflow: hidden` -- the geometry moved, not the clipping. - `.related-articles` / `.recent-articles` links CUE RESTORED 2026-10-29 Along with the table of contents' heading rows, which were never on this list because they had a stand-in: all three rail lists recoloured their rail on focus from 2026-10-26. That is gone and all three now draw the same ring -- see `.table-of-contents a`'s `:focus-visible`, which holds the reasoning for all of them. - `.collapsible-sidebar-toggle` (mobile only) STILL OUTSTANDING The last of the five. It is on request_page, not article_page, so it was out of scope for this round; it belongs to the sitewide focus audit in docs/brand-refresh/next-session.md. The first entry used to read "`summary` in `details { overflow: hidden }`", pointing at a bare rule that no longer exists -- the clipping is declared by each component now (css-page-article.css:434 explains why). The share menu's summary is one more clipped case by the same mechanism. It used to be left off this list because `.article-share-label-wrapper:focus-within` already drew it a filled cue that was not an outline, so it never lost anything -- but that cue was deleted on 2026-10-27 when the trigger became a Codex badge (it painted a fill only the summary covered while colouring *every* descendant white, including the open menu's links). It now carries the inset ring described below, at css-page-article.css:1724. THAT PER-CONTROL CUE WAS ADDED ON 2026-10-29 and this paragraph is the record of it being paid off. Joy's call on 2026-10-25 was: take the border out now so the fix is verifiable on the refreshed pages, and add the cue in the article_page round, where those controls get walked and the ones that actually lost their ring can be named. The focus pass is that walk. Four of the five are closed above and the fifth is named as outstanding. The replacement is `inset 0 0 0 var(--border-width-heavy) var(--form-focus-ring)` -- it paints inside the border box, so no ancestor's overflow can reach it, and it shifts nothing. It is still deliberately NOT applied blanket from here. Two reasons, and the second only showed up when the controls were walked: an inset ring cannot be made conditional, so on any control whose outline was only partly clipped it would reproduce the exact doubling this change removed; and it follows `border-radius`, which rules it out wherever the radius is not the shape the ring should be. The rail rows are that case -- their rail is a per-row `border-inline-start` and a radius would scallop it into a dashed line -- so they take the same ring as an absolutely positioned pseudo-element instead. Same shape, drawn by whichever mechanism the control's own geometry allows. EVERY ONE OF THEM ALSO NEEDS `outline: none` ALONGSIDE, which was the one thing the 2026-10-25 plan did not anticipate. A partly clipped outline does not read as a faint ring; it reads as unexplained borders. On the sidebar rows the left and right edges were cut off and the top and bottom survived, so a focused row grew a blue rule above and below it -- which is how Joy found this, reporting the sidebar's borders as needing adjustment rather than reporting a missing focus ring. Pair the two always. */ } /* owns the page's flat background colour, and it is the only element that can. The root's background is propagated to the canvas and painted across the entire window; every other element -- included -- paints only its own box. So a background here covers the window no matter what any descendant does with its width, and a background anywhere else does not. Until 2026-10-19 the root held plain #ffffff while the page was painted on and below at --page-bg-middle (#faffff). Nothing revealed the difference until something made narrower than the window, which the docked Forethought panel did, and then a one-step-off-white seam ran down the right of the page. no longer narrows (css-page-forethought.css:249), but the colour belongs here regardless -- that was only the symptom that found it, and two non-home pages had the same mismatch standing all along, since the header band is --page-bg-middle and the page behind it was white. Two things this rule depends on: `min-height`, not `height`. The 100vh it replaces was arbitrary -- nothing resolves a percentage height against -- and it capped the root's *background positioning area* at one viewport however long the document got. Nothing is measured against that box, because this rule's only layer is a flat colour and the corner glows that are measured against something are painted on
instead, in the rule directly below -- which is also where the reason not to put them here is written down. But a root box that stops short of its own content is the wrong default to leave for whatever lands here next. must stay transparent, below. A background-color there re-covers the canvas inside body's own box, which is the same bug one layer up. */ html { min-height: 100vh; background-color: var(--page-bg-middle); /* Not cosmetic, and the one colour decision a token cannot carry: color-scheme is what decides scrollbar, form-control and autofill rendering. A dark page with `color-scheme: light` gets a light scrollbar track down its edge and Chrome's pale-yellow autofill fill in its inputs, and no amount of custom property wins that -- those are UA-rendered. So it moves with [data-theme] rather than with the token tier. Unpinned 2026-10-20, when that tier landed; the rule it is paired with is at the end of css-brand-tokens.css. */ color-scheme: light; /* No `color` here on purpose. The document's ink is set on , in style.css, along with the font-family and line-height that go with it -- and it has to be, because a declaration on beats anything passes down by inheritance, so a value here would never have reached the page. */ /* Paints the UA's own checkbox, radio and range fills. Was the legacy `--clr-primary-100` (#ef4623); --brand-border is #ef4523, one hex digit away, so this hands the colour to the token tier without a visible change. It has no dark override and falls back to its light value, which is correct for a saturated brand fill -- the same situation as --high-icon. */ accent-color: var(--brand-border); /* Prevent font size inflation */ -moz-text-size-adjust: none; -webkit-text-size-adjust: none; text-size-adjust: none; } /* THE PAGE'S CORNER GLOWS, SITEWIDE. Codex draws the page background as a flat --page-bg-middle with a soft --page-bg-corner glow in the top-left and the bottom-right. The flat base is on above; these are the two glows. GLOBAL BY REQUEST. Joy, 2026-10-25: "I think it's missing on categories, section, requests_page, request_page, new_request_page, and article... So this is something that should be placed as a global setting, rather than page by page." Before this, exactly two pages had a wash and each carried its own copy of these two gradients -- the home page and the search results page -- and every other template was the flat base alone, which is what she was seeing. Both copies came out in the same commit so nothing double-paints. GLOBAL IS WIDER THAN HER LIST, which is the one judgement call here. She named six pages; `main` also reaches the three custom product pages and every template added from here on. That is the point of a global setting, but those pages have not been previewed with a wash behind them, so if any of them wants to opt out it joins the error page in the `:not()`.
IS THE BOX, and the choice of box is the whole decision here, because these glows are sized as a percentage of their positioning area: the element they are painted on decides how big they are, not just where they sit. - NOT . Both alternatives were tried on the home page on 2026-10-19 and rejected; css-page-home.css records why at length. The short version is that the root's background box is either the whole document, which scales the glows with page length and hides the lower one behind the opaque footer, or the viewport with background-attachment: fixed, which concentrates the upper one enough to tint the header band. - NOT #page-container, which was the obvious candidate and was wrong on two of the six pages Joy named: new_request_page.hbs and article_page.hbs gave it `wrapper` with data-wrapper='article', capping it at 80vw, so a wash painted there would have stopped short of both window edges with a visible hard seam. BOTH PAGES CAME OFF THAT PAIR SINCE (2026-10-25 and 2026-10-26), and `.wrapper` is deleted, so that specific objection is now historical -- but the conclusion does not change. #page-container is still the wrong box because it excludes its own `margin-block-end: 5rem` (style.css:231), which is the margin-to-padding swap the paragraph below explains
avoids.
is full width on every template. -
is also, on desktop, the SAME BOX the two existing copies were measured against, which is what makes replacing them a no-op rather than a retune. `.home-page` is a
wrapping the hero and #page-container (home_page.hbs), `.search-page-wrapper` is #page-container itself with its bottom margin restated as padding -- and in both cases the only thing
adds is .back-to-top-wrapper, which is position: absolute above 45em and contributes no height. Below 45em it is in flow but pulls itself up into #page-container's 5rem with a negative top margin (css-components.css, Back to Top), so it adds close to nothing there either.
is Zendesk's own element, not ours -- no template in this theme emits it. css-page-error.css and css-page-custom.css already depend on it for their sticky-footer chains, so this is not a new dependency, but it is one to know about: if Guide ever stops wrapping the template in
, this rule and both of those chains go at once. NO MARGIN-TO-PADDING SWAP IS NEEDED, which is the other thing this buys. style.css gives every #page-container `margin-block-end: 5rem`, and margin is outside the background box -- so the search results page had to zero that and restate it as padding to stop the wash ending 80px above the footer. Painted on
, that margin is *inside* the box and the wash covers it. That page's swap is left in place because it is harmless and its own comment explains it; it is just no longer load-bearing. THE ERROR PAGE IS EXCLUDED and keeps its own treatment: a linear --neutral-bg-soft wash on the `.error-page` band, built to its own Figma frame and signed off on 2026-10-21. Corner glows underneath would show through at the bottom of it. Longhands rather than the `background` shorthand: the shorthand resets background-color, which would make this rule restate the flat base that already owns. And --page-bg-corner-transparent rather than the `transparent` keyword for the second stop -- fading to `transparent` is fading to rgba(0,0,0,0), so the ramp dips through grey on the way out, where the token is the same colour at zero alpha. Both tiers of all three tokens are defined, so dark mode needs no rule here. */ html:not(.error-page) main { background-image: radial-gradient( 52.44% 56.77% at 100% 100%, var(--page-bg-corner) 0%, var(--page-bg-corner-transparent) 100% ), radial-gradient( 52.44% 56.76% at 0% 0%, var(--page-bg-corner) 0%, var(--page-bg-corner-transparent) 100% ); } /* Set core body defaults */ body { min-height: 100vh; line-height: 1.5; /* No background-color -- see the html rule above. */ padding-bottom: 3rem; font-size-adjust: from-font; } /* Remove default margin in favour of better control in authored CSS */ body, h1, h2, h3, h4, p, figure, blockquote, dl, dd, ol, ul { margin: 0; padding: 0; } /* Remove list styles on ul, ol elements with a list role, which suggests default styling will be removed */ ul, ol { list-style: none; } /* Set shorter line heights on headings and interactive elements */ h1, h2, h3, h4, button, label { line-height: 1.3; } input { line-height: 1.5; /* Every input that renders visible text already gets --neutral-text from a more specific rule -- the Garden fields in css-components.css, `.header-search.expand input`, `.kb-search-field input` -- so this is the floor rather than the ink anything is actually drawn with. It was the legacy `--clr-neutral-160` (#333333), which has no dark tier: any input that ever escaped those rules would have drawn #333333 on --form-bg #172029, or 1.30:1. On --neutral-text that floor is 17.89:1 light and 14.35:1 dark. Disarming a trap, not fixing a live defect. */ color: var(--neutral-text); } input::placeholder { text-align: start; } a[role='button'] { cursor: pointer; } /* [dir='rtl'] input { margin-inline-end: 1.25rem; } */ [dir='rtl'] input { text-align: end; } [dir='rtl'] input::placeholder { text-align: end; } /* Balance text wrapping on headings */ h1, h2, h3, h4 { text-wrap: pretty; font-weight: var(--font-bold); } p, ul, ol, li { line-height: 1.5; text-wrap: pretty; word-break: break-word; } h4 { font-size: var(--step-2); } /* Button Default */ button { display: inline-flex; background-color: transparent; border: none; align-items: center; gap: 0.25rem; cursor: pointer; } a { /* ONE underline weight now, and it is the rest weight. There was a second, --link-underline-hover at 1.5x this, which is how Codex's Hyperlink carries its hover state; it was removed on 2026-10-25 when Joy replaced that mechanism with a colour change. See the hover note on `a:not([class])` below -- the measurement that produced the 1.5x is kept there, because the value was right and it was the DESIGN that got overruled, not the reading. Still a custom property rather than an inline value, for the same reason it was one before: it is the handle anything needing to pin a link back to the default weight reaches for, and the breadcrumb trail needed exactly that for three days. Thickness is relatively sized; the offset is flat on purpose. Joy's call, 2026-10-22, settled against the breadcrumb trail: a relative offset drifts with font-size, so a link in a heading gets a visibly wider gap than one in body copy. The old 0.15em computed to ~2.1px at --step-0, so this is the same gap where most links live and a tighter one everywhere above it. */ --link-underline: max(0.08em, 1px); text-decoration-thickness: var(--link-underline); text-underline-offset: 2px; align-items: center; } /* A elements that don't have a class get default styles. THIS IS THE SITE'S LINK COLOUR AND IT IS NOW A CODEX ROLE. Joy, 2026-10-24: "we need to change this class to our default link styles, otherwise we're going to keep coming across the purple links everywhere we go". She is right about the reach -- this one rule is what paints every unclassed link in the theme, which is most of them: the request page's attachment names and collaborator links, the comment author's profile-name link, the comment bodies' inline links, every `{{link}}` helper Zendesk renders without a class. The plum it used to be (--clr-secondary-140, #56215d) was turning up on each page as it was converted and being fixed per page, which was the wrong place to fix it. --hyperlink-link is #050709 in the light tier and #ffffff in the dark one, so a link now reads as body text plus an underline, which is Codex's own model: the underline carries the affordance and the colour carries the tier. Codex also defines --hyperlink-link-visited (#755fbe) and this rule deliberately does NOT use it -- see the note in css-brand-tokens.css:494. THE HOVER IS A COLOUR CHANGE TO BRAND, AND THIS IS A DELIBERATE DEVIATION FROM CODEX. Joy, 2026-10-25, after previewing the underline version across the KB: "I've just been going through the KB and previewing how links work, and I think in this instance we need to deviate from Codex. Put simply, the hover states are not distinguishable enough from the standard text. I'm honestly not sure why they made the decision they did. So I'd like to go back on my previous decision and make the default on link hover the same color that we are using for breadcrumbs. So we don't change their current default state, just the hover." So: the rest state is untouched -- --hyperlink-link ink, 1px underline, which is still Codex's -- and the hover is --brand-text, the token the breadcrumb trail was already using. Both tiers exist, which is the whole reason this token and not a hand-picked red. ITS VALUE WAS RAISED ONE STEP ON 2026-10-28 and is now #992008 light / #fdb5a6 dark (vermillion-12 / vermillion-2, from 11 / 3). Codex's own step missed this project's AAA floor on every surface in both tiers -- 5.75:1 and 4.75:1 light, 6.83:1 and 5.13:1 dark -- which went unnoticed while the token was only painting breadcrumbs and was worth fixing before the hover reached every classed link in the theme. The reasoning, the ratios and the one documented AA exception live on the token itself in css-brand-tokens.css; the short version is that it is ONE step because step 13 would render a hovered link darker than the body copy it sits in, which inverts the paragraph below. THIS REVERSES THE 2026-10-24 DECISION ONE DAY LATER, and the previous one is kept below because the reasoning still explains the file. Joy then: "since we're applying these default hyperlink colors throughout, we need to get rid of the background highlight on link hover and look at the codex style guide. [...] So the only link where we'd see the brand colors would be the breadcrumbs. I know this might have been different than what I told you before -- I was operating off of the wrong assumptions." The half of that which SURVIVES is the rest state and the death of the background tint. The half that is gone is "only the breadcrumbs" -- brand is now every link's hover, and the trail is no longer the exception. Do not re-derive the underline hover from the measurement below; it was built, previewed and rejected on look, which no amount of re-measuring reaches. THE UNDERLINE THICKENING IS NOT KEPT ALONGSIDE THE COLOUR. The deviation was asked for because Codex's mechanism is too quiet, and 1.5px is the mechanism that was too quiet -- carrying both would leave the rejected cue in place and make links hover unlike the breadcrumbs they were just told to match. One hover model, sitewide. The measurement is kept because it is correct and expensive to redo. Codex's Hyperlink Documentation frame draws five states in a row -- default, hover, focus, active, visited. Measuring the light emphasis=base row: state ink underline coverage default #050709 0.97px hover #050709 1.53px active #050709 1.60px visited #755fbe (visited, not carried -- see below) The emphasis=soft row gives the same profile at its own ink (#384649): 0.96px rest, 1.50px hover. So in CODEX the state is carried entirely by the WEIGHT OF THE UNDERLINE -- 1.5x at rest-to-hover -- and the ink does not move in either row. That is a faithful reading of the design and it is the thing this theme now does differently, on the preview above. Worth recording how this was nearly got wrong, because the method was the problem and not the pixels. A first pass compared the two cells by counting scanlines that held ink and found one each, concluded "identical", and reported to Joy that Codex specifies no hover at all. A thin line and a heavy one both occupy one scanline at this render scale; they differ in how fully that scanline is FILLED, which a threshold count throws away. Joy: "No, they are slightly different" -- with a screenshot of the two cells side by side, where it is plainly visible. MEASURE COVERAGE, NOT PRESENCE. The two things this rule used to do on hover were wrong under every version of this decision, which is why they have not come back: a --neutral-bg-highlight fill -- which on a wrapping inline link draws a ragged rectangle broken across the line -- and `text-decoration: none`, which stripped the underline on hover. The underline is part of the REST state here and it stays put through the hover; only the ink moves. The `transition` is on `color` to match. THE HOVER IS --brand-text, NOT --hyperlink-link-soft. The soft token (#384649 light, #c8d5e0 dark) was recommended to Joy as the hover once before, on the strength of the bad measurement above, and declining it was right for a second reason that outlives the measurement: `link-soft` is emphasis=soft, a PROP for a quieter link, and it is *lower* contrast than the rest ink -- so as a hover it would have made the link recede, which is the opposite of the problem Joy is reporting. --brand-text moves away from body text in the direction that reads as interactive. inverse=true (--hyperlink-link-inverse, #faffff) is the other prop: a link sitting on a --bg-strong panel. No use in the theme yet. When one turns up it is a class on that link, not a change here. `:active` takes the hover colour. Codex measures active as the same state as hover (1.60px against 1.53px, which is one line), so pressing holding the hover treatment is still its model even though the treatment itself changed. It is listed second so that releasing the mouse inside the link lands back on :hover rather than on rest. Focus needs nothing added. The `--outline-color: var(--form-focus-ring)` at the top of this file is already #177da9 at 2px, which is exactly what Codex's focus panel draws (its own border-width/heavy). The focus row measures thicker than hover here, but that is the ring's own bottom edge falling into the sample window, not a third underline weight. */ a:not([class]) { text-decoration-skip-ink: auto; color: var(--hyperlink-link); cursor: pointer; transition: color var(--motion-duration-control) var(--ease-in-out); &:hover, &:active { color: var(--brand-text); } } /* Make images easier to work with */ img, picture { max-width: 100%; display: block; } /* Inherit fonts for inputs and buttons */ input, button, textarea, select { font-family: inherit; font-size: inherit; } /* Table default styles */ table { table-layout: fixed; border-collapse: collapse; width: 100%; } /*Code elements */ /* --font-regular, NOT --font-medium, as of 2026-10-29, and it is the typeface swap that forces it rather than a preference. --ff-mono became Space Mono in this same commit, and Space Mono is not a variable font: Google Fonts serves 400 and 700 and refuses a request for 500 outright with an HTTP 400. So --font-medium had no face to resolve to and every `code`, `kbd` and `samp` in the theme was being rendered in a browser-SYNTHESIZED 500 -- a faked weight, which on a monospace face thickens the stems without respecting the metrics the columns depend on. Codex's own mono is regular for the same reason; its language badge names `mono-regular-sm`. Under Inconsolata this declaration was legitimate -- that face carried a real 200..900 axis, so 500 was a weight it actually had. This is the kind of declaration a font swap silently invalidates, which is why it moved in the same commit rather than being left to be noticed later. */ :is(code, kbd, samp) { font-family: var(--ff-mono); hyphens: none; tab-size: 2; text-align: left; word-spacing: normal; word-wrap: normal; box-decoration-break: clone; font-weight: var(--font-regular); } td pre, td code { word-break: break-all; font-size: var(--step-0); width: fit-content; } /* `kbd` CAME OFF THIS SELECTOR, AND ITS OWN RULE IS GONE, 2026-10-29. The two together were the pre-refresh keycap: a --clr-neutral-5 fill, a `1px solid var(--clr-neutral-160)` border, a 0.25rem radius and a two-layer rgba box-shadow faking a 3D key -- hardcoded legacy values with no brand token behind any of them, plus `white-space: pre-wrap` and `align-items: flex-start` inherited from the code-block side of the shared selector, neither of which a one-line inline cap wants. Removed rather than commented out because nothing is left to break. The keycap is now `.article-content kbd` in css-page-article.css, built from Codex's KbKbd on brand tokens, and it already won on specificity -- (0,1,1) against this block's (0,0,1) -- so deleting these declarations changes nothing that renders inside an article body. THE ONE THING IT DOES CHANGE: a `kbd` outside .article-content now renders as plain monospace text. No template in this theme emits one, so the only `kbd` elements on the site come from author HTML in article bodies, which the new rule covers. If one ever turns up in a section or category description the fix is to promote that rule here rather than to restore this one. */ pre:has(code) { display: block; white-space: pre-wrap; background-color: var(--clr-neutral-5); border: 1px solid var(--clr-neutral-160); padding: 0.5rem; align-items: flex-start; border-radius: 0.25rem; width: auto; overflow-wrap: break-word; } @supports not (font-size-adjust: from-font) { :is(code, kbd, samp) { font-size: 0.8em; } } /* Make sure textareas without a rows attribute are not tiny */ textarea:not([rows]) { min-height: 10em; } /* Anything that has been anchored to should have extra scroll margin */ :target { scroll-margin-block: 5ex; } @-ms-viewport { width: device-width; } @media (prefers-reduced-motion: no-preference) { html { scroll-behavior: smooth; scroll-padding-top: 2rem; } } /* Dark Mode Setting */ /* @media (prefers-color-scheme: dark) { html { background-color: var(--clr-neutral-160); color: var(--clr-white); border-color: var(--clr-secondary-10); } a { color: var(--clr-white); } } */