/* Promethos Cyber Services.
No external resources by design: no web fonts, no CDNs, no third-party scripts.
A security practice should not leak its visitors to other people's servers.
THIS SITE AND THE PORTAL ARE NOW ONE DESIGN SYSTEM (I125). Chay chose it:
a client who books here lands in the portal, and until 21 September 2026
the two looked like two different companies at the moment of handover.
The tokens below are the portal's, named as the portal names them
(portal/src/app/globals.css). That file is upstream; when a value changes
there it is meant to change here, and the shared names are what make that a
copy rather than a translation.
HOW CLOSE THEY ALREADY WERE, measured rather than assumed. Five of the
site's seven colours were already the portal's exact hexes -- obsidian was
ink-900, charcoal was ink-700, slate was ink-100, white was bg-surface, and
Forge Amber is literally the client portal's accent. Two had drifted: the
border grey (#D8E0EA here, #E2E8F0 there) and the link amber (#B8441A here,
#C2461A there). So this was never a reskin. It was two systems built from
one palette that had drifted in two values and in structure, and the
structure is where the visible difference lived. */
:root {
/* ---- the portal's neutral scale, verbatim ---- */
--ink-900: #0F172A;
--ink-800: #1E293B;
--ink-700: #334155;
--ink-600: #475569;
--ink-500: #64748B;
--ink-400: #94A3B8;
--ink-300: #CBD5E1;
--ink-200: #E2E8F0;
--ink-100: #F1F5F9;
--bg-page: #F8FAFC;
--bg-surface: #FFFFFF;
/* ---- accent ----
The portal gives each portal a colour and calls the active one --accent.
The public site is the front door of the client relationship, so it takes
the client portal's accent, which is Forge Amber. One colour, two
systems, and no translation step. */
--accent: #E25822;
--accent-tint: #FFF1EC;
--accent-tint-text: #C2461A;
--accent-hover: #9C3814;
/* Hover for the amber button. Lighter, not darker: the label is
ink-900, so darkening would cost contrast rather than add it. */
--accent-lift: #E76634;
/* ---- the portal's radii and header metrics ---- */
--radius-sm: 6px;
--radius-md: 7px;
--radius-lg: 8px;
--radius-xl: 10px;
--header-height: 56px;
--accent-bar-height: 3px;
--font-sans: system-ui, -apple-system, 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
--maxw: 68rem;
/* ---- brand aliases ----
Kept, pointing at the tokens above, because this site's own vocabulary is
Deep Obsidian Blue and Forge Amber and a stylesheet that no longer says
so is harder for Chay to read than one that does. They are aliases, not a
second source of truth: nothing below sets them to anything new. */
--obsidian: var(--ink-900);
--amber: var(--accent);
--amber-lift: var(--accent-lift);
--amber-dark: var(--accent-tint-text);
--charcoal: var(--ink-700);
--slate: var(--ink-100);
--line: var(--ink-200);
--white: var(--bg-surface);
--font: var(--font-sans);
--nav-h: var(--header-height);
}
*, *::before, *::after { box-sizing: border-box; }
html { -webkit-text-size-adjust: 100%; }
/* BODY TEXT IS ink-700 ON bg-page, which is the portal's own pairing and
9.9:1. The page tint is the portal's most quietly structural idea: content
sits on #F8FAFC and anything that is a THING -- a card, a form, a table --
is white and bordered, so surfaces read as surfaces instead of being marked
out by rules on a flat white field.
THE READING SIZE STAYS 17px AND DOES NOT DROP TO THE PORTAL'S 14.5px, which
is the one place this file deliberately parts from upstream. The portal's
comfortable density is sized for scanning records; these pages are prose a
stranger reads once, at arm's length, deciding whether to trust us. Copying
a density built for tables onto an argument would be matching the letter of
the portal and losing the point. Everything that IS a control or a record
here -- form fields, the facts table, the footer -- does take the portal's
sizes. */
body {
margin: 0;
font-family: var(--font-sans);
font-size: 1.0625rem;
line-height: 1.6;
color: var(--ink-700);
background: var(--bg-page);
}
.wrap { width: 100%; max-width: var(--maxw); margin: 0 auto; padding-inline: 1.25rem; }
/* The portal's link pair exactly (globals.css): accent-tint-text, darkening
to accent-hover. The site's own link amber was #B8441A -- 4.5% off, nobody
would see it side by side, and that is the kind of drift that makes two
systems quietly stop being one. Both pass: 5.02:1 on surface, 4.80:1 on the
page tint. */
a { color: var(--accent-tint-text); text-decoration-thickness: 1px; text-underline-offset: 2px; }
a:hover { color: var(--accent-hover); }
:focus-visible { outline: 3px solid var(--accent); outline-offset: 2px; }
.skip {
position: absolute; left: -9999px; top: 0;
background: var(--obsidian); color: var(--white);
padding: .75rem 1rem; z-index: 100;
}
.skip:focus { left: 0; }
/* Header and navigation.
STICKY, NOT FIXED, AND THE BANNER IS GONE. Until 21 September 2026 the
nav was position:fixed and overlaid a separate .banner block that
existed to show the full logo -- and that banner had to reserve
--nav-h of top padding so the fixed bar did not cover it. Two elements
showing the same brand, one of them compensating for the other.
Measured before removing it: the banner was 237px tall on a laptop and
183px on a phone, so roughly a quarter of the first screen was spent
restating a logo the bar above it already carried, before a single word
of the message. Its image was also 166KB of a 225KB page -- the two
logos together were 86% of everything the homepage transferred.
The bar now carries the full lockup and sticks by participating in
layout rather than being lifted out of it, so nothing below it needs to
reserve space and there is no spacer to get wrong. */
.site-head a { color: var(--ink-200); text-decoration: none; }
/* THE DARK HEADER AND THE 3px ACCENT BAR ARE THE PORTAL'S SIGNATURE (I125),
and adopting them is most of what "match the portal" turns out to mean.
Every portal screen opens with an ink-900 bar 56px tall and a 3px rule
beneath it in the active portal's colour. Somebody who uses the portal
recognises that shape before they read a word of it.
This bar was white with a 1px grey border and 64px tall. Nothing was wrong
with it; it simply belonged to a different system, and it was the first
thing a client saw change when they signed in.
THE BAR IS ALSO WHY THE HERO'S OWN AMBER RULE IS GONE. The hero used to
draw a 4rem amber rule under its headline. With a 3px accent bar directly
above it that was the same gesture twice in 200px. */
.nav-bar {
position: sticky; top: 0; z-index: 200;
background: var(--ink-900);
border-bottom: var(--accent-bar-height) solid var(--accent);
}
/* THE BAR IS CENTERED, IN A COLUMN WIDER THAN THE CONTENT'S.
It was briefly full width, copied from PortalShell's header, which is
`padding: 0 20px` across the whole viewport. That is right for the portal
and wrong here, and Chay caught it on a large screen: the portal is an
application whose content fills the window, so a full-width header lines up
with everything below it. This site has a centered 68rem column, so a
full-width bar lined up with nothing -- the logo sat at the window's edge
while every word beneath it started hundreds of pixels inboard.
SO WHY NOT 68rem, matching the content exactly? Measured: the bar's
contents need 1134px (1167px before "Event RSVP" became "Events") and the
content column offers 1048px inside its padding. It is 86px short, and the only ways to close that are shrinking
the type until it fits or dropping a nav item -- the first makes the whole
bar look cramped to fix an alignment nobody would otherwise notice, and the
second is a content decision rather than a layout one.
78rem is the narrowest column that holds the row with room to spare. The
bar is therefore centered like everything else, in a slightly wider column,
which reads as deliberate in a way that flush-left did not. */
.nav-inner {
display: flex; align-items: center; gap: 1rem;
min-height: var(--header-height); position: relative;
max-width: 78rem; padding-inline: 20px;
}
.brand { display: flex; align-items: center; }
/* REVERSED LOCKUP, because the bar is now dark, and it is COMPOSED rather
than recoloured -- the second attempt, after Chay looked at the first one
live and said the flare looked awful.
He was right and the reason is worth keeping. The horizontal lockup in the
brand files is painted with a radial amber glow around the shield, which is
made to sit on white. Recolouring that artwork for a dark bar keeps the
glow, and the glow overlaps the letters, so stripping it afterwards leaves
orange fringes on the H, the S and half of CYBER SERVICES. The asset was
fighting back because it was never drawn for this.
So it is built from two pieces that were each already correct:
Promethos_logo_ShieldOnly_DarkBG_Inverted, which is the shield DRAWN for
dark backgrounds with the thick white outline Chay asked for, and the
wordmark from the STACKED lockup, which carries no glow at all -- zero warm
pixels in it, where the horizontal one had 33,509. Neither is recoloured
beyond turning the wordmark's grey ink white. Source files untouched.
width/height are on the ![]()
as well, so the bar does not reflow when the
logo finishes loading. */
.brand-icon { height: 2.75rem; width: auto; }
/* 2.75rem = 44px, the minimum comfortable tap target, and the size
.submenu-toggle below already uses. This was 2.25rem (36px) -- on a phone
it is the only way to open the navigation at all, so it was the worst
element on the site to have undersized. align-items centres the bars now
that the button is wider than they are. */
.nav-toggle {
display: none; margin-left: auto; flex-direction: column;
justify-content: center; align-items: center; gap: 5px;
width: 2.75rem; height: 2.75rem; background: none; border: 0; padding: 0; cursor: pointer;
}
.nav-toggle span { width: 1.375rem; }
.nav-toggle span { display: block; width: 100%; height: 2px; background: var(--ink-200); }
.nav {
display: flex; flex-wrap: wrap; align-items: center; gap: .25rem 1.25rem;
list-style: none; margin: 0 0 0 auto; padding: 0;
font-size: .95rem;
}
.nav > li { position: relative; }
.nav > li > a { display: block; padding-block: .25rem; border-bottom: 2px solid transparent; }
/* The portal marks the active nav item in the accent too, so hover and
current read the same here as they do there. On ink-900 the label itself
lifts to white rather than changing hue, which keeps the amber meaning
"this one" instead of meaning "a link". */
.nav > li > a:hover, .nav > li > a[aria-current="page"] {
border-bottom-color: var(--accent); color: var(--bg-surface);
}
.has-sub > a::after { content: ""; display: inline-block; margin-left: .35em; border: 4px solid transparent; border-top-color: currentColor; vertical-align: middle; }
.submenu-toggle { display: none; }
/* SIGN IN. The site had no way into the portal at all -- eight phases of it
built, and the front door never pointed at the thing. Somebody with an
account had to already know the URL.
IT IS A CONTROL, NOT A NAV LINK, so it is outlined rather than underlined:
a person looking for the way in scans for a box, not for the tenth word in
a row of nine. And it is outlined rather than filled, because a filled
amber button on this site means "start the Pulse Check" -- the thing we
want a STRANGER to press. Signing in is for the handful of people who
already have an account, and it should be findable without competing with
the call to action aimed at everybody else.
The rule on its left does the work extra spacing cannot: it says this item
is not part of the list. */
.nav-signin { margin-left: .5rem; padding-left: 1.25rem; border-left: 1px solid var(--ink-700); }
.nav-signin > a {
display: block; padding: .55rem 1rem;
border: 1px solid var(--ink-600); border-radius: var(--radius-md);
font-weight: 600; line-height: 1.2;
}
.nav-signin > a:hover {
background: var(--ink-800); border-color: var(--ink-500);
color: var(--bg-surface);
}
/* The dropdown stays inside the dark assembly rather than being a white panel
hanging off a dark bar, which would put the seam back one element lower. */
.submenu {
display: none; position: absolute; top: 100%; left: 0; z-index: 210; margin: 0; padding: .4rem 0;
list-style: none; min-width: 15rem; background: var(--ink-800);
border: 1px solid var(--ink-700);
border-radius: 0 0 var(--radius-lg) var(--radius-lg);
box-shadow: 0 8px 20px rgba(15, 23, 42, .35);
}
.has-sub:hover > .submenu, .has-sub:focus-within > .submenu { display: block; }
.submenu li a { display: block; padding: .5rem .9rem; border-bottom: 0; font-size: .9rem; }
.submenu li a:hover { background: var(--ink-700); color: var(--bg-surface); }
/* 1200px, NOT 860px, AND THIS WAS ALREADY BROKEN BEFORE SIGN IN ARRIVED.
Measured: with nine items the row wrapped below about 1100px, so at 1000px
"Pulse Check" -- the site's primary call to action -- sat alone on a second
line and the 56px bar grew to 76px. The breakpoint was 860px, so that band
from 861px to about 1100px got a broken desktop bar instead of the working
mobile one: every iPad in landscape, and a good number of laptops.
With the tenth item the row needs 1134px of content, so it needs a 1174px
window before padding -- and the breakpoint has to sit above that, not at
it, or the first desktop width is also the first width that wraps. 1240px
leaves 66px of slack at the narrowest desktop, which is kept rather than
tightened because the row has grown twice already.
It means tablets and small laptops get the mobile navigation, which is the
right trade -- that nav is carefully built, and a wrapped two-row bar
inside fixed-height chrome is worse than a menu button on any screen. */
@media (max-width: 1240px) {
.nav-toggle { display: flex; }
.nav {
position: absolute; top: 100%; left: 0; right: 0; margin: 0; flex-direction: column;
align-items: stretch; gap: 0; background: var(--ink-900);
border-bottom: 1px solid var(--ink-700);
max-height: 0; overflow: hidden;
}
.nav.open { max-height: 80vh; overflow-y: auto; }
.nav > li > a { padding: .8rem 1.25rem; }
.has-sub { display: flex; flex-wrap: wrap; align-items: center; }
.has-sub > a { flex: 1; }
.has-sub > a::after { display: none; }
/* First layer loads collapsed: the parent link still navigates to its
hub page, and a tap on the chevron button expands just that one
submenu in place, single column, without a second tap needed to
reach the hub page itself. */
.submenu-toggle {
display: flex; align-items: center; justify-content: center;
width: 2.75rem; height: 2.75rem; background: none; border: 0; padding: 0; cursor: pointer;
}
.submenu-toggle::after {
content: ""; width: 8px; height: 8px; border-right: 2px solid var(--ink-200);
border-bottom: 2px solid var(--ink-200); transform: rotate(45deg); transition: transform .15s ease;
}
.submenu-toggle[aria-expanded="true"]::after { transform: rotate(-135deg); }
/* STATIC, NOT ABSOLUTE. The base rule positions the dropdown absolutely,
which is right when it hangs off a desktop bar and wrong inside the
stacked mobile panel: an expanded submenu was drawn OVER the nav item
below it instead of pushing it down, so opening "Client Industries"
covered "Industry Insights".
This is not new -- it has been true since the mobile nav was written.
It was invisible because the panel and the submenu were both white, so
the overlap had no edge to see. Giving the submenu its own ink-800 (I125)
is what made a year-old bug show up. */
/* In the panel it is a row like the others, because a small outlined box
floating in a full-width list reads as debris. It keeps a border on the
top edge only, marking where the navigation stops and the account
starts. */
.nav-signin {
margin: 0; padding: 0;
border-left: 0; border-top: 1px solid var(--ink-700);
}
.nav-signin > a { padding: .8rem 1.25rem; border: 0; border-radius: 0; }
.submenu {
display: none; width: 100%;
position: static; border: 0; border-radius: 0;
box-shadow: none; background: var(--ink-800);
min-width: 0; padding: 0;
}
.submenu li a { padding: .7rem 1.25rem .7rem 2rem; }
/* Beats the base :hover/:focus-within reveal rule's specificity, so
tabbing to (or clicking) the parent link alone doesn't pop the
submenu open -- only the toggle's "open" class does. */
.has-sub:hover > .submenu:not(.open), .has-sub:focus-within > .submenu:not(.open) { display: none; }
.nav .has-sub > .submenu.open { display: block; }
}
/* Hero and page heads.
THE HERO IS NO LONGER A DARK BAND, and this is the change with the most
argument behind it. The portal has exactly one dark region -- the header --
and everything beneath it is light: bg-page with white surfaces on it.
A site whose first screen is a slab of obsidian does not look like that
product, it looks like a different product with the same logo. Now that
the bar above is ink-900 the dark weight is where the portal puts it, and
the hero can do the job a hero is actually for.
What it gives up is the poster moment, and that is a real cost rather than
a free win: a light hero has to earn attention with type and space instead
of with a colour field. It is bought back in the headline size, in the
eyebrow, and in the amber sitting on white where it is loudest. */
.hero {
background: var(--bg-page); border-bottom: 1px solid var(--ink-200);
padding-block: 3.5rem 3rem; text-align: center;
}
.hero h1 {
margin: 0 0 .7rem; color: var(--ink-900);
font-size: clamp(1.9rem, 5vw, 3rem); font-weight: 600;
line-height: 1.15; letter-spacing: -0.02em;
}
.hero .lede {
font-size: clamp(1.05rem, 2.2vw, 1.3rem); color: var(--ink-600);
max-width: 46ch; margin: 0 auto 1.75rem; line-height: 1.5;
}
.hero .btn-row { justify-content: center; }
/* THE EYEBROW IS LIFTED STRAIGHT FROM THE BOOKING PAGE (book.module.css
.brand): 12px, 600, 0.08em, uppercase, ink-500. It is the portal's way of
labelling a thing before naming it, it is the detail a returning client
will have seen most often, and it is what replaces the little amber rule
these heads used to draw -- which was the same gesture as the accent bar
now directly above them. */
.eyebrow {
font-size: 12px; font-weight: 600; letter-spacing: 0.08em;
text-transform: uppercase; color: var(--ink-500); margin: 0 0 .75rem;
}
.page-head {
background: var(--ink-100); border-bottom: 1px solid var(--ink-200);
padding-block: 2.5rem 2rem; text-align: center;
}
.page-head h1 {
margin: 0; color: var(--ink-900); font-size: clamp(1.6rem, 4vw, 2.25rem);
font-weight: 600; line-height: 1.25; letter-spacing: -0.02em;
}
main { padding-block: 2.5rem 3rem; }
main h2 { color: var(--ink-900); font-size: 1.4rem; font-weight: 600; margin: 2.25rem 0 .75rem; letter-spacing: -0.01em; }
main h2:first-child { margin-top: 0; }
main h3 { color: var(--ink-900); font-size: 1.1rem; font-weight: 600; margin: 1.5rem 0 .4rem; }
main p { max-width: 70ch; }
main > .wrap > :first-child { margin-top: 0; }
.lead { font-size: 1.15rem; color: var(--ink-800); }
/* Article byline, above the lead paragraph on a /news/* page. Same eyebrow
idiom as above, in the accent's text colour rather than ink-500 because
here it carries a date somebody may actually want to read. */
.article-meta {
font-size: 12px; font-weight: 600; text-transform: uppercase; letter-spacing: .08em;
color: var(--accent-tint-text); margin: 0 0 1rem;
}
/* Lists */
ul.ticks { list-style: none; padding: 0; margin: 1rem 0; max-width: 70ch; }
ul.ticks li { position: relative; padding-left: 1.5rem; margin-bottom: .7rem; }
ul.ticks li::before {
content: ""; position: absolute; left: 0; top: .55em;
width: .5rem; height: .5rem; background: var(--amber); border-radius: 1px;
}
ul.ticks strong { color: var(--obsidian); }
/* Cards.
THE PORTAL'S SURFACE, which is one border and one radius and no accent
stripe: 1px ink-200, radius-xl, bg-surface, sitting on the page tint. These
used to carry a 3px amber top border, which is how a card announces itself
on a flat white page -- but the page is no longer flat white, so the tint
does that work and the stripe became decoration. The portal draws its cards
this way on every screen; matching it is most of why the two now look
related at a glance. */
.cards { display: grid; gap: 1rem; grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)); margin: 1.5rem 0; }
.card {
border: 1px solid var(--ink-200); border-radius: var(--radius-xl);
padding: 1.25rem 1.35rem; background: var(--bg-surface);
}
.card h3 { margin-top: 0; }
.card p { margin-bottom: 0; font-size: 1rem; }
.card a { font-weight: 600; }
/* Callout and CTA band.
The callout keeps its amber edge: it is the one component whose whole job
is to be interrupted by, and the portal uses the accent the same way on a
selected row. Radius follows the portal now. */
.callout {
background: var(--ink-100); border-left: 3px solid var(--accent);
padding: 1.25rem 1.5rem; margin: 2rem 0;
border-radius: 0 var(--radius-lg) var(--radius-lg) 0;
}
.callout p { margin: 0 0 1rem; }
.callout p:last-child { margin-bottom: 0; }
/* THE BAND IS THE ONE DARK BLOCK LEFT BELOW THE HEADER, and it is kept on
purpose after the hero gave its obsidian up. It is the closing ask, it
appears once per page at the foot, and it is the same ink-900 as the bar at
the top -- so the dark on these pages now bookends the content rather than
being scattered through it. Removing it too would leave the site with no
weight anywhere, which is faithfulness past the point of usefulness. */
.band { background: var(--ink-900); color: var(--bg-surface); padding-block: 2.75rem; margin-top: 3rem; }
.band h2 { color: var(--bg-surface); margin-top: 0; }
.band p { color: var(--ink-300); max-width: 60ch; }
/* OBSIDIAN ON AMBER, NOT WHITE ON AMBER, and this was a real failure rather
than a preference. White #FFFFFF on Forge Amber #E25822 is 3.72:1, and
WCAG AA needs 4.5:1 for text this size -- so the single most important
element on the site, the button that starts the Pulse Check, was the one
thing on it that did not meet the standard. On the website of a security
practice that is the same class of problem as the Google Forms iframes.
Deep Obsidian Blue on the same amber is 4.81:1 and passes. It is the fix
that keeps the brand rather than compromising it: Forge Amber stays at
full strength and the two brand colours sit together, instead of the
orange being darkened until white would sit on it.
Hover lifts rather than darkens, because darkening reduces contrast with
dark text. #E76634 is 5.40:1 and still unmistakably the same colour.
AND MATCHING THE PORTAL DOES NOT UNDO THIS (I125). The portal's buttons are
white on var(--accent), which is correct for four of its five portals --
admin 4.76, executive 6.97, staff 5.10, partner 6.88 -- and wrong for the
fifth, because the client portal's accent is this same Forge Amber and
white on it is the same 3.72:1. So the portal has the site's old bug in the
one portal a client sees. Copying the button verbatim would have reinstated
here the exact failure that was fixed five days ago. The shape, padding and
radius come from the portal; the colour does not. Filed as I124. */
.btn {
display: inline-block; background: var(--accent); color: var(--ink-900) !important;
padding: 12px 18px; border-radius: var(--radius-md); font-weight: 600;
font-size: 15px; text-decoration: none; border: 0;
}
.btn:hover { background: var(--accent-lift); }
/* The portal's secondary button is book.module.css .icsLink: the accent as an
outline instead of a fill, same size as the primary.
IT HAD TO CHANGE COLOUR, not just shape. It was white text on a transparent
background, which worked only because the hero behind it was obsidian --
and the hero is not obsidian any more. On the page tint that button was
white on #F8FAFC, which is invisible rather than merely low contrast. So
the default is now the outline on light, and the dark band overrides it. */
.btn-ghost {
background: transparent; color: var(--accent-tint-text) !important;
border: 1px solid var(--accent);
}
.btn-ghost:hover { background: var(--accent-tint); }
.band .btn-ghost {
color: var(--bg-surface) !important; border-color: var(--ink-600);
}
.band .btn-ghost:hover { background: var(--ink-800); }
.btn-row { display: flex; flex-wrap: wrap; gap: .75rem; margin-top: 1.25rem; }
/* Event detail table */
/* A record, so it takes the portal's table sizing rather than the page's
reading size: 14.5px rows, ink-200 rules, and a white surface with a border
and a radius instead of zebra striping. The portal does not stripe -- its
rows are separated by a rule and the surface is one colour -- and striping
is the older convention of the two. */
.facts {
border-collapse: collapse; margin: 1.5rem 0; width: 100%; max-width: 34rem;
font-size: 14.5px; background: var(--bg-surface);
border: 1px solid var(--ink-200); border-radius: var(--radius-lg);
overflow: hidden;
}
.facts th, .facts td { text-align: left; padding: 11px 14px; border-bottom: 1px solid var(--ink-200); vertical-align: top; }
.facts tr:last-child th, .facts tr:last-child td { border-bottom: 0; }
.facts th { color: var(--ink-900); font-weight: 600; white-space: nowrap; width: 7.5rem; }
.facts td { color: var(--ink-700); font-variant-numeric: tabular-nums; }
/* Our own forms (I121). The three Google Forms iframes these replace were the
one place this site handed its visitors to somebody else's server, which the
header of this file says it does not do. */
.form { margin: 1.5rem 0; max-width: 42rem; }
/* The fieldset is a portal surface; the inputs are the booking page's inputs
(book.module.css .input/.label), down to the 15px value, the 13px label and
the ink-300 border. Somebody who fills the contact form here and then a
form inside the portal should not be able to tell the two apart, because
from where they sit it is one company asking twice. */
.form > fieldset {
border: 1px solid var(--ink-200); border-radius: var(--radius-xl);
padding: 1.25rem 1.35rem 1.5rem; margin: 0 0 1.5rem; background: var(--bg-surface);
}
.form > fieldset > legend { font-weight: 600; color: var(--ink-900); padding-inline: .4rem; }
/* A QUESTION IS NOT A SURFACE, and until now it was drawn as one. Each Pulse
Check question is a fieldset nested inside its section's fieldset -- correct
markup, because the Yes/No pair needs its own group label for a screen
reader. But `.form fieldset` gave every fieldset the panel border, so each
question got a second box inside the first, and a