/* ==========================================================================
BRAND.CSS — the two cross-cutting decisions that must win over every
other stylesheet on the site.
--------------------------------------------------------------------------
Author: Sharmila Parthiban. 2 Sep 2026.
THE LAST STYLESHEET IN EVERY LAYOUT. _Layout, _PrototypeLayout and the
standalone Views/Portal/Index.cshtml all include it as their final .
That is load-bearing for PART TWO: the families and the focus indicator are
declared in four other stylesheets already (tokens.css, prototype-final.css,
mdwds.min.css and prototype-tailwind.css), several of them on plain element
selectors, so an override that loads earlier loses on source order alone
with nothing to show it lost.
BUT IT IS NOT THE LAST SHEET IN THE DOCUMENT, and the difference matters.
_Layout ends with @RenderSectionAsync("Styles"), so a page-level stylesheet
is injected AFTER this file. Measured: on / and on /Account/Login the final
sheet is signin-lanes.css, not this one. Anything a page adds through that
section therefore outranks everything below on equal specificity.
That is fine TODAY, and only because the one page sheet doing it was written
to cooperate: signin-lanes.css declares no font-family at all, and its single
focus rule (.lanes .lane__btn:focus-visible) sets box-shadow from
var(--focus-ring, ...) -- i.e. it DEFERS to the token defined here rather
than restating a width, so the thin ring propagates into it. Its literal
fallback is the OLD 6px ring and would reappear if --focus-ring were ever
deleted from this file rather than re-valued.
SO: a page stylesheet added later must not declare a font-family, and must
express focus through var(--focus-ring) / var(--focus-line) instead of its
own widths. A page that hard-codes either one wins silently, on that page
only, which is the hardest kind of inconsistency to notice.
ONLY these two concerns live here. Anything page-specific belongs in that
page's own stylesheet; anything that would need !important to win belongs in
the file that made the declaration.
==========================================================================
PART ONE — THE TYPEFACE: Inter, self-hosted.
==========================================================================
Inter is the prototype's sans-serif, and the type scale in tokens.css and in
prototype-final.css was drawn against its metrics. One family everywhere:
body copy, headings, form labels, buttons and USWDS components, so a table
heading, a section heading and a form label are the same typeface.
SELF-HOSTED, NOT FETCHED FROM GOOGLE FONTS -- and this is the one deliberate
difference from the prototype's own , for two concrete reasons rather
than a preference:
1. The MDE network does not answer to CDN hosts. The prototype's porting
notes say so in its own words. A webfont that 404s falls back silently,
so headings and body copy diverge on exactly the machines the portal is
used on -- and it reads as a styling bug, not a network one.
2. fonts.googleapis.com and fonts.gstatic.com are third-party requests
from a government page. They carry every visitor's IP address and the
REFERRING URL to another company, and on this site a referring URL can
name a permit application.
The rendered result is identical: the same Inter, the same version (v20),
the same two subsets Google would have served. Two files, 130 KB together,
because Inter v20 ships as a VARIABLE font -- one file covers the whole
400-700 range that four static weights would have needed, so this is fewer
bytes than the CDN version as well as fewer hosts.
font-display:swap deliberately. Text is painted immediately in the fallback
and re-painted in Inter when it arrives; the alternative (block) leaves a
blank page on a slow connection. A small reflow beats invisible text.
latin-ext is loaded as well as latin because Maryland licence holders and
property owners have names in it -- an applicant called Nuñez or Krzyżewski
would otherwise render in a second font mid-word.
MONOSPACE IS FUNCTIONAL, NOT DECORATIVE, and it is Tailwind's system stack
(no webfont, nothing to fail). Registration numbers, group numbers, permit
numbers, licence numbers and well tags are read off paper and compared
character by character, so 0/O and 1/l/I have to be distinguishable. That is
the ONLY exception to one-family, and it is confined to .font-mono / .u-mono
and the code elements.
========================================================================== */
@font-face {
font-family: "Inter";
font-style: normal;
/* A RANGE, not a single value: this is one variable font covering every
weight the site uses, so 400 body, 500, 600 and 700 all resolve to this
file instead of synthesising a fake bold. */
font-weight: 100 900;
font-display: swap;
src: url("../fonts/inter/inter-latin-var.woff2") format("woff2");
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC,
U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215,
U+FEFF, U+FFFD;
}
@font-face {
font-family: "Inter";
font-style: normal;
font-weight: 100 900;
font-display: swap;
src: url("../fonts/inter/inter-latin-ext-var.woff2") format("woff2");
unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304,
U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0,
U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* THE TOKENS FIRST. tokens.css declares both of these on :root and this file
loads later, so these two lines are what every var(--font-sans) reference
already in the codebase resolves to -- including home-landing.css, which
uses nothing else. Behind Inter come the webfont fallbacks (Public Sans, then
Source Sans Pro), unchanged: if the woff2 ever fails to load the page renders
in Public Sans exactly as it did before rather than in Times. The tail after
them is the project's canonical system-native stack (set 3 Sep 2026) -- the
platform's own UI font, for the machine that has neither Inter nor the
fallback webfonts. Inter stays PRIMARY; only the system tail was replaced.
Monospace keeps ui-monospace primary (the OS's own fixed-pitch UI font, no
webfont, nothing to fail) and gains the same canonical native tail. It stays
the functional exception -- 0/O and 1/l/I distinguishable for reading numbers
off paper -- so Monaco / Liberation Mono / Courier New are all fixed-pitch.
--font-serif is NOT redefined and is NOT used. See the .serif rule below. */
:root {
--font-sans: "Inter", "Public Sans", "Source Sans Pro", -apple-system,
BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
--font-mono: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas,
"Liberation Mono", "Courier New", monospace;
}
/* THE ELEMENT RULES, for the pages tokens.css is not loaded on.
_PrototypeLayout and the Portal screen get their type from
prototype-final.css, which sets the family DIRECTLY on these selectors --
not through a custom property -- so redefining --font-sans above does
nothing for them on its own. Every selector below is one prototype-final.css
already writes, matched at equal specificity and winning on source order.
`body h1, body h2, body h3` is the one that matters most: prototype-final.css
scopes its Merriweather rule through `body` on purpose (to outrank Tailwind's
preflight), so a bare `h1` here would lose and headings would stay serif
while everything around them turned to Inter. */
html,
body,
button,
input,
select,
textarea,
optgroup,
h1, h2, h3, h4, h5, h6,
.serif,
.usa-table, .usa-tag, .usa-label, .usa-legend, .usa-input, .usa-select,
.usa-textarea, .usa-button, .usa-hint, .usa-prose {
font-family: var(--font-sans);
}
/* .serif is deliberately included above and is deliberately NOT serif.
The class survives in prototype-final.css and in generated markup, and the
delivered prototype's own final revision reached this same conclusion for
the same reason: the page was running three families at once, two of them
fetched, and off the network Merriweather fell back to Georgia so headings
became serif while body copy stayed sans. Mapping the class to the one
family means old markup carrying it renders correctly rather than
reintroducing a second typeface wherever it appears. */
body h1,
body h2,
body h3 {
font-family: var(--font-sans);
}
/* BODY COPY, ONE STEP DOWN — AND THE TWO LAYOUTS FINALLY AGREE.
tokens.css:146 and site-enhance.css:40 both put _Layout's body at --fs-sm (16px).
_PrototypeLayout never used that number: prototype-final.css:244 sets
--fs-body: 0.875rem, so every Portal and prototype screen has been running 14px
body copy all along. The 16px was the outlier, and it is why the same paragraph
looked like two different applications depending on which layout served it.
So this lands on 14px rather than 15px: it is not a step into new territory, it is
_Layout adopting the size the rest of the application already used. --fs-2xs and
prototype-final's --fs-body are the same 0.875rem, which is why the fallback reads
as it does — the rule is a no-op on the prototype layout and only moves _Layout.
THIS IS THE FLOOR FOR PROSE, and deliberately so. tokens.css:85-88 sets the rule:
13px (--fs-3xs) is the "legal fine print floor" and 12px carries an explicit
"NEVER put a sentence at this size". Body copy therefore stops here; a further
reduction would have to invent a size below the scale's documented minimum for
running text, which is a different decision from choosing a smaller existing step.
Set on `body` and NOT on `html`. Every --fs-* token is rem-based (tokens.css:87-95),
so touching the root would silently rescale every heading, every control and all
the rem-based spacing at once. On `body` it moves inherited text only, and the
headings below keep the explicit sizes the next block gives them — h4 at 16px and
h5 at 15px still outrank 14px body copy, so the hierarchy survives. */
body {
font-size: var(--fs-2xs, var(--fs-body, 0.875rem));
}
/* THE HEADING SCALE, EVERY LEVEL ONE STEP DOWN.
tokens.css:153-157 puts h1 at --fs-2xl (34px), which reads as a poster headline
rather than a page title — the Help & FAQ page ("Help & frequently asked
questions") is where it shows worst. Every level is stepped down one notch on
the SAME existing scale, so no new size is introduced and the gaps between
levels are the ones the scale was designed with:
h1 --fs-2xl 34px -> --fs-xl 28px
h2 --fs-xl 28px -> --fs-lg 22px
h3 --fs-lg 22px -> --fs-md 18px
h4 --fs-md 18px -> --fs-sm 16px
h5 --fs-sm 16px -> --fs-xs 15px
Stepping the whole set rather than h1 alone is what KEEPS THE HIERARCHY: h1
alone would have landed on 28px, exactly h2's size, and a page title would no
longer outrank its own section headings.
h6 IS DELIBERATELY ABSENT. No stylesheet in the solution gives h6 a size — it
is not in tokens.css's per-level list and prototype-final.css has no --fs-h6 —
so there is no declared level to step down FROM, and inventing one would be a
new size rather than a smaller one.
THE FALLBACKS ARE THE WHOLE TRICK, and they are why this is one block and not
two stylesheets. tokens.css is on _Layout only; _PrototypeLayout loads
prototype-final.css instead, which declares sizes for exactly `body h1/h2/h3`
(via --fs-h1/-h2/-h3) and nothing below. Those are ALREADY smaller than the
steps taken here — its h1 is 1.375rem against the 1.75rem above. So each rule
falls back to the value that screen already uses and those pages do not move:
- h1/h2/h3 fall back to prototype-final's own --fs-h1/-h2/-h3.
- h4/h5 fall back to the UA defaults they render at there today (h4 is 1em,
which `inherit` reproduces exactly; h5 is 0.83em).
A literal `1.75rem` on h1 would instead have ENLARGED the Portal and prototype
screens by 6px — the opposite of the instruction.
`body hN` and not `hN`, for the reason given above this block: prototype-final.css
scopes through `body` to outrank Tailwind's preflight, so a bare `h1` would lose
there. Specificity is matched to it (0,0,2), brand.css loads later on both
layouts, so source order alone carries it. No !important. */
body h1 { font-size: var(--fs-xl, var(--fs-h1)); }
body h2 { font-size: var(--fs-lg, var(--fs-h2)); }
body h3 { font-size: var(--fs-md, var(--fs-h3)); }
body h4 { font-size: var(--fs-sm, inherit); }
body h5 { font-size: var(--fs-xs, 0.83em); }
/* The functional exception. .font-mono is the prototype's own utility (and
Tailwind's name for it); .u-mono is tokens.css's. Both are listed so the
same registration number is monospaced whichever layout renders it.
tabular-nums is what actually lines up a column of numbers -- monospace
alone still lets a proportional-figure fallback shift the digits. */
.font-mono,
.u-mono,
code,
kbd,
samp,
pre {
font-family: var(--font-mono);
font-variant-numeric: tabular-nums;
}
/* ==========================================================================
PART TWO — THE FOCUS INDICATOR: a THIN highlighted border.
==========================================================================
What was there: USWDS and both token blocks draw a 4px band around the
focused control -- mdwds.min.css uses `outline:.25rem solid #2491ff` on
.usa-input:focus, and --focus-ring is `0 0 0 2px #fff, 0 0 0 6px #2491ff`,
which is a 2px white gap plus a 4px blue ring. On a field with a 1px border
that reads as the control having grown a thick blue slab: it hides the
control's own edge, and on a dense form it overlaps whatever sits beside it.
What it is now: the control's OWN border turns the highlight colour and is
joined by a 2px ring -- a thin, bright edge that traces the control's shape
instead of covering it.
THIS STAYS WELL INSIDE WCAG 2.4.11 / 2.4.13. The requirement is a contrasting
indicator at least 2px thick around the perimeter, not a thick one: 2px of
#2491ff against white is 3.1:1, above the 3:1 minimum, and the 1px white
separator keeps it visible on the darker controls too.
THREE THINGS THAT ARE DELIBERATE AND EASY TO UNDO BY ACCIDENT:
1. --focus-ring KEEPS its two-layer shape. Everything in the codebase
writes `box-shadow: var(--focus-ring)`, and both token files document
that it is a box-shadow value and not a colour. Only the widths change.
Anything written as `outline: var(--focus-ring)` was always invalid and
silently dropped; that has not changed.
2. :focus-visible, not :focus, wherever the browser supports it -- a mouse
click on a button should not leave a highlight behind it. The .usa-*
rules below match on :focus because that is the selector USWDS wrote and
an override has to match it to win; the visible result is the same
because those are text fields, which get :focus-visible on click anyway.
3. The transparent outline is NOT redundant. Windows High Contrast mode
discards box-shadows entirely, and forced-colors turns a transparent
outline opaque -- so it is the only thing carrying the indicator there.
Removing it removes the focus ring for the people who most need it.
========================================================================== */
:root {
/* 1px white separator + a 2px highlight. Same two layers as before, thinner. */
--focus-ring: 0 0 0 1px #ffffff, 0 0 0 3px #2491ff;
/* The highlight colour on its own, for the border-colour half of the
treatment. Named so a page never hard-codes the hex. */
--focus-line: #2491ff;
}
/* THE CONTROLS. Grouped rather than written per component so a control added
later inherits the treatment instead of keeping the 4px band. */
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
button:focus-visible,
a:focus-visible,
summary:focus-visible,
[tabindex]:focus-visible,
.inp:focus-visible,
.btn:focus-visible {
border-color: var(--focus-line);
box-shadow: var(--focus-ring);
outline: 2px solid transparent;
outline-offset: 0;
}
/* ------------------------------------------------------------------------
THE RULE THAT WAS ACTUALLY WINNING, and the one the group above could not
beat. Measured in the browser, not reasoned about: a focused .inp on the
landing page still computed `outline: 4px solid rgb(36,145,255)` with the
thin box-shadow drawn underneath it, so the control had BOTH indicators.
mdwds.min.css does not only style .usa-input. It also carries
input:not([disabled]):focus,
select:not([disabled]):focus,
textarea:not([disabled]):focus,
button:not([disabled]):focus { outline: .25rem solid #2491ff }
iframe:focus, [href]:focus,
[tabindex]:focus,
[contentEditable=true]:focus { outline: .25rem solid #2491ff }
`input:not([disabled]):focus` is (0,2,1) -- :not() contributes its
argument's specificity, so the attribute selector counts. The group above
is `input:focus-visible` at (0,1,1) and `.inp:focus-visible` at (0,2,0),
and BOTH lose to it however late brand.css loads. Load order never came
into it.
So this block matches mdwds's own selector shapes exactly. Equal
specificity, and brand.css is the last stylesheet on all three layouts, so
it wins on order -- which is the only lever left once the specificities tie.
:focus AND NOT :focus-visible HERE, DELIBERATELY. This block's whole job is
to REMOVE the 4px band, including on a mouse click, where no indicator is
wanted at all. It does not draw anything: the transparent outline is what
carries the ring in Windows High Contrast (see note 3 above), and the
visible thin edge is left entirely to the :focus-visible group, which
re-applies border-color and box-shadow for keyboard focus. A control
clicked with a mouse therefore ends up with no ring, which is what
tokens.css intended before USWDS overrode it.
WHY NOT !important: because the next person to need a wider ring on one
control -- a dark-background button, say -- would have to fight it. Equal
specificity plus load order is beatable by ordinary means.
------------------------------------------------------------------------ */
input:not([disabled]):focus,
select:not([disabled]):focus,
textarea:not([disabled]):focus,
button:not([disabled]):focus,
iframe:focus,
[href]:focus,
[tabindex]:focus,
[contentEditable="true"]:focus {
outline: 2px solid transparent;
outline-offset: 0;
}
/* And the thin edge back on, for keyboard focus only, at a specificity that
clears the block above. Same three declarations as the general group -- the
duplication buys the specificity, and the alternative is one enormous
selector list nobody can read. */
input:not([disabled]):focus-visible,
select:not([disabled]):focus-visible,
textarea:not([disabled]):focus-visible,
button:not([disabled]):focus-visible,
[href]:focus-visible,
[tabindex]:focus-visible,
[contentEditable="true"]:focus-visible {
border-color: var(--focus-line);
box-shadow: var(--focus-ring);
outline: 2px solid transparent;
outline-offset: 0;
}
/* USWDS's own components, matched on the selector USWDS uses. .25rem outlines
on four of these are the thickest thing on any form in the application. */
.usa-input:focus,
.usa-select:focus,
.usa-textarea:focus,
.usa-combo-box__input:focus,
.usa-button:focus,
.usa-checkbox__input:focus + .usa-checkbox__label::before,
.usa-radio__input:focus + .usa-radio__label::before {
border-color: var(--focus-line);
box-shadow: var(--focus-ring);
outline: 2px solid transparent;
outline-offset: 0;
}
/* A CHECKED radio or checkbox inside a card. "Selected" and "focused" are
different states and both want the thin edge: the focused one because that
is where the keyboard is, the checked one because that is the answer the
form is holding. The card carries it, not the 13px control inside it --
which is the same reason prototype-account.css puts the ring on .rolecard. */
.rolecard:has(input:checked),
.lp-form:has(input:checked),
label:has(> input:checked) {
border-color: var(--focus-line);
}
/* Text selection, so a dragged-over permit number is highlighted in the
site's own blue rather than the browser's default. */
::selection {
background: var(--c-primary-lighter, #d9e8f6);
color: var(--c-ink, #1b1b1b);
}
/* ==========================================================================
PART THREE — ONE TYPE SCALE ACROSS BOTH FORM VOCABULARIES.
==========================================================================
The reported fault: the Green form (Well Construction Permit Application)
and the White form (Well Abandonment Report) do not look like the same
application. They are built in two different design systems:
- The Green form uses the PROTOTYPE vocabulary (.fld__lbl, .inp,
.fld__hint, fieldset.fs > legend) styled by prototype-app.css on the
compact token scale: 14px labels, 13px hints.
- The White form uses the USWDS wizard vocabulary (.usa-label,
.usa-input, .usa-hint) on the larger federal scale: ~17px labels/
controls, 16px hints.
The FACE is already identical — brand.css resolves --font-sans to Inter for
both and loads last. What differs is SIZE. This block lifts the prototype
form controls onto the USWDS scale so a field on the Green form is the same
size and weight as the same field on the White form.
WHY HERE AND NOT IN prototype-app.css: that sheet is generated/served
verbatim and must not be edited. brand.css is the last stylesheet on every
layout, so these rules tie on specificity with prototype-app.css's own
(each is a single class, 0,1,0) and win on load order — no !important, so a
later page can still override one control by ordinary means.
SCOPE NOTE: this touches EVERY prototype-vocabulary screen, not only the
Green form. That is intended — one type scale everywhere is the point.
Legends are left alone: a section legend is a heading, not a field label,
and the two forms structure their sections differently.
========================================================================== */
/* ---- THE SCALE: THE PROTOTYPE'S OWN COMPACT SIZES, ARRIVED AT BY REDUCTION ----
The history is worth keeping because it explains the destination. This block
first LIFTED the prototype form vocabulary from 14px up to the USWDS ~17px so a
Green-form field matched a White-form one. That size was reported as too big and
came down to 16px. It was reported as too big again, together with body copy, and
it now sits at 14px labels/controls and 13px hints.
That is not an arbitrary third guess — it is exactly where the rest of the
application already was, and the reason it is a good place to stop:
- tokens.css:423-428 sizes .inp / select.inp / textarea.inp at --fs-2xs (14px).
These rules now AGREE with the sheet they override instead of fighting it.
- site-enhance.css:73-109 already pulls the USWDS vocabulary (.usa-label,
.usa-input, .usa-select, .usa-textarea) to --fs-2xs and its hints to
--fs-3xs. Both vocabularies are therefore on one 14/13 scale now, which is
this block's entire purpose — reached by bringing USWDS DOWN to the
prototype scale rather than the prototype UP to the federal one.
- prototype-app.css designed these forms at 14px labels / 13px hints in the
first place.
LABELS AND CONTROLS ARE HELD AT THE SAME VALUE ON PURPOSE — the original
reported fault was a control reading LARGER than the label above it, so these
two rules must move together or the fault comes straight back.
The literal fallbacks matter: _PrototypeLayout does not load tokens.css, so
--fs-2xs / --fs-3xs are undefined there and the fallback is what those screens
actually use. 0.875rem and 0.8125rem are prototype-final.css's own --fs-body and
--fs-floor (lines 244-246), so the fallback is not an approximation of that
layout's scale — it IS that layout's scale, and these rules leave it untouched
while moving _Layout onto it. */
/* Field labels. Weight stays semibold: it reads as a label at this size and
matches the emphasis the prototype forms were designed around.
.lbl IS INCLUDED and was the actual reported defect: Views/Account/Register.cshtml
uses the account vocabulary (.lbl x26, .inp x18) but is on _Layout, which loads
neither prototype-account.css nor prototype-final.css — the only sheets that
style .lbl. So its labels fell back to inherited body text while .inp was being
enlarged by the rule below, and the control ended up bigger than its own label.
Listing .lbl here puts both on the one scale without pulling a conflicting
stylesheet into _Layout's cascade (see _Layout's own warning about
prototype-final.css redefining .card/.btn/.inp/.chip). */
.fld__lbl,
.fld__label,
.lbl {
font-size: var(--fs-2xs, 0.875rem);
}
/* The controls themselves — text inputs, selects and textareas carrying the
prototype .inp class — and .ro beside them, which is the READ-ONLY rendering
of the same field. CLAUDE.md requires a read-only field to render as text
rather than a disabled input, so it has to sit at the control size or a
locked field would visibly shrink next to an editable one. */
.inp,
select.inp,
textarea.inp,
.ro {
font-size: var(--fs-2xs, 0.875rem);
}
/* Hints and helper notes — one step below the label, so they read as
supporting text without dropping to fine print. .hint is the account
vocabulary's name for the same thing, included for the reason .lbl is. */
.fld__hint,
.fs__hint,
.fld__note,
.hint {
font-size: var(--fs-3xs, 0.8125rem);
}
/* =============================================================================
THE CONFIRMATION DIALOGUE (wands-modal.js)
Added 18 Sep 2026, when window.confirm() was replaced everywhere.
A real