/* The navbar: the bar, its icon buttons, and the menu that opens from it.
 *
 * IN A FILE OF ITS OWN because the pages that show this button do not agree on
 * their stylesheets. The signed-in application loads styles.css; the login, MFA,
 * patient and public pages do not -- they load palette.css plus one page
 * stylesheet, and adding the whole application sheet to them would restyle
 * layouts built without it.
 *
 * The consequence of getting that wrong is visible: when these buttons were
 * pointed at .navbar-icon-btn while the rule still lived in styles.css, the
 * staff login page picked it up and every other page rendered a default browser
 * button instead -- so the menu visibly jumped position and changed shape
 * between the login page and the two-factor page.
 *
 * One source of truth, linked by everything that draws the button.
 */

/* The bar the button sits in. Only the two properties that decide where the
   button lands -- height, and the ground it is drawn against.
 *
 * Deliberately NOT position or z-index. styles.css sets those for the signed-in
 * application, and the pages linking this file have their own arrangements;
 * copying them here would silently change layout on ten pages that cannot be
 * checked without a browser. Height and background are enough to stop the menu
 * jumping between the login page (which loads styles.css) and the two-factor
 * page (which does not), which is the fault this fixes. */
/* A navbar marked fixed-top must actually BE fixed.
 *
 * styles.css sets .navbar { position: relative } for the signed-in application,
 * and it loads after Bootstrap, so it beat .fixed-top { position: fixed } on
 * every page that loads both. On a RELATIVE element `top` offsets from the
 * element's flow position rather than the viewport -- and the banner rule sets
 * `top: <banner height>` while body already carries `padding-top: <banner
 * height>`, so the banner was counted twice and the bar sat that much too low.
 *
 * It only showed on some pages, which is what made it look random: the staff
 * login page loads styles.css and sank, the two-factor page does not and sat
 * correctly. Same markup, different stylesheets.
 *
 * Scoped to .fixed-top, so the application's own navbar -- which is deliberately
 * `class="navbar"` with no fixed-top and belongs in the flow -- is untouched. */
.navbar.fixed-top {
    position: fixed;
}

.navbar {
    --bs-navbar-padding-y: 0.375rem;
    background-color: var(--surgerly-primary);
    border-bottom: none;
    height: 3rem;
    min-height: 3rem;
    max-height: 3rem;
}

.navbar-icon-btn {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    width: 2.75rem;
    height: 100%;
    padding: 0;
    border: none;
    background: transparent;
    /* White works because every palette so far has a DARK primary behind the
       navbar (Signature's is #222222). It is a token so a licensee whose
       primary is light -- the stock Surgerly gold #be9b5a gives white about
       2:1, which is not readable -- can override it in their branding rather
       than needing a code change. Default is unchanged. */
    color: var(--surgerly-navbar-fg, rgba(255, 255, 255, 0.9));
    /* Rounded, not a full-height square. The square read as a grey block
       stuck to the corner of the bar -- fine in a dense toolbar, wrong on a
       login page where it is the only control. */
    border-radius: 0.5rem;
    cursor: pointer;
    line-height: 0;
    transition: background-color 0.15s ease, color 0.15s ease;
}
.navbar-icon-btn:hover,
.navbar-icon-btn:focus-visible {
    background-color: rgba(255, 255, 255, 0.10);
    color: var(--surgerly-navbar-fg-hover, #ffffff);
    outline: none;
}
/* While the menu is OPEN, brighten the icon rather than leaving a filled box
   sitting there for as long as the panel is up. */
.navbar-icon-btn[aria-expanded="true"] {
    background-color: transparent;
    color: var(--surgerly-navbar-fg-hover, #ffffff);
}
.navbar-icon-btn .material-symbols-outlined {
    display: block;
    font-size: 1.35rem;
    line-height: 1;
}

/* ── the menu must draw ABOVE the bar that opens it ──────────────────────────
 *
 * The navbar sits at z-index 10010 so it clears the calendar. Bootstrap's
 * offcanvas defaults to 1045 and nothing raised it, so the bar drew straight
 * over the open menu -- the "Menu" heading and its close button were sliced in
 * half, which looks like a broken panel rather than a stacking problem.
 *
 * This was NOT only a banner issue. The rules that push the panel below the
 * banner live in _environment_banner.html, which renders on dev and uat only,
 * so production had the same overlap with no offset at all. It belongs here,
 * where every page that draws a navbar picks it up.
 *
 * The backdrop sits between the page and the panel. */
.offcanvas {
    --bs-offcanvas-zindex: 10020;
    z-index: 10020;
}
.offcanvas-backdrop {
    z-index: 10015;
}