/* ==========================================================================
   MOULDSHOP BREADCRUMB — the top band. M4 / TASK-0093.

   THE TARGET IS `.ms-utilitybar`, AND IT TOOK THREE GOES TO ESTABLISH THAT.
   Operator, 2026-09-20: *"do breadcrumb bar as sama as the top ms-utilitybar -
   same heifght and font, and paddiongs"*. The packet said "the info stripe",
   which is a third component; the first build matched that and was wrong.
   See Q-0150. The rule that came out of it: when the authority is a quotation
   or a class name, search for the literal string before anything else.

   MEASURED, at 1440, on /en-us/shop/mouldshop-product-details:

     item             .ms-utilitybar            breadcrumb, before
     ---------------  ------------------------  -----------------------
     band element     .ms-utilitybar (outer)    the nav in the column
     band height      44  (fixed, flex-centre)  60   <- first build; 57 before that
     band padding     0 / 0  and  0 / 0         0 / 0
     content x/width  76 / 1288 (.-inner)       76 / 1288
     text size        13px                      14px  (.875em)
     text line-height 20.8px                    normal
     text family      --ms-font-body (Roboto)   inherited Roboto
     text weight      400                       400

   SO THE DELTA IS TWO THINGS: the band height, and the type.

   THE HORIZONTAL BOX WAS ALREADY RIGHT AND IS NOT TOUCHED. The breadcrumb's
   nav tracks .ms-utilitybar-inner exactly at every width measured --
   1440: 76/1288 . 1300: 110/1080 . 1100: 16/1068 . 390: 16/358 -- because both
   sit on the same container ladder. Nothing below re-states those numbers, so
   the ladder stays the single source of them.

   NOT FULL-BLEED, and that is a structural fact rather than a choice.
   `.ms-utilitybar` paints its background edge to edge and centres its content
   inside. The breadcrumb cannot do the same on both pages: on the product
   detail page its <section> IS full width, but on /en-us/shop the identical
   markup is nested inside the app column and the section is already capped at
   1288. A full-bleed rule would therefore span the viewport on one page and
   not the other. The operator asked for height, font and paddings; none of
   those needs the bleed, so the band is the nav on both pages and the result
   is consistent. Painting it edge to edge is a separate, structural question.

   ── WHY THE ROW PADDING HAS TO GO WITH THE HEIGHT ────────────────────────
   The band measured 57px before this packet: 32 top + 17 content + 8 bottom.
   The 32 and the 8 are `data-dw-row-space-top="4"` / `-bottom="2"` -- a ROW
   SETTING made in admin, not code. Setting a band height and leaving them
   gives 0 + 44 + 40 = 84px, not 44. The row is therefore flattened for
   breadcrumb rows ONLY, matched on what the row contains rather than on a
   page or an id, so it holds wherever a breadcrumb is placed and nowhere else.

   A ROW SETTING OVERRIDDEN FROM CSS IS A REAL COST and it is named here: an
   operator who changes Row spacing on a breadcrumb row will see nothing
   happen. Deliberate, not an oversight -- and filed as Q-0148 so it is a
   decision rather than a discovery. Reverting this one block restores admin
   control and nothing else regresses.

   ── 44px IS THE UTILITY BAR'S NUMBER, COPIED, NOT SHARED ─────────────────
   `--ms-utilitybar-h` is declared on :root in mouldshop.css, so it IS
   reachable from here -- but reading it would silently couple the breadcrumb
   to a chrome token that another packet may move for reasons that have
   nothing to do with breadcrumbs. The value is restated once below, and
   `scripts/verify/breadcrumb.mjs` asserts the two bands are the same height
   ON THE SAME PAGE. The utility bar is site chrome, so that comparison runs
   against the real thing on every page tested rather than against a number.
   If either moves, the check fails instead of the two drifting apart.
   ========================================================================== */

:root {
  /* .ms-utilitybar computed height, measured at 1440, 1300, 1100 and 390 --
     44px at all four. Kept honest by the equality assertion in the verify. */
  --ms-breadcrumb-bar-height: 44px;

  /* .ms-utilitybar fill and rule. The bar hardcodes #efefef in mouldshop.css;
     its border uses --ms-grey-20. Restated here for the same reason as the
     height -- a copy that the verify keeps honest, not a silent coupling. */
  --ms-breadcrumb-bar-bg: #efefef;
  --ms-breadcrumb-bar-rule: var(--ms-grey-20, #E4E7EC);

  /* .ms-util-link computed type, same four widths. */
  --ms-breadcrumb-font-size: 13px;
  --ms-breadcrumb-line-height: 20.8px;

  /* Bootstrap ships 1rem for the node gap and the vendor breadcrumb template
     repeats it inline. 40% off 16px is 9.6px, which is 0.6rem. Not rounded to
     10px: the packet asks for the arithmetic, not a tidier number. */
  --ms-breadcrumb-node-padding-x: 0.6rem;
}

/* --------------------------------------------------------------------------
   1. THE ROW STOPS ADDING HEIGHT.

   `:has()` and not a page selector: the rule has to follow the breadcrumb
   wherever it is placed, and the breadcrumb sits at different depths on the
   Shop page (inside the app column) and on the product detail page (directly
   under main). The child combinators keep it to the row that OWNS the
   breadcrumb -- an ancestor row further up is not flattened.
   -------------------------------------------------------------------------- */
section[data-swift-gridrow]:has(
    > [data-swift-container]
    > [data-swift-gridcolumn][data-dw-itemtype="swift-v2_breadcrumbnavigation"]
  ) {
  padding-block: 0;
}

/* --------------------------------------------------------------------------
   1b. THE BAND IS FILLED, like the utility bar.

   Operator, 2026-09-20: the band read as a gap rather than a bar because it had
   no background at all. `.ms-utilitybar` carries `background: #efefef` and
   `border-bottom: 1px solid var(--ms-grey-20)`; both are taken here.

   ON THE ROW, NOT THE NAV, so the fill reaches the same edges the utility bar's
   does. On the product detail page that row spans the viewport and the bar goes
   edge to edge; on /en-us/shop the identical markup is nested inside the app
   column, so it stops at the content width. That is the same shape a colour
   scheme paints on this row, so the two routes agree rather than disagree.

   SCOPED TO ROWS WITH NO SCHEME SET, so this is a DEFAULT and not an override.
   Set a Color scheme on the row and DW's own background wins; clear it and the
   band falls back to the utility bar's grey. That keeps the per-page control
   the operator asked for instead of replacing it with a hardcoded colour.
   -------------------------------------------------------------------------- */
section[data-swift-gridrow]:not([data-dw-colorscheme]):has(
    > [data-swift-container]
    > [data-swift-gridcolumn][data-dw-itemtype="swift-v2_breadcrumbnavigation"]
  ),
section[data-swift-gridrow][data-dw-colorscheme=""]:has(
    > [data-swift-container]
    > [data-swift-gridcolumn][data-dw-itemtype="swift-v2_breadcrumbnavigation"]
  ) {
  background-color: var(--ms-breadcrumb-bar-bg);
  border-bottom: 1px solid var(--ms-breadcrumb-bar-rule);
}

/* --------------------------------------------------------------------------
   2. THE BAND TAKES THE UTILITY BAR'S HEIGHT AND PADDINGS.

   The same three declarations .ms-utilitybar uses, for the same reason: a
   fixed band height with the content centred in it, and no padding of its own.
   -------------------------------------------------------------------------- */
[data-swift-gridcolumn][data-dw-itemtype="swift-v2_breadcrumbnavigation"] > nav {
  display: flex;
  align-items: center;
  min-height: var(--ms-breadcrumb-bar-height);
  padding-block: 0;
  padding-inline: 0;
}

/* --------------------------------------------------------------------------
   3. THE TYPE MATCHES .ms-util-link.

   13px / 20.8px / Roboto / 400. Bootstrap sets the breadcrumb's size through
   `--bs-breadcrumb-font-size: .875em`, written INLINE by the vendor template,
   so the variable is overridden rather than the `font-size` -- the same route
   as the node spacing below, and it keeps the em-relative behaviour Bootstrap
   expects instead of fighting it with a second declaration.

   COLOUR IS DELIBERATELY NOT SET HERE. The packet's item 4 is explicit that
   this pass changes no colour, and the breadcrumb's LINKS are already
   #0A2979 -- the utility bar's navy -- so they match already. What does not
   match is the last (active) node and the ">" divider, both Bootstrap's
   rgba(33,37,41,.75). Making those navy is one line and is NOT taken
   unilaterally; it is reported for the operator to call.
   -------------------------------------------------------------------------- */
.breadcrumb.menu_breadcrumb {
  --bs-breadcrumb-font-size: var(--ms-breadcrumb-font-size) !important;
  font-family: var(--ms-font-body);
  font-weight: 400;
  line-height: var(--ms-breadcrumb-line-height);
}

/* --------------------------------------------------------------------------
   4. NODE SPACING, 40% OFF -- AND IT IS TWO PROPERTIES, NOT ONE.

   Bootstrap spends this one custom property twice per gap:
     .breadcrumb-item + .breadcrumb-item   padding-left  : var(--bs-...-x)
     .breadcrumb-item::before              padding-right : var(--bs-...-x)
   Measured on the product detail page: 16px and 16px, 32px of gap around the
   ">" glyph. Cutting only one of them would have been a 20% cut, which is the
   trap the packet names. Overriding the VARIABLE moves both at once.

   `!important` IS REQUIRED AND IS NOT A SHORTCUT. Swift-v2_BreadcrumbNavigation
   /Plain.cshtml writes `--bs-breadcrumb-item-padding-x: 1rem` in a `style`
   attribute on the <ol>. That is a vendor file, so it is not edited (DEC-0037),
   and an author rule without `!important` loses to an inline declaration.

   16px -> 9.6px per property; 32px -> 19.2px per gap.
   -------------------------------------------------------------------------- */
.breadcrumb.menu_breadcrumb {
  --bs-breadcrumb-item-padding-x: var(--ms-breadcrumb-node-padding-x) !important;
}

/* --------------------------------------------------------------------------
   5. THE COLOUR SCHEME REACHES THE BREADCRUMB.

   The route already exists and is the one every other band on this site uses:
   the ROW carries `data-dw-colorscheme`, set per row in admin, and each page
   owns its own breadcrumb row -- so it is per page by construction. What was
   missing is that the breadcrumb did not LISTEN. Measured before this block:
   flipping the row through all six schemes repainted the section background
   and moved `--dw-color-foreground`, and the breadcrumb's link, active item
   and ">" divider did not move at all. Bootstrap's own values won.

   THIS BLOCK CHANGES NO COLOUR TODAY, by construction. It is scoped to a row
   that has a scheme EXPLICITLY set and not to `default`, and no breadcrumb row
   on this box has one -- both read `data-dw-colorscheme=""`. Set one in admin
   and the breadcrumb follows; leave it alone and the resting appearance is
   byte-for-byte what it was, which is what the packet asks for.

   `default` is excluded deliberately: `default` IS the current appearance, so
   selecting it must be a no-op rather than a third look.
   -------------------------------------------------------------------------- */
[data-dw-colorscheme]:not([data-dw-colorscheme=""]):not([data-dw-colorscheme="default"])
  [data-swift-gridcolumn][data-dw-itemtype="swift-v2_breadcrumbnavigation"]
  .breadcrumb.menu_breadcrumb {
  --bs-breadcrumb-divider-color: var(--dw-color-foreground);
  --bs-breadcrumb-item-active-color: var(--dw-color-foreground);
  color: var(--dw-color-foreground);
}

[data-dw-colorscheme]:not([data-dw-colorscheme=""]):not([data-dw-colorscheme="default"])
  [data-swift-gridcolumn][data-dw-itemtype="swift-v2_breadcrumbnavigation"]
  .breadcrumb.menu_breadcrumb a {
  color: inherit;
}