/* =========================================================================
   DTA Collectibles — site chrome

   The header and the departments nav, plus the two things that have to be
   site-wide rather than per-template: the pinned type scale and the shell
   width.

   Loaded on every page. The header block below is the spec from tokens.css —
   .site-header / .site-header__inner / .brand / .brand__mark / .brand__name /
   .brand__tagline / .site-nav — carried over with two documented changes and
   nothing else. Header rules live here and nowhere else; no template
   redefines them.
   ====================================================================== */

/* =========================================================================
   1. TYPE AND SPACE SCALES — pinned, site-wide
   =========================================================================

   Moved here from archive.css, because the header needs it too and archive.css
   only loads on category pages.

   tokens.css states the scale in rem, and rem resolves against the ROOT
   element, which nothing in this theme's own files controls. This site's root
   is not at the 16px the scale assumes, so every token rendered at a fraction
   of its intended size — the tell was that only the two largest steps survived
   legibly. Stated in px here, the scale is right whatever the root turns out to
   be, so this is not a bet on the root's value.

   THE VALUES ARE UNCHANGED. Each is exactly what its rem token means at a 16px
   root, which is what tokens.css was written against. Nothing in Tyler's file
   is edited and no new value is introduced.

   If the root is ever normalised to 100%, delete this block and the rem tokens
   carry the same sizes on their own.
   ====================================================================== */

:root {
  --t-xs:   13px;   /* 0.8125rem @16 */
  --t-sm:   14px;   /* 0.875rem      */
  --t-base: 16px;   /* 1rem          */
  --t-md:   20px;   /* 1.25rem       */
  --t-lg:   25px;   /* 1.5625rem     */
  --t-xl:   31px;   /* 1.9375rem     */
  --t-2xl:  39px;   /* 2.4375rem     */

  /* The SPACE scale has exactly the same problem and needs exactly the same
     fix. Missing it the first time is why the archive read tight: every gap,
     padding and margin in both stylesheets comes from these, so at a shrunken
     root the whole layout was spaced at a fraction of its intended rhythm —
     --s-5, the header's own horizontal padding, was rendering at 15px instead
     of 24px. Found by measuring the header's left edge against the content
     row's, not by reading. */
  --s-1:  4px;      /* 0.25rem @16 */
  --s-2:  8px;      /* 0.5rem      */
  --s-3:  12px;     /* 0.75rem     */
  --s-4:  16px;     /* 1rem        */
  --s-5:  24px;     /* 1.5rem      */
  --s-6:  32px;     /* 2rem        */
  --s-7:  48px;     /* 3rem        */
  --s-8:  64px;     /* 4rem        */

  /* ---------------------------------------------------------------------
     SHELL WIDTH — one number, so the header and the content line up.

     tokens.css sets --page-max: 1200px, which is what the header was drawn
     against and what OceanWP's container happens to be. The archive row was
     widened past it to earn another column of merchandise, and the two then
     disagreed.

     This is now the single value both use: the header inner, the nav inner and
     the archive row all read it. Change it here and they move together.

     THE FOOTER DOES FOLLOW, and this note used to say it did not. Corrected
     Sept 10 by measuring rather than reading: `#footer-inner` carries class
     `clr`, not `container`, so the ID-qualified selector below never matches
     it — but the footer's real row is `.footer-widgets-inner.container`, which
     `body .container` matches, and its max-width resolves to this calc on the
     live page. Header, content and footer are already one width.

     The tidier end state still stands: set this to var(--page-max) and raise
     Site Width in the Customizer instead, leaving no width in a stylesheet at
     all. One line, and it needs a setting changed before the page is right,
     which is why it was not taken by default.
     ------------------------------------------------------------------ */
  --dta-shell-max: 1440px;
}

/* =========================================================================
   1b. THE SHELL — applied, not just declared
   =========================================================================

   The width above is only useful if everything reads it. OceanWP lays out the
   header, the content row and the footer inside `.container`, so that is where
   it goes — one rule, and the three line up.

   Applying it here rather than only on the archive matters: header.php is
   site-wide now, so a width set on category pages alone would put a 1440px
   header over a 1200px body on every product page, cart and home page. That is
   the same misalignment, just moved.

   The horizontal padding is set alongside the max-width on purpose. Matching
   max-widths is not enough to make two rows line up — their inner padding has
   to match too, and OceanWP's container padding is not a value this file can
   read. Setting both makes the left and right edges deterministic.

   THIS SUPERSEDES THE CUSTOMIZER'S SITE WIDTH. That is a real trade and worth
   knowing before someone spends an afternoon wondering why the setting does
   nothing: the width now lives in --dta-shell-max, in this file. The other end
   state — set --dta-shell-max to var(--page-max) and raise Site Width in the
   Customizer instead — is tidier in that it leaves no width in a stylesheet at
   all, and it is one line to switch to. It was not taken by default because it
   needs someone to change a setting before the page is right, and this does
   not.
   ====================================================================== */

/* The max-width includes the gutters on purpose.

   .site-header puts its padding on the OUTSIDE of the max-width element
   (.site-header pads, .site-header__inner caps), so the header's content box is
   the full shell width. .container puts its padding INSIDE. Setting both to the
   same max-width therefore leaves the content row inset by exactly one gutter
   against the header — 264px against 240px at a 1920 viewport, which is the
   kind of near-miss that reads as sloppy rather than as a bug.

   Adding the two gutters here makes the container's CONTENT box equal the
   shell, which is what the header's is. Measured equal at 1920, 1600, 1280,
   900, 600 and 375.

   The ID-qualified selectors are not padding. OceanWP's site width can arrive
   as an ID rule — #content-wrap, #footer-inner — and an ID beats `body
   .container` however late this file loads. The four named here are the
   containers in the wrapper chain recorded in THEME-CONSTRAINTS.md. */
body .container,
body #content-wrap.container,
body #footer-inner.container,
body #top-bar.container,
body #site-header-inner.container {
  /* Set here, not assumed. The calc above only means "shell plus gutters" if
     max-width includes the padding; under content-box it would leave the row a
     gutter too wide. OceanWP does set border-box globally, but the card grid
     already taught this lesson once — depending on the host for it costs
     nothing to avoid. */
  box-sizing: border-box;

  /* WIDTH IS SET HERE BECAUSE THE max-width BELOW REPLACED THE THING THAT WAS
     HOLDING IT, AND THAT WAS A SITE-WIDE REGRESSION THIS PORT INTRODUCED.

     OceanWP ships `.container { width: 1200px; max-width: 90% }`. The fixed
     width is not the responsive part; the PERCENTAGE cap is. On a 375px phone
     90% resolves to 337px and the row fits.

     Overriding max-width with a px calc took that cap away and left the 1200px
     width with nothing to hold it. Measured on staging at a real 375px
     viewport: document scrollWidth 1200 against a clientWidth of 375 — 825px
     of horizontal overflow, on every page of the site, at every viewport under
     1200px. It reached the front page only through the footer, because the
     ported templates deliberately do not use .container — front-page.php says
     so in as many words — so the footer was the last carrier and the last
     place anyone looked.

     OceanWP's own `@media (max-width: 959px) { .container { max-width: 90% } }`
     does not rescue it either: `body .container` outranks `.container`, so this
     rule wins at every width including inside that query.

     `width: 100%` restores the behaviour the percentage was providing: fill the
     space below the cap, cap above it. The max-width still does the alignment
     job described above.

     WHY THE ORIGINAL MEASUREMENT MISSED IT. The note above records equality
     with the header at 1920, 1600, 1280, 900, 600 and 375 — and that was true
     and is still true. Equality with the header was the property under test;
     whether either element fitted the viewport was not. Two rows can line up
     perfectly and both hang off the side of the screen. */
  width: 100%;

  max-width: calc(var(--dta-shell-max) + var(--s-5) * 2);
  margin-left: auto;
  margin-right: auto;
  padding-left: var(--s-5);
  padding-right: var(--s-5);
}

/* =========================================================================
   2. HEADER — the spec from tokens.css

   Two changes from that file, both deliberate, nothing else touched:

   1. The bare rem values in .brand__name (1.625rem), the 860px override
      (1.25rem), .brand__tagline (0.84375rem) and .site-nav a (0.90625rem) are
      stated in px — 26px, 20px, 13.5px and 14.5px. Same reason as the type
      scale above, same arithmetic: each is its rem value at a 16px root. The
      wordmark is the element that suffers most from a shrunken root, so
      leaving these in rem would have shipped a 16px wordmark.

   2. .site-header__inner and .site-nav__inner read --dta-shell-max rather than
      --page-max, so the header lines up with the content.
   ====================================================================== */

:root {
  --header-bg:         var(--c-dark);
  --header-bg-nav:     var(--c-darker);
  --header-h:          88px;      /* option 2 */
  --header-nav-h:      46px;
  --mark-size:         72px;
  --mark-size-mobile:  52px;
  --header-fg:         #ffffff;
  --header-fg-dim:     #cfc4c4;
  --header-field-bg:   #3d3535;
  --header-field-br:   #4a4040;
}

.site-header { background: var(--header-bg); padding: 0 var(--s-5); }
.site-header__inner {
  max-width: var(--dta-shell-max); margin: 0 auto;
  display: flex; align-items: center; gap: var(--s-4);
  min-height: var(--header-h);
}

.brand { display: flex; align-items: center; gap: 14px; text-decoration: none; }
.brand__mark { display: block; width: var(--mark-size); height: var(--mark-size); }
.brand__name {
  font-family: var(--f-sans); font-weight: 800; font-size: 26px;
  letter-spacing: .02em; text-transform: uppercase; line-height: 1;
  color: var(--header-fg); display: block;
}
.brand__tagline {
  font-family: var(--f-narrow); font-size: 13.5px; line-height: 1;
  color: var(--header-fg-dim); display: block; padding-top: 4px;
}

.site-header__tools { margin-left: auto; display: flex; align-items: center; gap: 14px; }
.site-header select,
.site-header input[type="search"],
.site-header input[type="text"] {
  font-family: var(--f-narrow); font-size: var(--t-sm);
  background: var(--header-field-bg); border: 1px solid var(--header-field-br);
  color: #e8e0e0; padding: 9px 11px; border-radius: var(--radius);
}
.site-header input[type="search"] { width: 260px; }
.site-header__link {
  font-family: var(--f-narrow); font-size: var(--t-sm);
  color: var(--header-fg-dim); text-decoration: none;
}
.site-header__link:hover { color: var(--header-fg); }

/* Search form inside the tools cluster. The fields above are styled by
   element; these two rules cover the layout and the submit control. */
.site-header__search { display: flex; align-items: center; gap: var(--s-2); }
.site-header__search button {
  font-family: var(--f-sans); font-size: var(--t-sm); font-weight: var(--w-semibold);
  background: var(--c-accent); color: #fff; border: 0;
  border-radius: var(--radius); padding: 9px var(--s-4);
  cursor: pointer; white-space: nowrap;
}
.site-header__search button:hover { background: var(--c-accent-hover); }
.brand__text { display: block; }

/* THE GUTTER IS SPLIT BETWEEN THE TWO ELEMENTS, AND THAT IS A FOCUS-RING FIX.
   See the note above .site-nav__inner's overflow rule in section 3a: that
   element clips, so a link sitting flush against its edge has nowhere to draw
   a focus outline and the first item's ring lost its left side entirely.

   8px of the 24px gutter moves from .site-nav to .site-nav__inner, so the
   clip edge sits 8px outside the first link instead of on top of it. The ring
   is --focus-ring (2px) at --focus-offset (2px) — 4px — so 8px is room and a
   little over.

   NOTHING MOVES. The outer loses exactly what the inner gains, and the cap
   grows by both gutters so the inner's CONTENT box is still the shell width.
   Measured on staging before and after, at 1600, 885 and 375: the nav's
   content edge sits on the header's at all three, which is the property this
   split must not break. */
.site-nav { background: var(--header-bg-nav); padding: 0 calc(var(--s-5) - var(--s-2)); }
.site-nav__inner {
  max-width: calc(var(--dta-shell-max) + var(--s-2) * 2); margin: 0 auto;
  padding-left: var(--s-2); padding-right: var(--s-2);
  display: flex; align-items: center; gap: 26px; min-height: var(--header-nav-h);
}
.site-nav a {
  font-family: var(--f-narrow); font-size: 14.5px;
  color: #d8cfcf; text-decoration: none; white-space: nowrap;
}
.site-nav a:hover, .site-nav a[aria-current] { color: var(--c-accent); }

@media (max-width: 860px) {
  :root { --header-h: 68px; --mark-size: var(--mark-size-mobile); }
  .brand__name { font-size: 20px; }
  .brand__tagline { display: none; }
  .site-header input[type="search"] { width: 100%; }
  /* overflow-y paired deliberately — see the note on the desktop rule below. */
  .site-nav__inner { gap: 18px; overflow-x: auto; overflow-y: hidden; }
  .site-header__inner { flex-wrap: wrap; }
  .site-header__tools { flex-basis: 100%; margin-left: 0; flex-wrap: wrap;
                        padding-bottom: var(--s-3); }
  .site-header__search { flex: 1 1 100%; }
}

/* =========================================================================
   3a. What the spec did not have to cover, because a mockup is not responsive
       between its breakpoints
   =========================================================================

   The header holds its desktop layout down to 860px, and at 900px it overflows:
   the tools cluster wants 663px beside the brand, and eight real departments
   want 910px of nav. The mockup never met this because it was drawn at one
   width with a hard-coded strip.

   Nothing below changes a value from the spec. The search field keeps 260px as
   its ideal and is merely allowed to shrink under pressure, and the nav keeps
   its single row and gains the scroll it already had below 860px at every
   width — where it fits, no scrollbar appears and nothing looks different.
   ====================================================================== */

.site-header__tools,
.site-header__search { min-width: 0; }

/* 260px is the basis, not a floor. */
.site-header input[type="search"] { flex: 0 1 260px; min-width: 0; }
.site-header select { flex: 0 1 auto; min-width: 0; }

/* The strip scrolls rather than wrapping: wrapping would double the 46px bar
   and the nav height is part of the header's proportions.

   BOTH AXES ARE STATED, AND THAT IS THE WHOLE POINT OF THE SECOND LINE.
   `overflow-x: auto` alone does not leave the other axis alone: per CSS
   Overflow, when one axis is not `visible` the computed value of the other
   becomes `auto`. So this rule silently asked for vertical scrolling too, and
   `scrollbar-width: thin` then drew that scrollbar down the right-hand end of
   the bar instead of hiding it. Only `hidden` is correct here — the strip is
   one row by design, so anything taller than it is a bug to see and fix, never
   something to scroll to.

   AND IT IS A CLIPPING BOX, WHICH IS THE COST. An overflow value other than
   `visible` establishes a clip on this element, so ANY descendant that escapes
   the 46px bar is cut off at it — position: absolute does not escape a
   clipping ancestor, and no z-index beats one. That is exactly what happened
   to OceanWP's mini-cart, which it appends to whatever menu sits on
   `main_menu`: `position: absolute; z-index: 10000`, and the panel rendered as
   an unreadable sliver inside the bar. It read as a stacking bug and was a
   clipping one.

   Both axes are still right, and the strip is still one row. So nothing that
   has to overflow this bar may live inside it — see dta_render_site_nav() in
   inc/header-parts.php, which discards anything appended to the menu for that
   reason. If a dropdown is ever wanted here, it has to be rendered outside
   .site-nav__inner, not unclipped by weakening this rule.

   THE SAME CLIP TOOK THE FIRST ITEM'S FOCUS RING, and the obvious fix does not
   work. Reported as `overflow-y: hidden` clipping horizontally, with the
   suggestion of dropping it now the mini-cart is no longer appended. Measured
   on staging: dropping it changes the computed overflow-y from `hidden` to
   `auto` and NOTHING ELSE — the element still clips, and the ring is still cut
   off, because the clip belongs to `overflow-x: auto`, which is the line that
   has to stay. Removing BOTH does unclip it, and cannot be done: at 375px the
   strip's scrollWidth is 341 against a 327px box, so the horizontal scroll is
   load-bearing on a phone.

   `overflow-y: hidden` is therefore still exactly right and still not the
   cause. What changed is the gutter split above .site-nav, which gives the
   first and last items 8px to draw into inside the clip rather than trying to
   remove the clip. */
.site-nav__inner {
  overflow-x: auto;
  overflow-y: hidden;
  scrollbar-width: thin;
}

/* =========================================================================
   3b. What the spec did not have to cover, because a mockup has no menu admin
   =========================================================================

   The nav is a real WordPress menu, so its markup is wp_nav_menu's, not the
   mockup's bare anchors. These rules flatten the <ul> the mockup did not have
   and give the current item the same treatment as aria-current.
   ====================================================================== */

.site-nav__inner ul {
  display: flex;
  align-items: center;
  gap: 26px;
  list-style: none;
  margin: 0;
  padding: 0;
  flex-wrap: nowrap;
}

.site-nav__inner li { margin: 0; position: relative; }

/* WordPress marks the current page on the <li>; the spec's rule targets the
   anchor. Both land in the same place. */
.site-nav .current-menu-item > a,
.site-nav .current-menu-ancestor > a,
.site-nav .current-menu-parent > a {
  color: var(--c-accent);
}

/* Submenus are not part of this design. A department's children belong on its
   own page, where they carry in-stock counts; a hover menu carries none and
   cannot be reached on a touch screen. */
.site-nav__inner .sub-menu { display: none; }

@media (max-width: 860px) {
  .site-nav__inner ul { gap: 18px; }
}

/* Skip link, sitewide. */
.skip-to-content {
  position: absolute;
  left: -9999px;
  background: var(--c-dark);
  color: var(--c-text-invert);
  padding: var(--s-3) var(--s-4);
  z-index: 100;
  font-family: var(--f-narrow);
  font-size: var(--t-sm);
}
.skip-to-content:focus {
  left: var(--s-4);
  top: var(--s-4);
  color: var(--c-text-invert);
}

/* The cart count reads as a figure, not a word. */
.site-header__link .dta-cart-count {
  font-feature-settings: var(--num-tabular);
}


/* =========================================================================
   WooCommerce's <mark>, site-wide.

   WooCommerce wraps several values in <mark> rather than <span> — the order
   number, date and status on the order-detail and order-received views:

     <mark class="order-number">1209284</mark>
     <mark class="order-date">10 September 2026</mark>
     <mark class="order-status">Processing</mark>

   <mark> carries a browser default of yellow background and black text, and
   nothing in this design had ever overridden it, so those three rendered as
   highlighter marks in the middle of otherwise finished pages.

   WHY THIS IS IN chrome.css AND NOT shop.css. It was found on the account
   pages, so shop.css is where it would naturally have gone. But <mark> is an
   element, WooCommerce reaches for it in more places than the account area —
   notices and widget counts among them — and a notice can render on any page
   of the site. Fixing it where it was noticed would have left the same yellow
   waiting on whichever page used it next. chrome.css is the stylesheet that
   loads everywhere, which makes it the only place a site-wide element reset
   can actually be site-wide.

   Semantics are kept: <mark> still means "marked for reference", it is still
   read as such, and it is still visually distinguished — by weight and by the
   strong text colour rather than by a background this palette has no value
   for.
   ====================================================================== */

mark,
.woocommerce mark {
  background: transparent;
  color: var(--c-text-strong);
  font-weight: var(--w-semibold);
  font-feature-settings: var(--num-tabular);
}


/* =========================================================================
   WooCommerce's price colour, site-wide.

   OceanWP paints .woocommerce-Price-amount and .price green — rgb(87,191,109)
   — from its own bundled WooCommerce stylesheet,
   themes/oceanwp/assets/css/woo/woocommerce.min.css. The approved mockups set
   .product .price { color: var(--c-text-strong) } and never colour a price at
   all. Green reads as a sale or a success state on a catalogue that has
   neither.

   FIFTH INSTANCE OF OCEANWP FIGHTING THE PORT, after li.product's
   col span_1_of_3, .woocommerce-MyAccount-content, .woocommerce-MyAccount-tabs
   and the .footer-box columns. The first four were float-era widths; this one
   is a colour, so it does not look like the others and was briefly attributed
   to WooCommerce core instead — from a stylesheet href truncated to its last
   two path segments, where woo/woocommerce.min.css is ambiguous between the
   plugin and this theme. Read the whole href.

   MEASURED, NOT READ. This rule cannot be found by enumerating cssRules:
   walking all 768 rules in that sheet and testing el.matches() against every
   selector that sets `color` returns nothing, while disabling that one sheet
   moves the computed colour from rgb(87,191,109) to rgb(50,43,43). Same
   enumerator blindness already recorded for the advanced-search max-width
   rule, now on a second sheet — so bisecting by disabling sheets one at a time
   is the method here, and reading the CSSOM is not.

   WHY !important, WHICH THIS FILE OTHERWISE AVOIDS. Four escalating selectors
   were injected into THIS stylesheet, in its real cascade position, and
   measured against two contexts at once — a cart line amount and a product
   card price:

     .woocommerce-Price-amount                                cart yes, card no
     .price .woocommerce-Price-amount                          neither
     ul.products li.product .price .woocommerce-Price-amount   neither
     body.woocommerce ul.products li.product .price ...        card yes, cart no

   Nothing without !important covers both, and the competing declaration cannot
   be inspected to find out why. The alternative is one selector per context —
   cart line, archive card, order summary, mini-cart, checkout review,
   order-received — which is exactly the enumeration the float-era notes in this
   port already warn against: each repair names the contexts somebody knew
   about, and the next context is uncovered. Neutralising the property on the
   class that carries it covers the contexts not yet built.

   MEASURING ONE CONTEXT WOULD HAVE SHIPPED A HALF FIX. The first candidate
   took the cart from 23 green elements to 4. The four survivors were the
   "From the same titles" cards — the archive-card price context — so a rule
   validated on cart line items alone would have gone out leaving every hub and
   leaf card green.

   SAFE TO BLANKET TODAY, AND THE CHECK IS ONE QUERY. del, ins and .onsale
   count zero across the catalogue: single physical copies, nothing is ever
   marked down, so there is no second price colour for this to flatten. If sale
   pricing is ever introduced this rule is the first thing to revisit, because
   it will paint a struck-through original the same colour as the new price.

   WHY chrome.css. Same reason as <mark> above — .woocommerce-Price-amount is
   the same class on archive cards, cart, checkout, order-received and the
   mini-cart. Verified after: cart 23 green to 0, a category page 22 to 0.
   ====================================================================== */

.woocommerce-Price-amount,
.price {
  color: var(--c-text-strong) !important;
}


/* =========================================================================
   5. FOOTER — styled, not ported

   OceanWP renders the footer and keeps rendering it. Four widgets, all
   content-driven from wp-admin:

     ocean_contact_info-1   Contact Info    text, phone, email, inquiry link
     ocean_custom_links-5   About DTA       four links
     ocean_custom_links-2   Support & Help  five links
     ocean_social-1         Follow Us       three icons

   WHY NOT A footer.php OVERRIDE. Because there is nothing here the design
   needs to change structurally, and one thing it must not: header.php opens
   #outer-wrap, #wrap and main#main, and OceanWP's footer.php is what closes
   them. That contract is currently held by exactly one file this port does not
   touch, and it has been correct since Sept 8. Taking ownership of the closing
   half to restyle four widgets would put both ends of the wrapper chain in our
   hands for no structural gain — and the widgets would still be OceanWP's,
   because they are what the client edits.

   So this section is type, colour, rhythm and the column behaviour. Every
   value is a token. Nothing below changes what the footer says or how it is
   administered, and deleting this section returns the footer to stock.

   WHAT IS DELIBERATELY LEFT ALONE:

   The social icons carry INLINE styles — height, width, line-height,
   font-size and border-radius:50%, written onto each anchor by the widget. An
   inline style beats any stylesheet rule without !important, and !important on
   a decorative circle is not a trade worth making. They stay 48px circles,
   which is a defensible size for a touch target and is the one part of the
   footer that already reads as deliberate.

   The `.container` width is NOT set here — it is fixed in section 1b above,
   because it was never a footer problem. See the note there.
   ====================================================================== */

/* The ground. OceanWP paints #footer-widgets rather than #footer, so the
   selector names the element that actually carries the colour rather than the
   one whose name suggests it. --c-darker, one step below the nav's --c-dark,
   so the page settles rather than repeating the header's weight at the bottom. */
#footer-widgets {
  background: var(--c-darker);
  padding: var(--s-7) 0;
}

#footer-bottom {
  background: var(--c-darker);
  border-top: 1px solid rgba(255, 255, 255, 0.08);
}

/* COLUMNS BY PROPERTY, NOT BY CLASS, and that is the third recurring lesson in
   this port rather than a preference.

   The four boxes are `.footer-box.span_1_of_4.col`, floated at a percentage
   width — the same float-era pattern that produced `col span_1_of_3` on the
   home grid and `width: 76%` on the account content. Enumerating the span_
   classes would fix the four that exist today and miss the fifth the moment a
   widget is added.

   So the float is neutralised on the row's children and the row becomes a grid
   that counts its own columns. auto-fit with a 200px floor gives four across on
   a desktop, two on a tablet and one on a phone, with no breakpoint stated and
   nothing to update when the widget count changes. */
#footer-widgets .footer-widgets-inner {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
  gap: var(--s-6);
}

#footer-widgets .footer-widgets-inner > * {
  float: none;
  width: auto;
  max-width: none;
  margin: 0;
  padding: 0;
}

/* Type. The footer inherits Lato from OceanWP; everything above it is Archivo.
   Narrow throughout, because a footer is reference matter read in columns. */
#footer,
#footer .widget-title,
#footer a,
#footer li,
#footer p,
#footer #copyright {
  font-family: var(--f-narrow);
}

#footer .widget-title {
  font-family: var(--f-sans);
  font-size: var(--t-xs);
  font-weight: var(--w-semibold);
  letter-spacing: 0.06em;
  text-transform: uppercase;
  color: var(--c-text-invert);
  margin: 0 0 var(--s-4);
}

/* Links read as a list of destinations, not as body text: one per line, a
   quiet rest state and the accent on hover, which is the same contract the
   departments strip uses. */
#footer .oceanwp-custom-links li,
#footer .contact-info-widget li {
  margin: 0 0 var(--s-2);
  padding: 0;
  line-height: var(--lh-snug);
  font-size: var(--t-sm);
  color: rgba(255, 255, 255, 0.72);
}

#footer .oceanwp-custom-links li:last-child,
#footer .contact-info-widget li:last-child {
  margin-bottom: 0;
}

#footer a {
  color: rgba(255, 255, 255, 0.72);
  text-decoration: none;
}

#footer a:hover {
  color: var(--c-accent);
  text-decoration: underline;
}

#footer a:focus-visible {
  outline: var(--focus-ring);
  outline-offset: var(--focus-offset);
}

/* The contact widget's own parts. The title is the label ("Phone:") and the
   text is the value, so the label recedes and the value does not. */
#footer .contact-info-widget .oceanwp-contact-title {
  display: block;
  font-size: var(--t-xs);
  color: rgba(255, 255, 255, 0.48);
}

#footer .contact-info-widget .oceanwp-contact-text {
  color: var(--c-text-invert);
  font-feature-settings: var(--num-tabular);
}

#footer .contact-info-widget li.text {
  color: rgba(255, 255, 255, 0.6);
  max-width: 34ch;
  margin-bottom: var(--s-4);
}

/* The icons the widget prints beside each row. They are decorative and already
   labelled by the text next to them. */
#footer .contact-info-widget i {
  color: rgba(255, 255, 255, 0.35);
  margin-right: var(--s-2);
}

/* The bottom bar: two links and a copyright, one row, wrapping to two on a
   phone rather than colliding. */
#footer-bottom-inner {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  justify-content: space-between;
  gap: var(--s-3);
  padding-top: var(--s-4);
  padding-bottom: var(--s-4);
}

#footer-bottom-menu ul.menu {
  display: flex;
  flex-wrap: wrap;
  gap: var(--s-4);
  list-style: none;
  margin: 0;
  padding: 0;
}

#footer-bottom #copyright {
  font-size: var(--t-xs);
  color: rgba(255, 255, 255, 0.48);
  margin: 0;
}

#footer-bottom-menu a {
  font-size: var(--t-xs);
}