/* Hand-written overrides for this migration.
 *
 * DELIBERATELY OUTSIDE site/public/styles/ (gotcha 49): tools/port-css.mjs owns
 * that directory and clears its own hashed outputs on every run, so a hand-written
 * sheet placed there is deleted by the next port with no error anywhere — on one
 * site that silently removed the sheet that hides the inactive device bands, and
 * all three headers then rendered at every width.
 *
 * Keep this file minimal. Anything that can come from the ported cascade should.
 */

/* The honeypot. Positioned off-screen rather than display:none — bots skip
 * obviously-hidden fields, and taking it out of flow means it costs no layout,
 * which the pixel gate would otherwise measure. */
.mg-hp {
  position: absolute !important;
  left: -9999px !important;
  top: auto !important;
  width: 1px !important;
  height: 1px !important;
  overflow: hidden !important;
}

/* SPECIFICITY NOTE — read before editing any rule below.
 *
 * Duda emits a per-widget rule for EVERY widget on the site, shaped
 *
 *     #dm .dmBody div.u_1213107879 { display: block !important }
 *
 * That is specificity (1,2,1) and it is `!important`. A hide written as a plain
 * `.mg-only-t { display:none !important }` is (0,1,0), so `!important` on both
 * sides means SPECIFICITY decides and Duda's rule wins — the element stays
 * visible and nothing in the console says so.
 *
 * Measured: with the plain selector, /blog rendered all THREE per-device widget
 * copies at once — 30 cards against live's 10, document height 7640px against
 * live's 3548px, and the gate scored 59.4%.
 *
 * So every gate below repeats its class three times behind `#dm`, giving (1,3,0),
 * which outranks (1,2,1) on class count without relying on source order. Do not
 * "tidy" the repetition away.
 */

/* Blog index: THIS SITE DOES HAVE A PAGER, and it withholds most of the posts.
 *
 * Measured on live: /blog declares data-paginate-total-elements="29" and
 * visible-items="10", and renders exactly 10 distinct data-blog-post-alias values.
 * The control is an APPEND-style <a class="more-posts-text-container"> ("Show
 * More"), not a numbered nav — driving it goes 10 -> 20 -> 29, after which the
 * control removes itself. blog.rss independently declares 29 items.
 *
 * A static build has no Duda backend, so all 26 cards ship and the extras are
 * stamped mg-blog-hidden with data-mg-blog-page in live's own batch size;
 * runtime.js reveals them a batch at a time. This rule is what hides them
 * initially, so unlike the port it came from it is NOT a no-op here. */
#dm .mg-blog-hidden.mg-blog-hidden.mg-blog-hidden {
  display: none !important;
}

/* display:none DOES NOT CHANGE CHILD INDICES, so shipping the withheld cards
 * silently moves which card is :last-child.
 *
 * Duda's own rule is `.postArticle:not(:last-child){padding-bottom:Npx}` — this
 * cascade carries it at 100px, 20px and 10px for the three bands. On live the
 * 10th card IS the last child and takes none of it. In our build the 10th card is
 * followed by 19 hidden siblings, so it stops matching :last-child and GAINS that
 * padding, pushing the control and the whole footer down by a constant amount at
 * every width — the signature of one shared element rather than a per-page fault.
 *
 * Keyed on `:has(+ .mg-blog-hidden)` rather than on a stamped class, because that
 * tracks the SEQUENCE as batches are revealed instead of pinning the initial
 * state; runtime.js does not have to re-stamp anything as cards appear.
 *
 * Specificity: Duda's rule is (0,2,1) and not !important, so this (0,4,1) plain
 * rule wins on merit without needing one. */
#dm .postArticle:not(.mg-blog-hidden):has(+ .postArticle.mg-blog-hidden) {
  padding-bottom: 0;
}

/* PER-DEVICE WIDGET FORKS.
 *
 * Duda builds .dmPhotoGallery and .mainBlog client-side and the three device
 * documents genuinely differ, so build-pages.py emits each widget three times and
 * stamps the copies mg-only-d / mg-only-t / mg-only-m. Without these rules ALL
 * THREE render at every width — which is exactly what the first gate run showed:
 * / came back at 77% with a +10458px height delta and /blog at 62% with +10150,
 * both of them simply the same widget painted three times over.
 *
 * The band boundaries are Duda's own, read out of the ported cascade: mobile
 * <=767, tablet 768-1024, desktop >=1025.
 *
 * These hide rather than remove, deliberately — the elements stay in the document
 * so the runtime can still address them, and display:none costs no layout.
 *
 * Only the INACTIVE bands are hidden, inside the media queries. The active band is
 * never touched, so it keeps whatever `display` the ported cascade gives it — an
 * earlier version hid all three and restored one with `display: revert`, which
 * reverts past the author cascade to the UA default and would have replaced the
 * widget's real display value with a plain `block`. */
@media (max-width: 767px) {
  #dm .mg-only-d.mg-only-d.mg-only-d,
  #dm .mg-only-t.mg-only-t.mg-only-t {
    display: none !important;
  }
}

@media (min-width: 768px) and (max-width: 1024px) {
  #dm .mg-only-d.mg-only-d.mg-only-d,
  #dm .mg-only-m.mg-only-m.mg-only-m {
    display: none !important;
  }
}

@media (min-width: 1025px) {
  #dm .mg-only-t.mg-only-t.mg-only-t,
  #dm .mg-only-m.mg-only-m.mg-only-m {
    display: none !important;
  }
}

/* MEDIA-SLIDER FILM ROLE — NO OVERRIDE, and that is the measured answer.
 *
 * An earlier revision added a filmstrip rule here, reasoning from the SERVED html
 * where the film role carries `.gDtRCy` with position:absolute, right:-200%,
 * flex-direction:row and translateX(-0%). That was WRONG, and it is recorded
 * rather than quietly deleted because the reasoning is seductive.
 *
 * The served html is the authority for what the RUNTIME WRITES, but this rule is
 * not something the runtime writes — it belongs to the pre-hydration render. Once
 * the component hydrates it re-renders under a different generated class and the
 * filmstrip rule is simply not applied.
 *
 * MEASURED on live, settled, at 1440:
 *     class="sc-gEvEer jKjUdt"  position:relative  display:block
 *     left:0px  right:0px  transform:none  children:2
 *
 * which is precisely what this build already produced WITHOUT any override. So
 * the correct action here is to add nothing.
 *
 * INHERITED CONTEXT, RETARGETED TWICE NOW. The paragraph that stood here described
 * a slider on a client two migrations back, and the retarget before this one
 * replaced it with a claim about cristosgaragedoors' /reviews page — a page this
 * site does not have. Neither was ever a fact about insulationspecialistusa.net.
 * The general lesson both recorded still holds and is why the block above adds
 * nothing: a slider showing a different photograph than live is usually the CAPTURE
 * landing on a different slide, not a CSS defect, and the remedy is to exclude it
 * from the pixel gate and verify it per element.
 *
 * CENSUSED ON THIS SITE (tools/census-structure.mjs, 159 captures, <style>/<script>
 * stripped first): .flexslider is on 24 of 53 pages, identically on all three bands.
 * There is also exactly ONE .bgGallerySlide, on a single page, and photo galleries
 * on 2. Whether any of them auto-advances is measured BEFORE anything is excluded,
 * and each exclusion is recorded in visual-diff.config.json's hiddenRegions with the
 * measurement behind it — a hidden region gets no pixel coverage at all, so the
 * per-element check is the only coverage it has.
 */

/* ---------------------------------------------------------------------------
 * ACCORDION OPEN STATE — recovering a rule the live CSS read could not see.
 *
 * Duda's FAQ accordion is a styled-component driven by Duda's runtime, which is
 * correctly not ported. The markup and the ported cascade both arrive intact, so
 * the widget PAINTS in its settled state and the pixel gate scores the page
 * 0.000% — while every click is inert. CENSUSED HERE: an accordion (matched on
 * data-grab, not on a class token — styled-components generate their class names,
 * so a class regex finds nothing on these) is present on 30 of 53 pages, identically
 * on all three bands.
 *
 * The state is a generated class on the panel host, and the two names are NOT
 * hardcoded here for the reason gotcha 75 gives: styled-components mint a fresh
 * instance name per render. What IS measured is the mechanism —
 *
 *     closed: .dygwmn { overflow:hidden; transition:max-height .3s ease-out;
 *                       height:auto; max-height:0px; }
 *
 * — so the transition runs on MAX-HEIGHT, and opening means raising it.
 *
 * THE OPEN RULE IS ABSENT FROM THE PORTED CASCADE, and that is not a porting
 * mistake. styled-components insert their rules through the CSSOM, so a class
 * only exists in a document's sheet if that component actually RENDERED with it.
 * No panel is ever open on a freshly loaded page, so `.gnWefg` — the open class
 * live uses — appears in ZERO of the ported sheets while `.dygwmn` appears in 4.
 * Restoring it is recovering a sheet the live read could not reach, which is the
 * same situation gotcha 46 describes for a slider's resting state, arrived at
 * from the opposite direction.
 *
 * Keyed on our own class rather than Duda's generated one so nothing here depends
 * on a name that changes per render. Repeated behind #dm to clear Duda's own
 * per-widget `!important` display rules (gotcha 70).
 *
 * Lives in gm/, NOT in styles/: port-css cleans its own hashed output from that
 * directory on every run and would take this file with it (gotcha 49).
 * ------------------------------------------------------------------------- */
#dm .mg-acc-open.mg-acc-open.mg-acc-open {
  max-height: 2000px;
}

/* ---------------------------------------------------------------------------
   NBC video embed — reproduce the MECHANISM, not the captured number (gotcha 73).

   nbcbayarea's own script sizes this iframe to a fixed 16:9 of its container, and
   it writes the result into the height ATTRIBUTE. Measured on live, all three bands:

       band   height attr   implied container width (h * 16/9)
       d      540           960.00
       t      387           688.00
       m      188.4375      335.00

   all three exact. Our fork is TWO-WAY, so the desktop document also serves the
   768 band — and it carries the DESKTOP capture's 540. Live's runtime re-sizes it
   to 387 at that width; our static markup cannot, so the tablet band rendered the
   video 153px too tall and every element below it moved, scoring 34.975% on
   /about-us/as-seen-on-nbc @768 while 375 and 1440 were 0.199% and 0.005%.

   Hardcoding 387 for the tablet band would be a NEWER frozen value, which is what
   gotcha 73 warns against. The ratio is the actual rule, so it is width-driven and
   correct at every viewport, including between the band edges.
   --------------------------------------------------------------------------- */
iframe[id^="nbcLMP"] {
  aspect-ratio: 16 / 9;
  height: auto !important;
}

/* Search-results summary line under the /blog-search h1. Duda renders live's
 * equivalent as a themed heading; this borrows the page's own heading colour and
 * centring rather than introducing a colour that is not already in the palette. */
#dm .mg-search-summary {
  margin: 8px 0 24px;
  text-align: center;
  font-size: 18px;
  line-height: 1.4;
  color: var(--color_3);
}

/* ---------------------------------------------------------------------------
   PHOTOSWIPE OVERLAY — the two rules the vendored skin cannot supply itself.

   1. POSITION. photoswipe.css ships `.pswp { position: absolute }` and it is the
      library's own JS that promotes it to fixed on open. We do not ship that JS,
      so without this the overlay anchors to the DOCUMENT: measured on /gallery at
      1440, opening thumbnail 3 after scrolling 170px put .pswp at rect.top -170,
      and from further down the page the whole overlay paints above the visitor.
      That is the failure that reads as "clicking the photo does nothing" while
      every class, opacity and size assertion still passes.

      Specificity: the base rule is (0,1,0) and carries no !important, so the
      doubled class (0,2,0) wins on merit.

   2. CENTRING. Real PhotoSwipe positions .pswp__img absolutely and drives it with
      per-slide transforms it computes in JS. With no JS the image would sit at the
      item's top-left corner. .pswp__item is already `position:absolute; inset:0`,
      so auto margins on an inset-0 child centre it in both axes at any viewport.
   --------------------------------------------------------------------------- */
.pswp.pswp {
  position: fixed;
}

.pswp .pswp__item > .mg-pswp-img {
  position: absolute;
  inset: 0;
  margin: auto;
  max-width: 92vw;
  max-height: 84vh;
  width: auto;
  height: auto;
  object-fit: contain;
  cursor: default;
}

/* 3. THE OVERLAY AND ITS BACKDROP ARE TRANSPARENT UNTIL PHOTOSWIPE'S JS RAISES
      THEM, and that is the failure this whole block exists to stop shipping.

      photoswipe.css ships `.pswp__bg { opacity: 0 }` and the library animates it
      to 1 with an INLINE style on open. With no library, the overlay opened
      correctly positioned, correctly sized, with the photo loaded at its natural
      800x600 and every control measuring 44x44 at opacity .75 — and the visitor
      saw the unchanged page, because the backdrop was fully transparent.

      Every geometric assertion passed against it. What caught it was a
      SCREENSHOT: the frame showed the ordinary gallery page while the DOM probe
      reported an open, positioned, populated lightbox.

      (The root's own `opacity: .001` came from `.pswp--animate_opacity`, which is
      PhotoSwipe's pre-animation state and which this runtime no longer adds.) */
.pswp.pswp--open {
  opacity: 1;
}

.pswp.pswp--open .pswp__bg {
  opacity: 1;
}

/* ---------------------------------------------------------------------------
   BODY-TEXT INTERLINKS ON THE PAGES THIS MIGRATION ADDED.

   Scoped to .mg-added so it can only ever touch copy we wrote — never a heading,
   a button, or anything in the header or footer, which carry their own styling.

   The inherited anchor colour here is #777 on #fff, which measures 4.48:1 —
   under the 4.5:1 AA floor for body text — and carries no underline, so the link
   is signalled by a colour difference that does not itself pass. Taking the
   colour from the surrounding copy and adding the underline fixes both: the link
   is legible at the paragraph's own contrast and is identifiable without relying
   on colour at all.
   --------------------------------------------------------------------------- */
#dm .mg-added p a,
#dm .mg-added li a {
  color: var(--color_3);
  text-decoration: underline;
  text-underline-offset: 2px;
}

/* Legal links in the FOOTER sit on the footer's dark ground, and in the CONTACT
   FORM on a light one. A single colour is wrong in one of them, so each is given
   the ink its own background needs rather than inheriting one from the other. */
#dm .mg-legal-links {
  margin: 10px 0 0;
  font-size: 14px;
  line-height: 1.6;
  text-align: center;
}

#dm .mg-legal-links a {
  text-decoration: underline;
  text-underline-offset: 2px;
}

#dm .mg-legal-links--onDark a {
  color: #fff;
}

#dm .mg-legal-links--onLight a,
#dm .mg-legal-links--form a {
  color: var(--color_3);
}

/* THE FORM'S LEGAL LINE MUST CLEAR THE SUBMIT BUTTON AND STAY ON ONE LINE.
 *
 * Duda wraps the submit in `.dmformsubmit.dmWidget.R`, which is FLOATED. A
 * following block therefore flows up ALONGSIDE it rather than under it: measured
 * on /contact at 1440, the legal block's top was 840px against the submit's
 * bottom of 909px — 69px ABOVE the last field, overlapping it — while being the
 * form's last DOM child. `clear: both` is what actually puts it below.
 *
 * It also has to READ as one line. The sentence form wrapped to 2 lines at 1440
 * and 6 lines at 390, which is what makes it look like stray body copy rather
 * than a form footnote. Reduced to the two link labels, which fit one line at
 * every width this site serves. */
#dm form .mg-legal-links {
  clear: both;
  margin: 14px 0 0;
  padding-top: 4px;
  text-align: center;
  font-size: 14px;
  line-height: 1.5;
}

/* Business-name interlink placed in BODY COPY only (Phase 7). Same treatment as
   the added pages' links: the paragraph's own colour plus an underline, so it is
   legible and identifiable without relying on colour alone. Never applied to a
   heading, a button, or header/footer content — those carry their own styling,
   which is why the only occurrence linked on this site is the one that appears
   inside a <p>. */
#dm a.mg-interlink {
  color: var(--color_3);
  text-decoration: underline;
  text-underline-offset: 2px;
}

/* ---------------------------------------------------------------------------
   BLOG PAGER: THE INACTIVE PAGE NUMBERS WERE WHITE ON WHITE.

   Duda's skin sets `.pagination-link { color: inherit }` and styles ONLY the
   active item — `:has(.pagination-link.active)` gives it the dark button pill and
   `--btn-text-color` ink. Every OTHER number therefore inherits the surrounding
   section's colour, which on this site is white, onto a white background.

   MEASURED on /why-do-brakes-squeak-and-how-can-you-fix-it at 1440, and on LIVE
   too — this is inherited, not introduced by the port:

       page 1 (active)  white on rgb(32,32,32)   16.29:1   visible
       page 2           white on white            1.00:1   INVISIBLE
       page 3           white on white            1.00:1   INVISIBLE
       next arrow       white on white            1.00:1   INVISIBLE

   So the visitor sees a single dark "1" and no way to reach pages 2 or 3. The
   ink has to come from the background actually behind the pager, not from the
   inherited section colour: this pager sits on the page's white ground, so it
   takes the body ink. Scoped to :not(.active) so the active pill keeps its own
   white-on-dark treatment, and to :not(.disabled) so the greyed-out arrow stays
   grey and still reads as unavailable.
   --------------------------------------------------------------------------- */
#dm [dmle_extension="internal_blog_list"] .pagination-nav .pagination-list .pagination-item .pagination-link:not(.active):not(.disabled) {
  color: var(--color_3);
}

/* ---------------------------------------------------------------------------
   BLOG POSTS CARRIED TWO H1s — the site name above the article title — on all 22.
   The site name is demoted to h2 so each post has exactly one h1 (its own title).

   RETAGGING A HEADING MOVES THE TYPE, because h1 and h2 are different rules in
   the ported cascade, so the tag change has to be paid for by pinning what the
   h1 actually computed to. Measured on three posts BEFORE the change, at all
   three bands, and every one agreed:

       desktop 1440   40px / 48px   weight 400  Kanit  uppercase  centre  box h=48
       tablet   900   40px / 48px   weight 400  Kanit  uppercase  centre  box h=48
       mobile   390   36px / 43.2px weight 400  Kanit  uppercase  centre  box h=43

   A size class alone is not enough — font-size pins the glyphs but NOT the line
   box, and an unpinned line-height is what silently changes the element's height
   and moves everything below it. Both are pinned, per band, against the same
   767px boundary the rest of this sheet uses.

   Colour is untouched on purpose: it lives on the inner <span>'s inline
   `color: var(--color_3)`, which survives the parent's tag change.
   --------------------------------------------------------------------------- */
/* SPECIFICITY: the rule that actually sizes these is
 * `#dm div.dmContent h2 { font-size: 28px }` at (1,1,2) — one id, one class, two
 * types. A plain `#dm h2.mg-was-h1` is (1,1,1) and LOSES to it on type count. It
 * looked right at 1440 purely by coincidence, because Duda's desktop value for
 * h2 is also 40px; at 390 the heading came out 28px/33.6px against the h1's
 * measured 36px/43.2px, shrinking the box from 43px to 34px. The class is
 * repeated to reach (1,3,1), which is this sheet's existing way of outranking
 * Duda's own selectors without reaching for !important. */
#dm h2.mg-was-h1.mg-was-h1.mg-was-h1 {
  font-size: 40px;
  line-height: 48px;
  font-weight: 400;
  letter-spacing: normal;
  text-transform: uppercase;
  margin: 0;
  padding: 0;
}

@media (max-width: 767px) {
  #dm h2.mg-was-h1.mg-was-h1.mg-was-h1 {
    font-size: 36px;
    line-height: 43.2px;
  }
}

/* ---------------------------------------------------------------------------
   DRAWER SUBMENUS — collapsed by default, caret-driven.

   This site ships them flat and expanded (measured on the <ul> itself: max-height
   `none`, overflow `visible`, 1122px tall at tablet), so opening the menu dropped
   the visitor into a wall of every service page. The house standard is that every
   group starts closed and the caret opens it.

   The height is driven by runtime.js to the panel's measured scrollHeight; this
   only supplies the collapsed frame and the transition. `overflow: hidden` is
   what does the hiding — note that the child <a>s keep their full layout boxes
   inside it, which is why the submenu's own <ul> is the only honest thing to
   measure.
   --------------------------------------------------------------------------- */
#dm .layout-drawer .unifiednav__container_sub-nav {
  overflow: hidden;
  transition: max-height 0.3s ease-out, padding 0.3s ease-out;
}

/* max-height clips the CONTENT box, so the <ul>'s own vertical padding survives
   it: measured, a "collapsed" group still stood 20px tall and showed a sliver of
   the red submenu panel under every parent. Collapsing the padding with it is
   what actually takes the group to zero. */
#dm .layout-drawer li:not(.mg-sub-open) > .unifiednav__container_sub-nav {
  padding-top: 0 !important;
  padding-bottom: 0 !important;
  border-top-width: 0 !important;
  border-bottom-width: 0 !important;
}

/* The caret is a bare inline <span> inside the label's anchor, far too small to
   hit on a phone. This gives it a real tap target and keeps it clear of the
   label, whose click still navigates. */
#dm .layout-drawer .mg-sub-toggle {
  position: relative;
  display: inline-block;
  margin-left: 8px;
  cursor: pointer;
  vertical-align: middle;
}

/* The tap target is an invisible overlay rather than a bigger box. Sizing the
   caret itself to 44px turned this inline <span> into a flex box wide enough to
   wrap, and the carets ended up floating above and to the right of their labels
   instead of sitting next to them. The pseudo-element gives the same 44px touch
   area while the caret keeps its original inline footprint. */
#dm .layout-drawer .mg-sub-toggle::after {
  content: "";
  position: absolute;
  top: 50%;
  left: 50%;
  width: 44px;
  height: 44px;
  transform: translate(-50%, -50%);
}

#dm .layout-drawer .mg-sub-toggle::before {
  transition: transform 0.3s ease-out;
}

#dm .layout-drawer li.mg-sub-open > a .mg-sub-toggle::before {
  transform: rotate(180deg);
}

/* ---------------------------------------------------------------------------
   DESKTOP NAV DROPDOWN — reachable on short laptop screens.

   The Auto Repair Services submenu holds 29 links. Duda lays it out as a
   `column-count: 2` flyout, 642px wide and 695px tall, positioned absolutely
   under a sticky header whose bottom edge sits at 119-131px. At 1440x900 the
   whole thing fits. On the laptop heights this site actually gets it does not,
   and the overflow is UNREACHABLE rather than merely off-screen: it is a HOVER
   menu, so moving the pointer down to chase the missing items closes it, and the
   page cannot be scrolled while it is open.

       viewport     links below the fold   first one lost
       1440x900     0                      —
       1440x800     1                      Collision Center
       1536x720     5                      Car Diagnostics
       1280x700     5                      Car Diagnostics
       1366x640     7                      Car Battery Replacement

   A MAX-HEIGHT ALONE MAKES IT WORSE, and that is the whole reason this is two
   rules. A multi-column box does not scroll in the block direction — it reflows
   into MORE columns. Capping the height at 1366x640 pushed the overflow into a
   third column at x=1148, outside the container's own 642px box, so the links
   painted on bare page background beyond the flyout's edge. Measured: three
   distinct column x-positions (510, 829, 1148) against a box ending at 1142.

   So the cap is paired with dropping to a single column, and only at the heights
   that need it. The two-column flyout needs 695 + 131 + a little margin, so
   above 845px of viewport nothing changes and the menu renders exactly as live.
   Below it, one column plus `overflow-y: auto` makes the remainder reachable by
   scrolling inside the menu.

   CSS only, deliberately: the dropdown opens on :hover with no JS, so its
   scrollability must not depend on any either. `overscroll-behavior: contain`
   stops the wheel chaining to the page once the list bottoms out, which would
   scroll the header out from under the pointer and close the menu.

   Scoped to the desktop band and explicitly NOT to the drawer, which is a
   different menu with its own collapsed-by-default behaviour and already scrolls
   as a whole panel.
   --------------------------------------------------------------------------- */
@media (min-width: 1025px) and (max-height: 845px) {
  #dm .main-navigation .unifiednav__container_sub-nav {
    /* `columns: initial`, NOT `column-count: 1`. Setting the count to 1 still
     * establishes a multi-column formatting context, and a multicol box with a
     * bounded height reflows its overflow into further columns instead of
     * scrolling — measured, that left 19 of the 29 links outside the box with
     * scrollHeight stuck equal to clientHeight (490 = 490). `columns: initial`
     * removes the context altogether: scrollHeight becomes 1325 against a 490
     * client height, nothing outside the box, and the list scrolls. */
    columns: initial;
    max-height: calc(100vh - 150px);
    overflow-y: auto;
    overscroll-behavior: contain;
    scrollbar-width: thin;
    scrollbar-color: rgba(0, 0, 0, 0.35) transparent;
  }

  #dm .main-navigation .unifiednav__container_sub-nav::-webkit-scrollbar {
    width: 8px;
  }

  #dm .main-navigation .unifiednav__container_sub-nav::-webkit-scrollbar-track {
    background: transparent;
  }

  #dm .main-navigation .unifiednav__container_sub-nav::-webkit-scrollbar-thumb {
    background-color: rgba(0, 0, 0, 0.35);
    border-radius: 4px;
  }
}

/* The drawer's own submenus keep the height runtime.js measures for them, at any
   viewport, so nothing above can reach inside the drawer. */
#dm .layout-drawer .unifiednav__container_sub-nav {
  max-height: none;
  overflow-y: hidden;
  column-count: auto;
}