/* ---------------------------------------------------------
GLOBAL VARIABLES
--------------------------------------------------------- */
:root {
}
/* ---------------------------------------------------------
GLOBAL RESET / BASE
--------------------------------------------------------- */
html, body, form {
height: 100%;
margin: 0;
padding: 0;
background: var(--bg);
font-family: 'Inter', sans-serif;
color: var(--ink);
}
/* Left nav disabled: never reserve left-nav space */
body.ln-disabled {
--layout-leftnav-col: 0px
}
/* Left nav enabled: open reserves full width */
body.ln-enabled.show-lnav {
--layout-leftnav-col: var(--leftnav-width);
}
/* Left nav enabled, closed + reclaim collapses column to collapsed width */
body.ln-enabled.close-lnav.ln-reclaim {
--layout-leftnav-col: var(--leftnav-collapsed-width);
}
/* Left nav enabled, closed + preserve keeps the width */
body.ln-enabled.close-lnav:not(.ln-reclaim) {
--layout-leftnav-col: var(--leftnav-width);
}
/* Left nav: during closing with reclaim, collapse DURING animation */
body.ln-enabled.ln-reclaim.ln-closing {
--layout-leftnav-col: var(--leftnav-collapsed-width);
}
/* CBS-34 2026-09-19: --layout-rail-col-static is what the APPBAR and the FOOTER use.
*
* It holds the column the rail occupies when CLOSED, in every rail state, so opening the
* rail moves the content track and nothing else. The three rules below are deliberately
* state-independent - no show-rail, no close-rail - which is the whole point: they cannot
* change when the rail opens. Each sits beside the --layout-rail-col rule it mirrors so the
* pair cannot drift apart unnoticed. cbs.css adds the fourth, for the 48px strip.
*
* Why the appbar and footer need this at all: .appbar-right and .footer-right are EMPTY
* spacer divs (Site.master:175 and :280) - the logo, the menu, the user chip and the footer
* content all live in the centre region. So the rail track in those two grids holds nothing
* and its only effect was to squeeze the centre when the rail opened, which is exactly what
* the developer saw: at 1920 on Commission Plans the appbar centre went from 280/1600 to
* 280/1368 on opening the rail. Using the closed value keeps the appbar and footer
* pixel-identical to the closed-state body - which is the CBS-24 alignment - and immune to
* the rail. */
/* Disabled pages: never reserve rail space */
body.rr-disabled {
--layout-rail-col: 0px;
--layout-rail-col-static: 0px;
}
/* Reclaim pages give the column back when closed, so closed is 0 whatever the state is now. */
body.rr-enabled.rr-reclaim {
--layout-rail-col-static: 0px;
}
/* Preserve pages keep the width when closed, so the static column is the full width. */
body.rr-enabled:not(.rr-reclaim) {
--layout-rail-col-static: var(--rail-width);
}
/* Enabled pages: when open, reserve full rail width */
body.rr-enabled.show-rail {
--layout-rail-col: var(--rail-width);
}
/* Enabled pages: when closed AND reclaim is on, collapse the column */
body.rr-enabled.close-rail.rr-reclaim {
--layout-rail-col: 0px;
}
/* Enabled pages: when closed AND preserve is desired, keep the width */
body.rr-enabled.close-rail:not(.rr-reclaim) {
--layout-rail-col: var(--rail-width);
}
/* RR: while closing with reclaim, collapse the rail column DURING the animation */
body.rr-enabled.rr-reclaim.rr-closing {
--layout-rail-col: 0px;
}
/* Header right group vs the right rail: ONE mechanism, JavaScript/appbarAlign.js. It MEASURES the rail card and writes
--appbar-rr-ext and --appbar-rr-w on .user-panel (both 0 when the rail is collapsed or under 1101px); the rule on
.appbar-center-grid > .user-panel below and the bell-room rule in updates.css read them. The old arithmetic
(--appbar-rr-shift, --appbar-rr-minw, --rr-header-slot) is gone: it was reasoned from variables and was off on TEST. */
/* ---------------------------------------------------------
APP SHELL (HEADER / BODY / FOOTER)
--------------------------------------------------------- */
.layout {
height: 100vh; /* 🚨 min-height is NOT sufficient */
/* iOS Safari: 100vh is the viewport with the address bar collapsed, so the layout was taller than what is visible and
.layout-body (overflow: hidden) cut the bottom of every page off behind the toolbar: the Passkeys card on Preferences
could not be scrolled to. 100dvh follows the bar. Browsers without dvh keep the 100vh above. */
height: 100dvh;
display: flex;
flex-direction: column;
background: var(--bg);
min-height: 0; /* allow children to shrink */
}
/* ---------------------------------------------------------
APP BAR (HEADER)
--------------------------------------------------------- */
.appbar-left {
grid-column: 2;
}
.appbar-center {
grid-column: 3;
display: block;
}
/* TL-71 2026-09-20: the chrome does NOT follow the content width any more.
*
* The appbar and footer used to cap their centre region at --content-max-width, so they changed
* shape with the page: 1600 on a grid-wide page, 1000 on a page that sets no body class, 620 on
* a page-narrow one. Two consequences, both wrong. The chrome visibly jumped inward when a user
* opened a sparse page - Security/Entity, QuickBooksOnline and the others that take the 1000px
* default - and the menu's track shrank with it: measured at 1920, the track is 1174 on a
* grid-wide page, 574 on a default page and 194 on a narrow one, against an Administrator menu
* that needs 914. That is why the same menu fits on one page and collides on the next.
*
* The developer's decision: the appbar and footer are app chrome, identical on every page. The
* narrow content column belongs to the page, not to the shell.
*
* The consequence to know about: on a grid-wide page the appbar centre is now slightly wider
* than the content column - the shell gutters rather than the content cap decide it - so the
* logo and the user chip no longer sit exactly on the content's edges. CBS-24 and CBS-34 were
* about the chrome not COLLAPSING and not moving when the rail opens, and both still hold. */
.appbar-center,
.footer-center {
width: 100%;
margin: 0;
box-sizing: border-box;
}
.appbar-right {
grid-column: 4;
}
.appbar-center-grid {
display: grid;
/* TL-71: the menu's own track follows the appbar, not the page. Capping it at
--content-max-width here would have undone the full-width change one level down - on a
page that takes the 1000px default the menu would still have been squeezed to 574. */
grid-template-columns: auto minmax(0, 1fr) auto;
align-items: center;
height: var(--appbar-height);
/* Designer 2026-10-14: with the bell outside the chip, the logo's left edge and the bell's right edge line up with the main content
cards at 32px; this also keeps the bar stable when the right cluster changes width. */
margin-right: 32px;
margin-left: 32px;
}
/* TL-72: every child is placed EXPLICITLY.
*
* This grid had three columns and three children, so auto-placement happened to be right.
* TL-70 added the hamburger as a fourth child and auto-placement did what it is supposed to:
* it wrapped the fourth item onto a second row - which is how the user chip ended up beneath
* the logo instead of at the right of the appbar, and why its flyout, which is anchored to a
* right-hand chip, opened off screen. Explicit columns cannot wrap, and a display: none item
* is not placed at all, so the hamburger simply takes no column above the breakpoint. */
.appbar-center-grid > .brand-logo {
grid-column: 1;
}
.appbar-center-grid > .appbar-user-container {
grid-column: 2;
}
.appbar-center-grid > .user-panel {
grid-column: 3;
justify-self: end;
/* Header right group follows the right rail (2026-10-14). Collapsed: both values are 0 and the group sits
* at the right edge of the content cards (the 32px margin on the grid). Expanded: appbarAlign.js has
* measured the rail card, so the group's right edge moves out by --appbar-rr-ext to the card's right
* edge and the chip is held at least the card's width less the bell's room (updates.css), which puts
* the chip's left edge on the card's left edge. No transition here: the script eases the values
* itself, at the rail's own duration, so the header moves with the rail. */
box-sizing: border-box;
margin-right: calc(-1 * var(--appbar-rr-ext, 0px));
min-width: var(--appbar-rr-w, 0px);
}
.appbar-center-grid #menuMain {
float: none !important;
display: flex !important;
}
.brand-logo img {
height: 40px;
width: auto;
}
/* Narrow widths: the logo, the chip (initials only from 640, nav.css) and the bell never touch.
*
* At 320 the centre track is only what is left between the 16px gutters, the 56px nav icon rail and, on a page
* that keeps the closed right-rail column in the appbar (CBS Invoices' 48px strip), that column - and the 32px
* margins take 64 of it, which is less than the logo (119), the avatar chip (58) and the bell's room (37) need
* (measured in docs/design/harness/apprail.html: the chip overlapped the logo by 38px at 320). Three things give
* it back, neither at desktop widths:
* - up to 640 the centre spans the (empty) right column as well, so the strip's width is usable;
* - the grid's side margins are 16, not 32 (the desktop 32 is the content cards' margin; at this width the
* cards themselves are edge to edge).
* Measured after: gap between logo and chip 41px at 320, 81 at 360, 111 at 390, 201 at 480.
*/
@media (max-width: 640px) {
.appbar-center {
grid-column: 3 / -2;
}
.appbar-center-grid {
margin-left: 16px;
margin-right: 16px;
}
}
/* Smooth rail/leftnav column changes */
.appbar-inner,
.layout-body,
.footer-inner {
transition: grid-template-columns var(--rails-collapse-expand-time) ease;
}
.appbar-inner {
display: grid;
/*grid-template-columns: 1fr var(--layout-leftnav-col) minmax(0, var(--content-max-width)) var(--layout-rail-col) 1fr;*/
/* TL-71: full width. The centre track takes everything between the gutters instead of
being capped at the page-s content width, and the gutters are fixed rather than flexible
so they cannot grow and pull the chrome inward. */
grid-template-columns: var(--shell-gutter) var(--layout-leftnav-col) minmax(0, 1fr) var(--layout-rail-col-static) var(--shell-gutter);
width: 100%;
height: var(--appbar-height);
box-sizing: border-box;
}
/* ---------------------------------------------------------
MAIN LAYOUT BODY (SCROLL PARTICIPANT)
--------------------------------------------------------- */
.layout-body {
flex: 1; /* ✅ take remaining vertical space */
min-height: 0; /* ✅ ALLOW SCROLL CONTAINERS */
display: grid;
/*grid-template-columns: 1fr var(--layout-leftnav-col) minmax(0, var(--content-max-width)) var(--layout-rail-col) 1fr;*/
/* TL-71 2026-09-20: the LEFT gutter is fixed, like the appbar's and the footer's.
*
* It used to be minmax(--shell-gutter, 1fr), and so did the appbar's, and both grids had the
* same capped content track - so the two flexible gutters always computed to the same value
* and everything lined up by coincidence of symmetry. Making the chrome full width broke
* that coincidence: the appbar's gutter became a fixed 16 while this one still grew to
* absorb the slack left by a narrow content column, so on a 1000px page at 1920 the left nav
* started at x=340 while the logo started at x=256 - the nav sitting well to the right of
* the logo, which is what the developer photographed.
*
* With this gutter fixed too, all three grids start their left-nav column at the same x, so
* the nav, the logo and the content column share one left edge on every page type.
*
* The CONTENT track keeps its cap. That is the difference between this grid and the chrome:
* the narrow column belongs to the page, so a sparse page still gets a narrow content column
* - the slack now falls on the RIGHT, in the last track, instead of being split evenly and
* pulling the whole page inward. */
grid-template-columns: var(--shell-gutter) var(--layout-leftnav-col) minmax(0, 1fr) var(--layout-rail-col) var(--shell-gutter);
box-sizing: border-box;
overflow: hidden;
}
/* ---------------------------------------------------------
LEFT NAV
--------------------------------------------------------- */
.left-rail {
grid-column: 2;
position: sticky;
top: 0;
width: var(--layout-leftnav-col);
min-width: var(--layout-leftnav-col);
background: var(--bg);
border-right: 1px solid var(--border);
box-shadow: 1px 0 0 rgba(var(--shadow-rgb), 0.02);
display: flex;
flex-direction: column;
box-sizing: border-box;
padding-top: var(--page-vertical-gap);
padding-bottom: var(--page-vertical-gap);
max-height: calc(100vh - var(--header-footer-total));
max-height: calc(100dvh - var(--header-footer-total));
min-height: 0;
opacity: 1;
pointer-events: auto;
transform: none;
transition: width var(--rails-collapse-expand-time) ease, min-width var(--rails-collapse-expand-time) ease;
}
/* Left nav container: search stays visible; menu list scrolls */
.left-nav {
width: 100%;
padding: 0px 16px 0px 16px;
/* critical: allow inner scroll region to size correctly */
display: flex;
flex-direction: column;
min-height: 0;
/* prevent the entire aside from scrolling */
overflow: hidden;
flex: 1;
box-sizing: border-box;
background: var(--bg);
transition: opacity var(--rails-collapse-expand-time) ease, transform var(--rails-collapse-expand-time) ease;
will-change: opacity, transform;
opacity: 0;
pointer-events: none;
transform: translateX(-20px);
}
/* =================================================================================================
TL-114: THE LINK IN THE FLEX CHAIN THAT WAS MISSING, AND WHY THE NAV CLIPPED INSTEAD OF SCROLLING.
The rules here were written for this DOM:
.left-rail max-height: calc(100vh - var(--header-footer-total)), flex column
.left-nav flex: 1, flex column, min-height: 0, overflow: hidden
.left-nav-search flex: 0 0 auto <- pinned
.AspNet-TreeView flex: 1 1 auto, min-height: 0, overflow-y: auto <- scroll owner
THE REAL DOM HAS AN asp:Panel BETWEEN .left-nav AND THOSE TWO. The selectors below are descendant
selectors, so they still MATCHED - but flex: 1 1 auto on an element that is not a flex item does
nothing at all. The panel sized itself to its content, .left-nav's overflow: hidden clipped the
excess, and the tree's overflow-y: auto never had a bounded height to scroll within. The bottom
of a long menu was therefore unreachable rather than scrollable, which is exactly the report:
the appended Support, Help centre, Contact support and Logout nodes go last and are what a
clipped nav hides first.
THIS IS WHY IT LOOKED LIKE THE CSS WAS ALREADY CORRECT. Every rule was right and the chain was
broken by markup none of them mentioned.
This is also the reason TL-116 could not be built alone: showing every top-level node makes the
menu taller, so without this it would have pushed more items out of reach. */
.left-nav-panel {
display: flex;
flex-direction: column;
flex: 1 1 auto;
min-height: 0;
}
/* Search box area stays pinned (not sticky—just outside the scroll owner) */
.left-nav-search {
flex: 0 0 auto;
margin-bottom: 16px;
background: var(--bg);
}
.left-nav-search input[type="search"] {
width: 100%;
height: 32px;
padding: 0 8px;
border-radius: 6px;
border: 1px solid var(--border-strong);
box-sizing: border-box;
box-shadow: 0 1px 0 rgba(var(--shadow-rgb), 0.03);
}
/* TL-115: the row the user actually searched for. The search opens every ancestor of a match, so
without this the match is simply one more row in a newly opened tree - and a search matching
several branches gives no clue which rows were the hits. Applied to the li, so it marks the node
itself rather than the whole branch. */
/* TL-150: THE MATCH HIGHLIGHT REACHES SPANS AS WELL AS ANCHORS - WHICH IS WHY SEARCHING "fleet"
CAME BACK HALF INDIGO AND HALF BLACK.
This selector was `> a` only. TL-138 made a node with children and no Url of its own render as
.AspNet-TreeView-ClickableNonLink - a SPAN, not an anchor - so a matched GROUP node got the
nav-search-match class on its li but no colour from this rule, and kept the ordinary ink colour.
A matched LEAF, which is a real anchor, went brand-primary. Two colours in one result set, and
nothing to do with visited-link state.
THIS IS THE FOURTH TIME `> a` ALONE HAS BEEN WRONG in this nav, after the top-level emphasis
rule, the collapsed-rail centring rule and the icon colour. The adapter renders a label as an
anchor OR one of two span classes depending on the node, so any rule that styles a nav label must
list all three. */
/* TL-168 2026-09-30: THE COLOUR IS GONE. The developer rejected colouring search results outright -
no colour changes for search results at all. WEIGHT ONLY, which still marks the row the user was
looking for without introducing a second meaning for the brand colour inside the nav.
The three-selector list stays, and must: the adapter renders a label as an anchor or as one of two
span classes, so a rule listing only `> a` reaches some matches and not others. That was TL-150,
and it is the reason a search came back half indigo and half black. Removing the colour does not
remove that requirement - it would come straight back the next time anything styles a match. */
.left-nav li.nav-search-match > a,
.left-nav li.nav-search-match > .AspNet-TreeView-ClickableNonLink,
.left-nav li.nav-search-match > .AspNet-TreeView-NonLink {
font-weight: 600;
}
/* TL-168 2026-09-30: THE nav-search-match-desc RULE IS DELETED, not kept dormant.
It styled a description match in italic muted text. The developer rejected that idea in place:
people would never learn what the italic meant, so it communicated nothing and cost a second
visual language inside the nav. The "Also mentions ..." section is the direction that survives,
because it SAYS why those entries appeared instead of hinting at it with a style.
The class was already unapplied since TL-153 moved description matches out of the tree. Keeping
a rule for a class nothing sets is how a dead style gets reinstated by accident later, so it is
removed rather than left behind a comment. */
/* =================================================================================================
TL-153: THE "Also mentions ..." SECTION. Description matches live here rather than in the tree,
because a tree cannot be re-sorted without destroying the hierarchy that gives node positions
their meaning - see the note in site.core.js.
Styled as clearly secondary to the tree above it: a muted heading carrying the query, then each
item with its path underneath so the user can see where it sits without the tree having to move.
================================================================================================= */
/* TL-176: BOUNDED, AND WITH ITS OWN SCROLL.
flex-shrink is 1 and there is a ceiling, because the failure this guards against is the mirror of
the one above: a query matching many descriptions would make this list tall enough to take the
space the menu needs, and with flex: 0 0 auto it would have won outright. 40% leaves the majority
of the rail to the menu, which is the primary thing; the list scrolls inside whatever it gets.
It stays AFTER the tree in the flex order rather than being positioned, so the menu pushes it down
naturally and neither element needs to know the other's height. */
.nav-search-also {
flex: 0 1 auto;
max-height: 40%;
overflow-y: auto;
margin-top: 10px;
padding-top: 8px;
border-top: 1px solid var(--border);
}
.nav-search-also-heading {
font-size: 12px;
font-weight: 600;
color: var(--muted);
margin-bottom: 6px;
}
.nav-search-also-item {
margin: 0 0 8px 0;
line-height: 1.25;
}
.nav-search-also-item > a,
.nav-search-also-item > span {
font-size: 13px;
font-weight: 500;
color: var(--ink);
text-decoration: none;
}
.nav-search-also-item > a:hover {
color: var(--brand-ink);
font-weight: 600;
}
.nav-search-also-path {
font-size: 11px;
color: var(--muted);
}
/* The section is text, not icons - it has no place in the 56px rail. */
body.close-lnav .nav-search-also {
display: none;
}
/* =================================================================================================
TL-140: ROOT NAV ICONS, AND THE COLLAPSED ICON RAIL THEY EXIST FOR.
Ten roots only, never the 188 nodes below them. The markup is added server side by
MT.Utils.ApplyRootNavIcon, which emits
Title
into the root node's Text. The label span is not decoration: it is what the collapsed rail
hides, and without it the title is a bare text node that cannot be hidden separately.
THE MASK IS WHY THE BRAND MARK IS NOT RED. Every icon here follows the pattern already used by
.ph--clock in ucKPIDetailDrawer.css: the SVG is a MASK and the colour comes from
background-color: currentColor. A mask uses only the alpha channel, so the fills inside the
source SVG are discarded entirely. The Franchisees mark therefore picks up the nav's own colour
with no edited copy of the artwork and no chance of the Jiffy Lube red leaking into the rail -
the requirement is satisfied by construction rather than by remembering to change a fill.
THE FRANCHISEES ARTWORK is the same geometry as brandStoreIcon in CBS/CBSInvoices.aspx.cs. Its
reasoning, recorded because it is not obvious: CBS users see Franchisees and run reports about
franchisees, so the brand mark fits and avoids inventing a second "reports" icon. That icon is
defined inline in the code-behind rather than as a file so the brand can be swapped if future
versions support brands other than Jiffy Lube - if that happens, this copy needs swapping too.
BILLING AND CBS INVOICES CURRENTLY SHARE A SHAPE. Accounts and Account sharing one is safe -
they are shown to different roles and never appear together - but Billing and CBS Invoices CAN
both be visible to a CBS user, and two identical icons in a ten-item rail is where an icon stops
helping. Flagged to the developer; built as specified pending his call.
================================================================================================= */
/* TL-140: THE ROOT ICON'S OWN APPEARANCE, MATCHING .left-nav-toggle's MECHANISM EXACTLY.
That control (controls.css:992) is the reference the developer named: it sets
color: var(--brand-ink) with opacity .6 and transition: opacity .25s ease, and lifts on
hover with transform: translateY(-1px) and opacity 1. The same three ideas are here - dim
brand-primary at rest, full opacity plus the lift on hover.
EVERY ICON IS AN INLINE