, which adds its OWN 1.5rem (24px) of padding on every side, on top of the .container inside it that has its usual 0.75rem (12px). The navbar has no such wrapper - just a plain .container with nothing extra around it - so it only ever gets that 0.75rem, never the boxes' extra 1.5rem. That constant 24px gap is what was actually showing up as "way out to the edge" in the screenshot. Below 576px specifically, NEITHER container has any max-width active yet (Bootstrap's first container breakpoint doesn't start until exactly 576px), so neither one gets any extra auto-margin from being centered in a capped box - the boxes' 24px head start from their section's own p-4 is the ONLY thing separating them from the navbar in this range, and it stays a constant 24px at every width from 0 up to 575.98px (it's fixed padding, not something that scales with the viewport). Above 576px, both containers' auto-margins grow together at the same rate and this gap becomes visually irrelevant on its own - which is why this only needed fixing in this one narrow band, and why a previous attempt at fixing this via max-width (rather than this padding) didn't address the real cause. The fix: give the navbar's container that same missing 24px directly, as real padding (0.75rem default + 1.5rem to match the boxes' section padding = 2.25rem total), only in the range where it isn't otherwise covered by the ≥768px rule below. This used to shrink back down at very narrow widths (a clamp() easing from 2.25rem down to 0.75rem below 380px) to try to leave the brand row more room and avoid wrapping. That's no longer needed - see the .navbar-brand rules further down, which fix the wrapping problem at its actual source instead. With that fixed independently, this padding can just stay the flat 2.25rem that matches the cards, at every width, with no compromise. */ @media (max-width: 575.98px) { nav.navbar > .container { padding-left: 2.25rem; padding-right: 2.25rem; } } /* Right around 992px - where the horizontal desktop nav first appears - there isn't quite enough room for the logo text plus all five nav items at their normal size, so Bootstrap was dropping the whole nav-links row onto a second line below the logo instead of keeping it inline (visible as the nav "wrapping" anywhere from 992px up to roughly 1200px). clamp() scales the logo and nav-link text (and their padding) down fluidly as the viewport narrows through that range, so everything shrinks a little instead of wrapping - and flex-wrap: nowrap forces it to actually stay on one line rather than falling back to wrapping if it's ever a few pixels short. Below 992px the hamburger takes over completely, so none of this applies there. */ @media (min-width: 992px) { nav.navbar > .container { flex-wrap: nowrap; } .navbar-brand { font-size: clamp(0.85rem, 0.6rem + 0.6vw, 1.25rem); white-space: nowrap; } .navbar-nav .nav-link { font-size: clamp(0.75rem, 0.5rem + 0.45vw, 1rem); padding-left: clamp(0.3rem, 0.3vw, 0.75rem); padding-right: clamp(0.3rem, 0.3vw, 0.75rem); white-space: nowrap; } } /* Same wrapping problem shows up again down at the opposite end of the scale. Below ~992px the brand+toggler row isn't sized by us at all - it just uses Bootstrap's plain 1.25rem brand text - which is fine until the phone itself gets narrow enough that "Liberti's Auto Electric" plus both icons plus the toggler button no longer fit on that one flex row. Since nav.navbar > .container is flex-wrap: wrap by default at these widths, the toggler is what gets pushed down to its own line when that happens. This used to be "fixed" by shrinking the brand's font-size via clamp() below a chosen breakpoint - 400px at first, then 430px once the padding fix above ate into the row's space, then a recalculated shrink curve once that still went flat too soon and let the wrap back in at 355px, then it came back again at 300px, then 240px. Each round "fixed" the specific width that had just been screenshotted and nothing more, because shrinking the font only ever bought a fixed amount of extra room - and a company name plus two icons plus a hamburger simply doesn't fit in one row at any width, once the row gets narrow enough. There's no clamp() curve that fixes that; it can only ever move the breaking point to a different number. The actual fix: stop trying to shrink everything to fit. Keep the two icons and the toggler at a fixed, always-legible/tappable size, and let ONLY the text label - the one part of this row that doesn't need to stay a fixed size to remain usable - flex to fill whatever room is left, and truncate with an ellipsis if there isn't enough. See .navbar-brand, .navbar-brand-icons, and #navlibertis below. That removes the ceiling entirely: there is no width, ever, at which this row can wrap again, because nothing in it is being asked to grow past its available space without somewhere to give. IMPORTANT - do NOT "fix" this the way the desktop case above does, by forcing flex-wrap: nowrap on the container. That was tried and broke the OPEN mobile menu at this same width: nav.navbar > .container has three flex children (brand, toggler, and the #navmenu collapse), and it's .navbar-collapse's own flex-basis: 100% - relying on wrapping being allowed - that pushes the whole dropdown list onto its own line below the brand/toggler row in the first place. Force nowrap on the container and that no longer has anywhere to wrap TO, so the open dropdown gets squeezed onto the same row as the brand instead, overlapping it and clipping every link's text off the right edge - exactly what showed up in a screenshot at 400px with the menu open. The fix below doesn't touch the container's own flex-wrap at all, so the collapse's behavior is completely unaffected. UPDATE: #navmenu is now position:absolute (search "#navmenu {" further up for the overlay-menu change), which takes it out of this flex layout entirely - .container effectively only has two flex children now (brand, toggler), not three, so the specific wrap-collision this warning describes can't happen anymore either way. Left this comment as history/context rather than deleting it, since forcing nowrap here is still unnecessary either way (the real fix, described above, already guarantees the brand/toggler row itself never needs to wrap) - just noting that the ONE reason nowrap specifically would have been dangerous no longer applies. */ .navbar-toggler { flex-shrink: 0; } .navbar-brand { display: flex; align-items: center; /* Flex items default to min-width:auto, which means a flex item is never allowed to shrink below its own CONTENT's natural width, no matter how small flex-shrink makes its share of the row - that's the exact, easy-to-miss reason the whole brand block was always forcing the row wider than it had room for instead of compressing, regardless of font-size. min-width:0 removes that floor, so the browser is actually allowed to shrink this block down to whatever space the row has left. */ min-width: 0; } .navbar-brand-icons { /* The car + activity icons never shrink or get squeezed - only the text label (below) gives up space when the row is tight. */ flex-shrink: 0; } #navlibertis { white-space: nowrap; overflow: hidden; text-overflow: ellipsis; min-width: 0; /* same reasoning as .navbar-brand above, one level in - this is what actually lets the text shrink narrower than "Liberti's Auto Electric" instead of forcing the row wider to fit every letter. */ } /* Inert everywhere by default - this
(in nav.js, between "Liberti's" and "Auto Electric") only does something once the media query below turns it back on. */ .brand-break { display: none; } /* Not load-bearing for the no-wrap guarantee above (that comes entirely from the ellipsis-truncation rules), just a nicety: on real phones this keeps a bit more of "Liberti's Auto Electric" visible before the ellipsis needs to kick in, rather than relying on truncation for every phone in portrait. */ @media (max-width: 480px) { .navbar-brand { font-size: 1rem; } } /* At 364px and below, rather than let "Liberti's Auto Electric" truncate down to something like "Liberti's Au..." (which the rules above would otherwise do - still perfectly safe, just not the nicest look at this size), deliberately break it into a two-line block instead: "Liberti's" next to the icons, "Auto Electric" wrapping underneath. The two lines come out close to the same length, which reads as a clean, intentional lockup instead of a squeezed one-liner. This is a specific design choice at this exact width, not a fallback for a wrapping bug - the ellipsis rules above already guarantee the row itself can never break regardless of width; this just chooses a nicer-looking way to use that same guarantee once there's this little room. (This was briefly moved down to 350px on the assumption that the single-line ellipsis version could safely run a little narrower first - turned out 350-364px still wrapped the toggler even with ellipsis active, so apparently that version has its own floor somewhere in this range too. Not fully diagnosed why - reverted back to 364px, which is the number actually confirmed working end to end, rather than keep guessing at a number that isn't. If this gets revisited, the browser's own dev tools - inspecting #navlibertis's computed width at ~360px, the way the flex-vs-float question got settled a few rounds back - would give a real answer instead of another guess.) */ @media (max-width: 364px) { /* .navbar-brand is display:flex everywhere above this width - not for alignment, but because that's what lets #navlibertis act as a shrinkable flex child (min-width:0, further up), which is the whole mechanism behind the ellipsis-truncation guarantee at every width from 365px up to 575px: the name shrinks/truncates there instead of wrapping or breaking into two lines. That still needs to stay flex everywhere else - this override only touches the one breakpoint where a two-line lockup is what's wanted instead. Turning flex back off JUST here is actually all this needs. Flex locks every child to the same starting column no matter what wraps inside it - that's why "Auto Electric" was lining up under "Liberti's" instead of under the icons: as a flex item, the text block's own left edge always stayed where flex placed it (right after the icon column) on every line it contains, including the wrapped one. Plain, ordinary inline flow doesn't have that behavior at all - each new line just returns to the containing block's own left edge on its own, with nothing extra needed to make that happen. Since that left edge is the same one the icons sit at, this is enough by itself - no float, no hard-coded width to keep in sync with the icons later. */ .navbar-brand { display: block; } .navbar-brand-icons { margin-right: 0.35rem; } .brand-break { display: inline; } #navlibertis { /* This first tried to keep white-space:nowrap here (inherited from the base rule further up), reasoning that the
above should be the only break allowed, so "Auto Electric" always stays together as one line. That was the actual cause of the hamburger overlapping "Electric" in testing: nowrap means the text is NOT allowed to wrap on its own no matter what, so once "Auto Electric" needed even slightly more room than this row had left, it had nowhere to go but overflow sideways, straight into the toggler - there was no fallback if the numbers were ever this tight. white-space:normal here instead means the
above still does its job as the PRIMARY, intended break (that's what produces the normal "Liberti's" / "Auto Electric" two-line look), but if this row is ever narrow enough that even "Auto Electric" alone doesn't fit, it can ALSO wrap a second time into "Auto" / "Electric" as a fallback - a slightly taller, three-line brand instead of overlapping text. Worse-looking in that rare case, but never broken - the same trade made for the ellipsis-truncation rule at wider widths further up: prefer a guaranteed graceful fallback over a hard rule that quietly breaks the moment its assumptions are off by a few pixels. */ white-space: normal; overflow: visible; text-overflow: clip; line-height: 1.15; } } /* Below 280px, the fixed-size pieces of this row - the two icons, the toggler, and the edge padding that matches the Repair/Hybrid/Service cards - add up to nearly the whole available width on their own, before any text even enters the picture. That's a genuine space shortage, not a layout bug the way the wrapping/overlap issues above were - no wrapping or truncation trick invents width that isn't there. Nothing real loads this page anywhere near this narrow (320px, the original iPhone SE, is the actual floor - this is only reachable by manually dragging a desktop browser's width down), so this is pure extra headroom, not a fix for a real device: - the decorative flash icon next to the car icon is dropped entirely, freeing up its width for the text. - the edge padding that matches the cards eases back down to the plain 0.75rem every other .container has by default (same trade made for the padding clamp earlier in this file: a little edge-alignment given up at a width nothing will ever actually see, in exchange for more breathing room). */ @media (max-width: 280px) { #navflash { display: none; } nav.navbar > .container { padding-left: 0.75rem; padding-right: 0.75rem; } } /* Old attempts at recoloring Bootstrap's built-in SVG-background-image hamburger icon (.navbar-toggler-icon). Replaced below by a real 3-bar custom icon (.hamburger-icon / .hamburger-bar) that animates into an "X" with CSS transitions instead of swapping static SVGs, so these no longer apply to anything - kept only as a record of what was tried. .navbar-dark .navbar-toggler-icon { background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 30 30'%3e%3cpath stroke='rgba%28220, 53, 69, 0.95%29' stroke-linecap='round' stroke-miterlimit='10' stroke-width='2' d='M4 7h22M4 15h22M4 23h22'/%3e%3c/svg%3e") }; .navbar-dark .navbar-toggler-icon { background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 30 30'%3e%3cpath stroke='rgba%282255, 0, 0, 0.95%29' stroke-linecap='round' stroke-miterlimit='10' stroke-width='2' d='M4 7h22M4 15h22M4 23h22'/%3e%3c/svg%3e") }; .navbar-dark .navbar-toggler-icon { background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 30 30'%3e%3cpath stroke='rgba%282255, 255, 255, 0.95%29' stroke-linecap='round' stroke-miterlimit='10' stroke-width='2' d='M4 7h22M4 15h22M4 23h22'/%3e%3c/svg%3e") }; */ /* Custom hamburger -> X toggle button. Bootstrap's default .navbar-toggler ships a gray focus ring (box-shadow) that shows on tap/click, plus a border - both removed here. The icon itself is now 3 real bar elements instead of a background-image, animated purely with CSS transitions. Bootstrap's collapse JS keeps aria-expanded in sync with the menu's open/closed state on its own, so that attribute alone drives the animation below - no extra JS needed. */ .navbar-toggler { border: none; box-shadow: none; padding: 0.35rem 0.5rem; } .navbar-toggler:focus { box-shadow: none; outline: 0; } .hamburger-icon { display: inline-block; position: relative; width: 24px; height: 18px; vertical-align: middle; } .hamburger-bar { position: absolute; left: 0; width: 100%; height: 2px; background-color: rgba(255, 255, 255, 0.9); border-radius: 1px; transition: transform 0.25s ease, opacity 0.2s ease, top 0.25s ease; } .hamburger-bar:nth-child(1) { top: 0; } .hamburger-bar:nth-child(2) { top: 8px; } .hamburger-bar:nth-child(3) { top: 16px; } /* Open state: top and bottom bars rotate into an X, middle bar fades out. */ .navbar-toggler[aria-expanded="true"] .hamburger-bar:nth-child(1) { top: 8px; transform: rotate(45deg); } .navbar-toggler[aria-expanded="true"] .hamburger-bar:nth-child(2) { opacity: 0; } .navbar-toggler[aria-expanded="true"] .hamburger-bar:nth-child(3) { top: 8px; transform: rotate(-45deg); } /* MailerLite Newsletter Form now lives in a modal (#newsletter in index.html) instead of the #news bar, so it just stacks naturally with plain Bootstrap spacing utilities (mb-3, d-flex, d-grid) in the markup, no custom layout CSS needed here anymore. Only styling the recaptcha needs: centered, and scaled down slightly since the modal is narrow on mobile. */ #mlb2-6904338 .g-recaptcha { transform: scale(0.9); transform-origin: center top; } /* Footer credit link ("Website by Matt Whitcomb", both pages): after a few rounds of trying different reds and greys specifically for THIS link (see earlier versions of this file if curious - a compliant grey, a lightened red, an outline, back to plain red...), the simpler answer was to just stop giving this one its own separate identity and instead match it to the exact same white/grey/underline treatment the 5 main nav links already use right above in this file (see "Underline hover/focus effect" further up) - consistent with the rest of the site's link language, and it sidesteps the whole red-vs-contrast debate entirely (white text and a light grey hover both clear contrast against this dark footer with plenty of room to spare, no special-casing needed). "!important" is required on the color overrides - Bootstrap's own .link-danger class (still the class in the HTML - only the color is being overridden here, not the class itself) ships its own colors with !important already, so a normal, unqualified override would quietly lose to it. Scoped to "footer" so this doesn't touch link-danger anywhere else the class might get used later. text-decoration:none removes the browser's own plain, always-on underline - replaced by the animated version below instead, matching the nav links, which don't have a plain underline either. position:relative is what lets that replacement underline (an ::after pseudo-element, positioned absolutely) anchor itself to this link specifically instead of somewhere else on the page. */ footer .link-danger { color: rgb(255, 255, 255) !important; text-decoration: none; position: relative; } footer .link-danger:hover, footer .link-danger:focus-visible { /* Same grey, same shade, as .nav-link:hover further up this file - see that rule for why it's 205,205,205 and not the slightly darker 185,185,185 it used to be. */ color: rgb(205, 205, 205) !important; } /* The animated underline itself - same left-to-right "grows in on hover" technique, and now the same red accent color, as the 5 main nav links above (search this file for "Underline hover/focus effect" for the fuller explanation of how/why this works). Only real difference left is the thickness: 1px instead of the nav version's 2px, and sitting a few pixels further below the text (bottom: -4px, a negative number, so it's now BELOW the link's own bottom edge instead of hugging just inside it) - both purely because this is a much smaller line of text in a much smaller link, where the nav's own 2px/tighter spacing looked heavy. */ footer .link-danger::after { content: ''; position: absolute; left: 0; bottom: -4px; width: 0%; height: 1px; background-color: #dc3545; transition: width 0.25s ease; } footer .link-danger:hover::after, footer .link-danger:focus-visible::after { width: 100%; } /* "Back to top" up-arrow icon (both pages, bottom-right corner of the footer): plain #dc3545 red, same as everywhere else on the site, no outline/text-shadow on it. It already clears contrast on its own without needing one - it carries Bootstrap's ".h1" size class (40px), well past the 24px cutoff where WCAG relaxes the requirement to 3:1 for large text/icons, and #dc3545 on this dark footer measures 3.41:1, which clears that relaxed bar. (A white, then light-grey, outline was tried here too during an earlier round, alongside the credit link above and the hero's "Specialists" text - pulled back out again on all three, it just didn't look right.) display:inline-block plus the transform/transition below give it a small hover animation to actually signal it's clickable, instead of relying purely on cursor:pointer - nudging upward (translateY, a negative number moves it up) doubles as a small visual hint pointing in the same direction the button itself scrolls the page, with a slight scale-up alongside it for a bit of "lift". display:inline-block is needed for the transform to apply predictably - a plain inline element (what an is by default) doesn't reliably support being moved/scaled like this the way an inline-block or block element does. */ footer .bi-arrow-up-circle { display: inline-block; transition: transform 0.2s ease; } footer a:hover .bi-arrow-up-circle, footer a:focus-visible .bi-arrow-up-circle { transform: translateY(-4px) scale(1.1); } /* "Back to top" link: real tester feedback (Sept 2026) said this was a small tap target on mobile. The measured click box was already fairly generous on paper (this link's own p-3 padding plus the icon's h1 font-size works out to roughly 60x73px, comfortably above the 44px iOS/WCAG minimum) - the real problem is that most of that box is invisible padding a visitor has no way to see, so what they actually aim for is just the small visible circle glyph itself. A bigger VISIBLE icon is a bigger real target, not just a bigger hidden one, so this bumps the icon's size directly (rather than only adding more invisible padding around the same small glyph) and gives it a little extra padding too. Desktop is untouched - nobody's reported this being hard to click with a mouse, and the current size matches this footer's existing visual weight there. */ @media (max-width: 767.98px) { footer a[aria-label="Back to top"] { padding: 1.25rem !important; } footer a[aria-label="Back to top"] .bi-arrow-up-circle { font-size: 3.5rem; } }