/* ========================================================================== Account sidebar navigation — SHARED COMPONENT Promoted out of `pages/_t24.css` on T25, closing register #53. WHY THIS IS A COMPONENT AND NOT A PAGE RULE. This is the SAME rendered element on every account route, so a per-page fix does not make the design consistent — it makes the inconsistency harder to see. Before this file existed the sidebar was themed on `/customer/account/` and Blank's everywhere else, which meant it changed under the user as they navigated. T25 would have fixed one more route of nine and left the flip in place. The theme has already made this exact correction twice — the filter rail (`_filter-rail.css`) and the column shell (`_layout-columns.css`) were both promoted after a page-scoped version left a sibling route unstyled. THE DENOMINATOR IS TWELVE, AND IT TOOK THREE ATTEMPTS AND THREE METHODS TO GET THERE. TEN (from the nav's hrefs) -> NINE (hrefs minus /wishlist/) -> TWELVE (measured by asking every route whether it RENDERS `.block-collapsible-nav`). Only the third method answers the question the component actually poses. The nine below, plus `/sales/order/invoice/`, `/sales/order/shipment/` and `/sales/order/creditmemo/` - each `items=11 anchors=9 strongs=0` and correctly styled, so the component was always covering more than it claimed. Worth keeping in view: those three extra routes are exactly register #55's - the sales family whose page bodies T25 left unthemed. Had this denominator been enumerated properly the first time, that split would have surfaced a whole task earlier. A wrong denominator is not just a wrong number; it is a set of pages nobody looked at. The nine that this file was written for: /customer/account/ T24 (closed) /customer/address/ T26 /sales/order/history/ T25 (this) /customer/account/edit/ T27 /sales/order/view/ T25 (this) /newsletter/manage/ T27 /downloadable/customer/products/ T28 /review/customer/ T28 /vault/cards/listaction/ T28 AND THE COUNT WAS TEN UNTIL S1 MEASURED IT, THEN NINE UNTIL S8 DID. `/wishlist/` was in that list and does NOT belong: it is `page-layout-1column` with body class `account hrv-page-wishlist wishlist-index-index` and no `.block-collapsible-nav` at all, so it appears in the nav and never displays it. The paragraph claimed loudly to have "enumerated live rather than guessed" - and it did enumerate live, but it enumerated the nav's LINK TARGETS, which is not the set of pages that RENDER the nav. A denominator drawn from hrefs answers "where can you go from here", not "where does this component apply". Eight of the nine measure `items=11 anchors=8 strongs=1 delims=2` byte-identical at 1440 and 375; `/sales/order/view/` differs only as `anchors=9 strongs=0`, because that route is not itself in the nav so no item is `.current`. THE PROMOTION IS WEIGHT-NEUTRAL, WHICH IS NOT LUCK — IT IS WHY `.account` WAS CHOSEN. `.customer-account-index` and `.account` are both a single class, so every moved rule keeps the specificity it was verified at on T24. De-scoping to bare `.block-collapsible-nav` would have dropped a class and silently re-opened the contests T24 spent three review rounds settling. WEIGHTS ARE MEASURED HERE, NOT COUNTED. T24 got its specificity arithmetic wrong three consecutive rounds — including inside the paragraph explaining how to count — so these were bisected live by injecting a candidate rule and watching whether the computed value flipped. The delimiter is the one that matters: Blank owns it at `.block-collapsible-nav .item .delimiter` (0,3,0) in `styles-m.css`, and a rule written at `.block-collapsible-nav .delimiter` (0,2,0) — the obvious shape, and the one a hand count reaches for — measured as a NO-OP. `.item` is load-bearing, not decorative. WHAT BLANK PAINTS HERE, so the fixes below are legible as fixes: .block-collapsible-nav .item > a color: #575757 (off-palette grey) .block-collapsible-nav .item.current > strong border-color: #FF5501 (LUMA ORANGE, which this theme's own `_checkout.css` annotates as NOT A TOKEN) .block-collapsible-nav .item .delimiter border-top: #D1D1D1 (off-palette grey) ========================================================================== */ .account .block-collapsible-nav .content { background: var(--hrv-surface); border: 1px solid var(--hrv-border); border-radius: var(--hrv-radius); padding: 12px; } .account .block-collapsible-nav .item { margin: 0; } /* The current item renders a , not an - measured on T24, where the first version listed both and the anchor half matched nothing. `border-left: 0` is what retires Blank's orange rail. AND THE SENTENCE THAT USED TO FOLLOW WAS UNTRUE: it said "the colour is overridden below as well". No `border-color` declaration exists anywhere in this file. Measured on `.item.current > strong`: widths `0px` on all four sides and styles `none`, but the computed COLOUR is still Luma's `rgb(255,85,1)` on three of them. Inert, so there is no visual defect - a zero-width border paints nothing - but a reader checking "is the orange gone" would find it in the computed styles and reasonably conclude the file was lying. Zeroing the width is the whole mechanism; nothing overrides the colour. */ .account .block-collapsible-nav .item a, .account .block-collapsible-nav .item > strong { display: block; padding: 9px 12px; border-radius: var(--hrv-radius-sm); font-size: 14px; text-decoration: none; border-left: 0; } /* Blank's #575757 on the resting anchors. T24 never needed this rule because its own card and token colours happened to cover the dashboard; on the other nine routes the grey is what actually renders. */ .account .block-collapsible-nav .item > a { color: var(--hrv-text-muted); } /* `.item` IS LOAD-BEARING — see the header. Blank owns this at (0,3,0); dropping `.item` makes the rule a measured no-op, not a weaker win. */ .account .block-collapsible-nav .item .delimiter { border-top-color: var(--hrv-border); } .account .block-collapsible-nav .item.current > strong { background: var(--hrv-accent-tint); font-weight: 700; color: var(--hrv-text); }