/* ============================================================================ Enhancements — layered on top of the original theme (theme.css). ---------------------------------------------------------------------------- Nothing here restyles the existing design. It adds what a static site had no way to express: signed-in navigation states, a scroll-reactive navbar, form feedback, and the accessibility basics the original CSS was missing. Every colour below is taken from the existing palette: accent #EA9C22 surface #141313 / #1A1919 border rgba(255,255,255,.08) muted #8A8585 ========================================================================= */ /* ── Accessibility ──────────────────────────────────────────────────────── */ /* The original stylesheet suppressed focus outlines site-wide, which made every page unusable by keyboard. Restored, in brand amber. */ :focus-visible { outline: 2px solid #EA9C22; outline-offset: 3px; border-radius: 4px; } .skip-link { position: absolute; left: -9999px; top: 0; z-index: 2000; } .skip-link:focus { left: 16px; top: 16px; padding: 10px 18px; background: #EA9C22; color: #0F0E0E; font-weight: 700; border-radius: 10px; } [x-cloak] { display: none !important; } /* ── Device tokens ───────────────────────────────────────────────────────── Two facts about the DEVICE that the whole site has to answer, declared once here because this is the only stylesheet both layouts load and because the answer is the same on a marketing page and inside the dashboard. ── 1. THE 16px FLOOR UNDER EVERY TEXT FIELD ─────────────────────────────── iOS Safari zooms the entire page when a field whose computed font-size is BELOW 16px is focused, and it does not zoom back out afterwards. The customer is left on a page 1.4x too wide, scrolling sideways to read the form they were half way through, and nothing on the screen says what happened or how to undo it. It is invisible on Android and invisible on a desktop browser at 375px, which is why it survives review. Measured across every route in the dashboard before this existed, EVERY text-entry control on the member side was under the line: .dash-input, .dash-select and .dash-textarea at 14px (Profile, Security, Licences, Tickets, Top-up — 17 controls), .adm-inline-select and .adm-inline-input at 13.5px (Orders, Wallet — 6), .adm-search-input at 15px (Orders), and the sign-in and register overlay's own fields at 14.5px. Not one field in the signed-in area, or on the way into it, could be focused on an iPhone without the page zooming. A FLOOR, NOT A SIZE, and that is the whole reason it is a token rather than a rule. `font-size: max(var(--field-font-floor, 0px), 14px)` is exactly 14px on a pointer device — the floor resolves to 0 and the declared size is what the designer wrote, to the pixel — and exactly 16px on a phone. Written the other way round, as a blanket `input { font-size: 16px }` somewhere late in the cascade, it would also have SHRUNK the two controls that are deliberately larger than the floor (.tfa-code-input at 20px, .adm-res-pct's figure at 18px) and it would have had to out-specify a dozen class rules in three stylesheets to land at all — the "restated at several rungs" failure this codebase has already been bitten by twice. max() at the declaration has no rung to lose: there is one number for the device and one for the design, and the larger wins. KEYED ON THE POINTER, NOT ON THE VIEWPORT. A 400px-wide desktop window does not zoom and does not need 16px type; an iPad at 1024px does and does. The sheet already uses `@media (hover: none)` for the copy affordances in dashboard.css, so this is the same distinction drawn with the same tool. ── 2. THE SAFE AREA ─────────────────────────────────────────────────────── partials/head sets `viewport-fit=cover`, which is what PUTS the page under the notch and the home indicator — without it the browser letterboxes and there is no inset to respect. With it, anything full-bleed or fixed to an edge has to reserve for env(safe-area-inset-*) or it is drawn underneath the hardware. Only the BOTTOM inset was ever reserved (the footer and the sidebar foot), so a notched phone in LANDSCAPE — where the notch is on the long edge, 47px of it on an iPhone 14 Pro — put the sidebar's icons, the navbar's brand and the content pane's left gutter behind it. env() is read into custom properties rather than used directly at each site for one reason that matters more than tidiness: env() cannot be set, so a layout that consumes it directly cannot be TESTED anywhere except on the physical phone. Through a variable it can: set --safe-l on in the console and every edge that honours the inset moves, and every edge that does not, does not. That is how the arithmetic below was checked. */ :root { --field-font-floor: 0px; --safe-l: env(safe-area-inset-left, 0px); --safe-r: env(safe-area-inset-right, 0px); --safe-b: env(safe-area-inset-bottom, 0px); } @media (pointer: coarse) { :root { --field-font-floor: 16px; } } @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: .01ms !important; transition-duration: .01ms !important; scroll-behavior: auto !important; } } /* ============================================================================ Site-wide layout corrections ---------------------------------------------------------------------------- These exist because the original was six separate HTML files that never sat next to each other. Now that the navbar and the footer are ONE partial rendered on every page, any width or padding a page stylesheet declares for a shared class becomes a visible jump when you navigate. Corrected here rather than in the page stylesheets, which stay as the original design. ========================================================================= */ /* ── Canonical chrome width ───────────────────────────────────────────────── THE RULE: .container is 1200px on every page, full stop. That is theme.css:40's value and what home, /store's hero, /status, /faq, /contact, /terms, /privacy, /email/verify and /reset-password all use. product.css:1608 redeclares `.container { max-width: 1300px }` at the same specificity and loads after theme.css, so on product pages it won this and dragged the NAVBAR and the FOOTER with it — both use .container. Measured at a 1425px viewport: nav container 1300px wide starting at x=62.5 on a product page vs 1200px at x=112.5 on every other page. Clicking into a product made the logo and the nav links jump 50px outward, which reads as the navbar moving. This one rule loads after product.css and pins chrome AND product content back to 1200. Why 1200 and not 1300: the product grid is fluid all the way down to its 1024px breakpoint, so 1200 is well inside its tested range, whereas widening the chrome to 1300 everywhere would push the nav wider than the content it frames on the five other page types. DOCUMENTED EXCEPTION: store.css's .store-container stays at 1400px on /store and /status. That is a sidebar + card grid designed for the extra width and narrowing it costs a column. The rule is that the CHROME is the constant — nav and footer are 1200px on all eight page types — and a content region may opt out when its own layout needs to, not the other way round. Wrapped in @media screen so it does not outrank theme.css:5121's print block, which deliberately un-caps .container for the legal pages. */ @media screen { .container { max-width: 1200px; } } /* ── Scrollbar gutter ─────────────────────────────────────────────────────── scrollbar-gutter was set nowhere, so the layout was 7.5px narrower on a page that scrolls than on one that does not, and the fixed navbar jogged sideways every time you navigated between a short page and a tall one. Reserving the gutter always makes every page lay out identically. (The related worry — the fixed navbar overhanging the scrollbar — is not real: `width: 100%` on a fixed element resolves against the initial containing block, which already excludes a classic scrollbar. Measured nav width == documentElement.clientWidth exactly.) */ html { scrollbar-gutter: stable; /* SAFARI'S TEXT AUTOSIZER, TURNED OFF — and 100%, never `none`. WebKit inflates the font-size of text blocks it judges too wide for the screen, and it does it hardest when an iPhone is turned to LANDSCAPE: body copy comes back larger than it was written, every measured height on the page is wrong by an amount nothing in the stylesheet can predict, and it happens on exactly one browser on exactly one orientation, which is why it survives every desktop check. Nothing in this codebase declared it — no reset here sets it, and theme.css is the original design and does not either — so every landscape phone has been reading a slightly different site. `100%` means "do not inflate", not "do not scale": pinch zoom and the reader's own text-size setting still work exactly as before. `none` would also disable those, which is an accessibility failure and is the reason this value is spelled out rather than copied from the first search result. Both spellings, because Safari only understands the prefixed one and Chrome only understands the standard one on desktop. */ -webkit-text-size-adjust: 100%; text-size-adjust: 100%; /* nav.navbar is position:fixed and ~71px tall, so every in-page anchor, every :target and browser scroll restoration landed the target underneath it (measured getBoundingClientRect().top === 0.14 on /#faq-container-landing). 71px of bar plus breathing room. */ scroll-padding-top: 90px; } /* ── Navbar: scroll state ───────────────────────────────────────────────── */ /* The navbar is solid at rest (theme.css:53 — deliberately, it sits over the hero artwork) and gets *more* solid plus a soft edge once you scroll off the hero, so it reads as lifted above the content passing under it. The previous values here were 3% MORE transparent than the resting state, i.e. the effect was inverted and invisible; the comment that used to sit here claimed the bar was transparent over the hero, which it never was. The transition is narrowed to the properties that actually change: theme.css:58 sets `transition: all 0.2s ease`, which meant the ~2px height change when the Outfit webfont swaps in ANIMATED, and the bar visibly wobbled on load. */ nav.navbar { transition: background-color .25s ease, border-color .25s ease, backdrop-filter .25s ease, box-shadow .25s ease; } nav.navbar.navbar-scrolled { background: rgba(15, 14, 14, .98); backdrop-filter: blur(16px); border-bottom-color: rgba(255, 255, 255, .10); box-shadow: 0 10px 30px rgba(0, 0, 0, .35); } /* ── Navbar: no layout shift while fonts load ─────────────────────────────── Outfit and RemixIcon both load with a swap/block window. Measured: the nav was 69px tall on the fallback and 71px once Outfit landed, and the hamburger glyph went 15px → 20.84px wide. Because the bar is position:fixed nothing below it moves, so the change reads as the bar itself settling. min-height pins the row to its settled height so a shorter fallback metric cannot shrink it, and the icon gets a reserved 1em box so a glyph that has not painted yet still occupies its final width. Together with the width/height now on the logo (navbar.blade.php) the navbar geometry is final at first paint. */ nav.navbar > .container { min-height: 40px; } nav.navbar .navbar-toggle i, nav.navbar .nav-account-trigger i, nav.navbar .nav-dashboard-btn i, nav.navbar .nav-verify-badge i { display: inline-block; min-width: 1em; min-height: 1em; text-align: center; font-style: normal; } /* Active page marker. */ nav.navbar .navbar-menu > li > a.is-active { color: #fff; } nav.navbar .navbar-menu > li > a.is-active::after { content: ''; display: block; height: 2px; margin-top: 5px; border-radius: 2px; background: #EA9C22; } /* ── Navbar: Dashboard button ─────────────────────────────────────────────── An , so theme.css:499's .btn-primary already gives it the right box — this only stops the label wrapping when the account username beside it is long. It is deliberately amber: it sits in the slot a guest sees the Login button in, so the primary action does not move when you sign in. */ .nav-dashboard-btn { white-space: nowrap; } /* ── Navbar: unverified nudge ───────────────────────────────────────────── */ .nav-verify-badge { display: inline-flex; align-items: center; gap: 7px; padding: 7px 13px; font-size: 12px; font-weight: 600; color: #F97316; border: 1px solid rgba(249, 115, 22, .35); background: rgba(249, 115, 22, .10); border-radius: 10px; text-decoration: none; white-space: nowrap; transition: background-color .2s ease; } .nav-verify-badge:hover { background: rgba(249, 115, 22, .18); } .nav-verify-dot { width: 6px; height: 6px; border-radius: 50%; background: #F97316; } /* ── Navbar: the cart ─────────────────────────────────────────────────────── "cart should be top right at navbar." The first thing in .navbar-actions, on BOTH layouts — see the comment on the markup in partials/navbar for why that slot and not the far right. SELECTED THROUGH nav.navbar .navbar-actions, WHICH IS NOT DECORATION. theme.css:113 declares `nav.navbar .navbar-actions a { padding: 8px 20px; border-radius: 6px }`, which is specificity (0,2,2). A bare `.nav-cart` is (0,1,0) and LOSES to it regardless of file order, so the chip would silently inherit the pill geometry of a Login button — 40px wider than it needs to be, in the one part of the bar that has no room to spare. Written this way it is (0,3,1) and wins on its own merits, with no !important. A FIXED-WIDTH SQUARE, and that is the measurement that drove the design. The bar between 769px and 1023px is already at its limit: the wallet chip stands down entirely in that band because 133px of it pushed .navbar-actions 103px past the viewport at 780px (see the note on that chip below). A cart cannot stand down anywhere — it is the entry point to the basket and there is no sidebar entry to fall back on — so it is built to be the narrowest thing that can carry a count: one glyph, and the number OUTSIDE the box. The badge is absolutely positioned for the same reason. An inline count makes the control 18px wider the moment somebody adds an item, so the whole row shifts left as you shop; overlapping the corner, the chip is the same width with a basket of nothing and a basket of ninety-nine. */ nav.navbar .navbar-actions .nav-cart, nav.navbar > .container > .nav-cart-bar { position: relative; display: inline-flex; align-items: center; justify-content: center; gap: 8px; padding: 8px 11px; border: 1px solid rgba(255, 255, 255, .08); border-radius: 12px; background: transparent; color: #C9C5C5; font-size: 14px; font-weight: 500; line-height: 1; text-decoration: none; white-space: nowrap; transition: border-color .2s ease, color .2s ease, background-color .2s ease; } /* Borrowed from .nav-account-trigger exactly, so the cart, the wallet chip and the account button read as one family of controls rather than three widgets that happen to share a row. */ nav.navbar .navbar-actions .nav-cart:hover, nav.navbar > .container > .nav-cart-bar:hover { color: #fff; border-color: rgba(234, 156, 34, .45); background: rgba(255, 255, 255, .03); } .nav-cart > i { font-size: 17px; /* The same reserved box every other glyph in this bar gets: RemixIcon loads with a block window, so without it the chip is narrower until the font lands and the bar visibly settles on first paint. */ display: inline-block; min-width: 1em; min-height: 1em; text-align: center; font-style: normal; } /* The word "Cart", clipped on desktop and real in the mobile panel. ONE ELEMENT RATHER THAN A .sr-only SPAN PLUS A VISIBLE ONE. The chip needs an accessible name at every width and a visible label at exactly one of them; two elements would mean a screen reader hearing "Cart" twice on a phone. This is the standard clip, undone inside the 768px block at the bottom of this section. */ .nav-cart-label { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); clip-path: inset(50%); white-space: nowrap; border: 0; } /* AMBER, AND THE ONE AMBER THING THAT IS ALLOWED TO APPEAR AND DISAPPEAR. Everything else accented in this bar is permanent (the Dashboard button, the wallet glyph); this exists only when there is something in the basket, which is what makes it read as news rather than as chrome. The ring is the navbar's own background colour, so the badge reads as sitting ON the chip rather than being clipped by its corner — the bar is rgba(15,14,14,.95) over whatever the page is, and a solid #0F0E0E ring is indistinguishable from it at this size. NOT COLOUR ALONE: it is a number. There is nothing here a colour-blind customer has to infer from a hue. */ .nav-cart-count { position: absolute; top: -7px; right: -7px; display: inline-flex; align-items: center; justify-content: center; min-width: 19px; height: 19px; padding: 0 5px; border-radius: 10px; background: #EA9C22; color: #0F0E0E; font-size: 11px; font-weight: 800; line-height: 1; font-variant-numeric: tabular-nums; box-shadow: 0 0 0 2px #0F0E0E; } /* ── Navbar: wallet balance ───────────────────────────────────────────────── The balance chip that sits immediately left of the account menu on panel pages. Rendered only when partials/navbar is given $walletChip, which DashboardNavComposer supplies and only for the dashboard layout — so this block is inert on marketing pages even though this stylesheet loads there. DECLARED HERE, beside .nav-account and .nav-verify-badge, rather than in dashboard.css: it is part of the signed-in account cluster in the bar, it has to obey the same 768px stacking rule as .nav-dashboard-btn (see the media query at the bottom of this section of the file), and splitting one visual group across two stylesheets is how the pieces come to disagree. NEUTRAL, NOT AMBER. The bar already has one accent object — the Dashboard button — and a second amber thing beside it makes neither read as the primary action. This borrows .nav-account-trigger's exact box instead: same 12px radius, same 1px hairline, same muted text, same hover. The two then read as one control pair rather than as a badge stuck onto a button. PHONE WIDTHS ARE THE MEASURED RISK. Below 768px the whole of .navbar-actions collapses into the mobile menu panel as a full-width column (see the media query further down), so this chip never competes with the username for space in the bar itself — the bar there is a logo and a hamburger. The rule that matters is therefore the stacking one, not a truncation one. Measured at 430px and 360px: nothing overflows and the bar's own layout is unchanged with the chip present. The figure is tabular so it does not jitter in width as the balance changes — a chip that resizes on every page load reads as the layout settling. */ .nav-wallet { display: inline-flex; align-items: center; gap: 7px; padding: 7px 12px; border: 1px solid rgba(255, 255, 255, .08); border-radius: 12px; background: transparent; color: #C9C5C5; font-size: 14px; font-weight: 500; line-height: 1; /* The bar's own `.navbar-actions a` rule (theme.css:113) sets 8px 20px and a 6px radius on every anchor in here. This is more specific by one class, so the values above win — but the shorthand there also sets text-decoration, which is restated rather than inherited. */ text-decoration: none; white-space: nowrap; transition: border-color .2s ease, color .2s ease, background-color .2s ease; } .nav-wallet:hover { color: #fff; border-color: rgba(234, 156, 34, .45); background: rgba(255, 255, 255, .03); } /* Amber, and only the glyph. It is the one thing in the chip that says "money" at a glance, and colouring the figure itself would make a €0.00 balance look like a warning. */ .nav-wallet > i { font-size: 16px; color: #EA9C22; /* Same reserved box as the other navbar glyphs above: RemixIcon loads with a block window, so without this the chip is narrower until the font lands and the bar visibly settles. */ display: inline-block; min-width: 1em; min-height: 1em; text-align: center; font-style: normal; } .nav-wallet-value { color: #FFFFFF; font-weight: 600; font-variant-numeric: tabular-nums; } /* ── The band where the bar has no room for it ────────────────────────────── MEASURED, NOT GUESSED, and this rule exists because the first version of this chip broke the navbar without producing a scrollbar to notice it by. The bar is one flex row: brand, then .navbar-menu, which CONTAINS .navbar-actions. Between 769px (where theme.css stops collapsing the menu into the mobile panel) and roughly 890px, that row is already at its limit — measured on production before this chip existed, .navbar-actions cleared the container's right edge by 7px at a 780px viewport. Adding 133px of balance chip to a row with 7px of slack pushed .navbar-actions 103px PAST the viewport at 780px and 63px past it at 820px. And it did so SILENTLY. nav.navbar is position:fixed, and a fixed element's overflow does not extend the document's scrollable area — so documentElement.scrollWidth still equalled clientWidth, no scrollbar appeared, and the account menu simply sat off the right-hand edge of the screen where nobody could reach it. That is worse than a scrollbar: a scrollbar is visible. So the chip stands down for that band. 1023px rather than the ~890px where it actually starts fitting, because 1024 is the width the dashboard shell already uses to turn its sidebar into a drawer — reusing a breakpoint the layout has rather than inventing a third, and buying comfortable slack (at 1024 the row clears the container by 24px with 117px spare) instead of the 17px it has at 900. The chip is not lost in that band: below 1024 the sidebar is a drawer with a Wallet entry in it, and below 768 the chip itself reappears inside the mobile menu panel — which is why this query has a LOWER bound. Without min-width the rule would also hide it there, where it was measured to fit perfectly. */ @media (min-width: 769px) and (max-width: 1023px) { .nav-wallet { display: none; } } /* ── Navbar: account dropdown ───────────────────────────────────────────── */ .nav-account { position: relative; } .nav-account-trigger { display: flex; align-items: center; gap: 9px; padding: 6px 10px 6px 6px; background: transparent; border: 1px solid rgba(255, 255, 255, .08); border-radius: 12px; color: #C9C5C5; font: inherit; font-size: 14px; font-weight: 500; cursor: pointer; transition: border-color .2s ease, color .2s ease, background-color .2s ease; } .nav-account-trigger:hover { color: #fff; border-color: rgba(234, 156, 34, .45); background: rgba(255, 255, 255, .03); } .nav-account-trigger i { font-size: 16px; transition: transform .2s ease; } .nav-account-trigger i.is-flipped { transform: rotate(180deg); } .nav-avatar { display: grid; place-items: center; width: 28px; height: 28px; border-radius: 50%; background: #EA9C22; color: #0F0E0E; font-size: 12px; font-weight: 800; } .nav-account-name { max-width: 120px; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } /* ── The band where the bar's width must not depend on who is signed in ───── THE WALLET CHIP WAS NOT THE ONLY VARIABLE IN THAT ROW. The block above stands the chip down between 769px and 1023px because the bar measured 7px over at 780px before it existed — but that figure, and the "24px of slack at 1024" beside it, were both read off the operator's own account, and "Admin" is five characters. The username is rendered at its natural width up to the 120px cap directly above, so the LENGTH OF A CUSTOMER'S NAME is a term in whether the navigation fits. Measured on /dashboard as the platform's own test member, whose name is twelve characters: the bar cleared the container by 23px at a 900px viewport and by 16px at 1024 — where the chip has just come back — and at the 120px cap, which any name of about eighteen characters reaches, by 68px and 61px. So this is not an edge case waiting to happen; it is the ordinary state for most of the customers on the platform, on every page of the panel. AND IT IS INVISIBLE FROM THE PAGE. nav.navbar is position:fixed, so its overflow never extends the document's scrollable area, and body is overflow-x:hidden besides — documentElement measures clean while the right edge of the account button, the control that reaches Profile, Security and Sign out, sits cut off past the screen edge. That is the same failure mode the chip's own comment above describes, one step further along. THE WORD IS WHAT LEAVES, NOT THE CONTROL. The avatar keeps the initial, the chevron keeps the affordance, the button keeps its box — and the dropdown it opens prints the full username and the email address as its first line, so nothing is actually lost. It is the move .nav-cart-label and .dash-bill-go-label already make on this platform when a row runs out of width, and it is the only one that makes the bar a FIXED width again rather than a width that happens to fit the person who measured it. 1099px, measured rather than rounded to a breakpoint we already own: with the name gone the row clears the container by 24px from 769px up, and with a 120px name it first clears at a 1100px viewport (15px spare) and is 61px over at 1024. Below 769 theme.css has already folded the whole row into the mobile panel, where the name is uncapped on purpose and there is a column to put it in — hence the lower bound, without which this would strip the name out of the one place it has room. WHAT THIS DOES NOT FIX, so nobody measures it and thinks the rule failed: between 769px and roughly 830px the bar is over the container by ~70px with no name at all. That is the pre-existing condition the chip's comment recorded at 780px and it is a property of the desktop row itself — five nav links at a 32px gap, the cart, the Dashboard button and the account cluster simply do not fit a 754px content box. Closing it means collapsing to the burger higher than 768px, which is theme.css's breakpoint and enhancements' whole mobile-panel block, and belongs to whoever owns that bar. */ @media (min-width: 769px) and (max-width: 1099px) { nav.navbar .nav-account-name { display: none; } } .nav-dropdown { position: absolute; right: 0; top: calc(100% + 10px); min-width: 232px; padding: 6px 0; background: #141313; border: 1px solid rgba(255, 255, 255, .08); border-radius: 14px; box-shadow: 0 24px 48px rgba(0, 0, 0, .55); /* THIS NUMBER ONLY RANKS THIS PANEL AGAINST ITS SIBLINGS INSIDE THE BAR. nav.navbar is fixed AND has a z-index, so it is a stacking context and nothing inside it can outrank anything outside it — against the rest of the document this menu sits at whatever level the BAR has, not at 1200. Reading it as "1200 clears the page" is what left the account menu under the flash toast. The level that actually governs it is nav.navbar's, in the STACKING ORDER block below. */ z-index: 1200; overflow: hidden; } .nav-dropdown-head { display: flex; flex-direction: column; gap: 2px; padding: 12px 16px; border-bottom: 1px solid rgba(255, 255, 255, .07); } .nav-dropdown-head strong { font-size: 14px; color: #fff; } .nav-dropdown-head span { font-size: 12px; color: #8A8585; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } /* min-height 44, not the 39px the padding alone produced. Measured at 430, 375 and 360: every row in this menu — Dashboard, Subscriptions, Orders, Security, Sign out — came out 39px tall, a pixel under the 40px floor and five under the 44px target, and on a phone this menu IS the account menu because the whole thing stacks into the mobile panel. The height is added as a floor rather than as more padding so the text keeps sitting where it does on desktop, where the rows are already comfortable. */ .nav-dropdown a, .nav-dropdown-signout { display: flex; align-items: center; gap: 9px; width: 100%; min-height: 44px; padding: 10px 16px; font-size: 14px; color: #C9C5C5; text-decoration: none; background: transparent; border: 0; font-family: inherit; text-align: left; cursor: pointer; transition: background-color .15s ease, color .15s ease; } .nav-dropdown a:hover, .nav-dropdown-signout:hover { background: rgba(255, 255, 255, .05); color: #fff; } .nav-dropdown-accent { color: #EA9C22 !important; font-weight: 600; } .nav-dropdown form { border-top: 1px solid rgba(255, 255, 255, .07); } /* ============================================================================ STACKING ORDER — the one place the site's fixed layers are ranked ---------------------------------------------------------------------------- WHAT WAS WRONG, AND WHY IT WAS INVISIBLE IN THE MARKUP nav.navbar is `position: fixed` with `z-index: 1000` (theme.css), and those two together make it a STACKING CONTEXT. Everything inside it is therefore ranked against its siblings only, and the whole bar is then ranked against the page as a single unit at 1000. .nav-dropdown declares `z-index: 1200` just above, which reads like it clears the page — and it does not clear anything. It cannot: a child cannot escape its parent's context, so the account menu's real level against the rest of the document is 1000, whatever number is written on it. .flash-toast sat at 1500, a sibling of the bar rather than a child of it, so it outranked the account menu by 500. MEASURED by hit-testing the centre of the open dropdown at 1440 and 1024 with a toast on screen: the element returned by elementFromPoint was div.flash-toast, not the menu. The toast covers the dropdown's head — the "signed in as" name and email — which is exactly the moment it is most needed, because a flash message and somebody opening the account menu are the SAME event: you sign in, "Signed in successfully" appears, and you go straight to the menu. WHY THE TOAST IS NOT SIMPLY LOWERED It has to stay above product.css's .breadcrumb, which is `position: fixed`, `top: 80px`, `z-index: 999` and lands under the toast on every product page. So the toast must be over 999 and the account menu must be over the toast — and the account menu IS the navbar. The navbar therefore has to move up, and everything that legitimately covers the navbar has to move with it. THE LADDER, low to high. Anything fixed on this site belongs on it. 999 .breadcrumb product.css — fixed under the bar 1500 .flash-toast over the page and the breadcrumb, under the bar 1600 nav.navbar and with it .nav-dropdown and the mobile panel 1650 .dash-backdrop dims the shell, so it is over the bar 1700 .dash-sidebar the drawer covers the bar on purpose; see the note in dashboard.css beside its own z-index 1790 .lock-bar platform state, over the drawer 1800 .imp-bar whose own note requires it to survive a modal 2000 .auth-overlay a real modal, over all site chrome 10000 .video-modal product.css WHY THE OVERRIDES LIVE HERE RATHER THAN IN EACH FILE Three of these values are declared in theme.css and dashboard.css. A ladder split across three files is a ladder nobody can read, and the last time these numbers were chosen independently is how the dropdown ended up under the toast. enhancements.css is the last stylesheet in the cascade, so one block here is both the statement of the order and the thing that enforces it. CHANGE A LEVEL HERE, NOT AT ITS ORIGINAL SITE, or the two will disagree. ========================================================================= */ nav.navbar { z-index: 1600; } @media (max-width: 1024px) { /* The drawer and its backdrop are the two things that are meant to cover the bar — dashboard.css argues that case beside its own declarations. They move up with it so that stays true. Scoped to the same breakpoint dashboard.css uses, because above it .dash-sidebar is `position: sticky` and 100px down the page, where it neither needs a level nor should have one. */ .dash-backdrop { z-index: 1650; } .dash-sidebar { z-index: 1700; } } /* ── Flash toast ────────────────────────────────────────────────────────── */ /* Fixed, never in flow. The previous implementation was an in-flow div above the hero with `margin: 100px 0 -60px` hand-compensating for the fixed navbar, so any page that flashed a message rendered with different geometry from the same page without one — the symptom being "logging in moves the navbar". Position: fixed removes it from layout entirely, so no message can shift anything, on any page, at any breakpoint. */ .flash-toast { position: fixed; /* CLEARS THE TALLEST BAR ON THE SITE, WHICH IS NOT THE ONE THIS NUMBER WAS WRITTEN FOR. The old value said "clears the 68px navbar"; the bar has not been 68px for some time. Measured in a browser at six widths: the marketing bar is 73–74px everywhere, and the DASHBOARD bar is 75px above 1024 and 83px at 768 and below. So the toast at 84px was already sitting 5px inside the dashboard bar on a phone, and got away with it only because it used to paint on top of the bar. It no longer does — see the stacking block above, where the bar moved over the toast so the account menu could clear it — so the overlap that did not show before would now clip the toast's top corners behind the bar. 93px is the tallest measured bar plus a 10px gap, and it is one number for every width and both layouts rather than a value per breakpoint that drifts the next time a bar changes height. */ top: 93px; right: 20px; z-index: 1500; display: flex; align-items: center; gap: 11px; max-width: min(420px, calc(100vw - 40px)); padding: 13px 16px; border-radius: 13px; font-size: 14px; font-weight: 500; line-height: 1.45; background: #141313; box-shadow: 0 18px 40px rgba(0, 0, 0, .5); animation: flashToastIn .28s cubic-bezier(.16, 1, .3, 1); } @keyframes flashToastIn { from { opacity: 0; transform: translateX(16px); } to { opacity: 1; transform: none; } } .flash-toast > i { font-size: 18px; flex-shrink: 0; } .flash-toast > span { flex: 1; min-width: 0; } /* 44x44, AND THE TOAST KEEPS ITS SHAPE. This is the only control on the toast, it is the only way to get a message off the screen before its six-second fuse burns down, and it measured 18x18 at every width from 1440 to 360 — the smallest target anywhere in the site's chrome, on the one element that is always over the page rather than in it. THE NEGATIVE MARGIN IS THE WHOLE POINT, and it is on both axes. A bare 44px button would take the flex line from 28px to 44px and the toast from 54px to 70px, and it would take the 26px it gains out of the flexible text span and drag the glyph 13px left with it — a fatter, rearranged bar of chrome on every sign-in, which is the opposite of what this pass is for. -8px top and bottom and -13px each side puts the button's MARGIN box back at 18px wide, which is exactly the space the old glyph occupied, so the toast's width is untouched and the glyph stays on the pixel it was on. The hit area grows outwards over the toast's own padding on the right and over the 11px gap on the left, both of which are dead space, and stays entirely inside the toast. MEASURED, same message, same 1440 viewport, before and after: toast 281x54 with an 18x18 target, then 282x56 with a 44x44 one, glyph unmoved at x 1370-1388. One pixel of that is rounding on the side margins and two are the line growing to fit a 26px margin box against a 26.1px icon; that is the entire cost. elementFromPoint returns this button at all four corners and the centre of the 44x44 square, at 1440 and at 360, and the toast still clears the tallest bar on the site with its own top:93px. */ .flash-toast > button { flex-shrink: 0; display: grid; place-items: center; width: 44px; height: 44px; margin: -8px -13px; padding: 0; background: none; border: 0; color: inherit; opacity: .55; font-size: 17px; line-height: 1; cursor: pointer; transition: opacity .15s ease; } .flash-toast > button:hover { opacity: 1; } .flash-success { color: #22C55E; background: #101a13; border: 1px solid rgba(34, 197, 94, .35); } .flash-error { color: #EF4444; background: #1a1011; border: 1px solid rgba(239, 68, 68, .35); } /* Full width across the top on phones — a 420px card pinned right is most of a small screen anyway, and a partially off-screen toast reads as broken. */ @media (max-width: 520px) { .flash-toast { /* No `top` here any more. It used to drop the toast to 78px on a phone, which is 5px INSIDE the 83px dashboard bar — the collision described on the base rule, and the one width where it mattered most. The base 93px already clears every bar at every width, so this block is left holding only the thing it is actually for: going full width. */ left: 14px; right: 14px; max-width: none; } } /* ── Mobile ───────────────────────────────────────────────────────────────── 768px, matching theme.css:140 and product.css:1770 exactly. This block used to open at 968px, which put a 200px band (769–968px) where the mobile account rules below were live against a navbar still in its full desktop row — a signed-in user at 900px got a full-width stretched account button and a dropdown rendered inline, growing the fixed bar from 72px to 264px tall. One breakpoint, used in all three places. ========================================================================= */ @media (max-width: 768px) { /* THE MOBILE PANEL. The original drove this from a `mobile-active` class that an inline onclick put on nav.navbar, and theme.css:151-162 hung the entire panel off it — display, fixed positioning, dark background, column direction, padding. Alpine sets `.is-open` on the