/* EventPixHub embed test - simple, clean, own design (not a clone of any reference site) - just reusing the same content: logo, Events/About/ Contact nav, a footer with links + social. */ html, body { background: #ffffff !important; } /* Tells the embed widget's own sticky icon rail how tall this site's real sticky nav bar is, so the rail clears it instead of sitting underneath - custom properties pierce the Shadow DOM boundary, so this reaches every [data-eventpixhub-embed] instance on the page even though nothing else here can style their actual contents. See resources/js/widget/main.ts's own --epx-rail-top comment (event_pix_hub repo). */ :root { --epx-rail-top: 73px; } /* ── Header: vertical - logo centered on top, nav centered below - black background (the theme's old float-era clearfix pseudo-elements, `.site-header:before/:after { display: table }`, become real flex items once this is display:flex - killed below, that was the stray layout artifact). ── */ #page, #masthead, .site-header { max-width: none !important; width: 100% !important; } .site-header { background: #1B1C25; padding: 12px 32px; display: flex; flex-direction: column; align-items: center; justify-content: center; gap: 8px; box-sizing: border-box; } .site-header::before, .site-header::after { content: none !important; display: none !important; } /* Real bug found live (2026-08-25) - "logo goes halfway out of screen to the left, space on the right" (asymmetric, not just "too big"). Root cause: style.css's own `.site-header.has-logo.has-title-and-tagline { align-items: flex-start; }` (3-class selector) outranks the plain `.site-header { align-items: center; }` above (1-class) regardless of this stylesheet loading after style.css - specificity beats source order. This site's header always carries both classes (a logo AND a tagline are set via Site Identity), so `.site-branding` was left-aligned inside `.site-header`'s column flex layout instead of centered - and since the logo image (2222x444 natural, height:120px here → ~600px rendered) is far wider than `.site-branding`'s own resulting box, the image (centered *within that already-left-shifted box* via `.site- branding`'s own justify-content:center) overflowed almost entirely to the left instead of spilling evenly both ways. Confirmed via full matched-CSSRule walk (recursing into every stylesheet incl. style.css) before concluding this was the actual winning rule, not guessed from the symptom alone. Matches the theme's own selector exactly so this wins on source order at equal specificity, rather than reaching for `!important`. */ .site-header.has-logo.has-title-and-tagline { align-items: center; } .site-branding { display: flex; align-items: center; justify-content: center; margin: 0; } .site-logo { margin: 0; } .site-logo img { display: block; height: 120px; width: auto; } /* Text fallback (site-branding.php) for whenever no logo is set via Appearance > Customize > Site Identity - matches the wordmark's own sizing/weight instead of falling back to unstyled default text. */ .site-logo-text { display: block; color: #fff; font-size: 32px; font-weight: 800; letter-spacing: -0.02em; } .site-header .site-description { display: none; } /* Sticky on scroll (2026-08-23, per direct request), moved to be a sibling of #masthead rather than nested inside it (2026-08-24, real bug found live: "wordpress nav and minicart badge is not being sticky") - position:sticky only keeps an element pinned for as long as its own CONTAINING BLOCK is still in view. #masthead is a short box (just the logo + its own padding, ~250px), so nesting the nav inside it meant the nav released from "stuck" the moment the page scrolled past that short header - it wasn't really sticking for the vast majority of a real page's scroll depth. See template-parts/header/site-header.php's own comment on the markup change. Now a plain full-width block (no negative margin needed any more - that was only ever cancelling out .site-header's own padding while this was nested inside it; at this level there's no parent padding to cancel, so the same trick used to overflow the viewport by 32px on each side once the nesting changed). */ .primary-navigation { position: sticky; top: 0; z-index: 100; box-sizing: border-box; background: #1B1C25; padding: 14px 32px; display: flex; align-items: center; justify-content: center; gap: 100px; } .primary-navigation .menu-wrapper { display: flex; flex: 1; justify-content: center; gap: 16px; list-style: none; margin: 0; padding: 0; } .primary-navigation .menu-wrapper > li > a { color: #ffffff; font-weight: 600; text-decoration: none; font-size: 16px; } .primary-navigation .menu-wrapper > li > a:hover { opacity: .7; } /* The EventPixHub cart widget mount (see template-parts/header/site-nav.php) - a Shadow DOM boundary starts right at this div, so nothing here styles its actual contents; this just keeps it from collapsing/shrinking in the flex row. */ .primary-navigation__cart { flex-shrink: 0; } /* 1200px cap for the "all events" listing (reads better at that width), but NOT while a single event is open inside the same embed instance - the widget mirrors its own current sub-view onto its mount
via data-current-view (see resources/js/widget/main.ts's own comment on this), so #content:has(...) can react to it even though it can't see inside the widget's own Shadow DOM otherwise. (2026-08-24, re-added after briefly being removed entirely - per direct request, "for all embed events page we still need 1200px max width - but not for single event embed".) */ #content { max-width: 1200px; margin: 0 auto; padding: 0 32px; background: #fff; } #content:has([data-eventpixhub-embed][data-current-view="event"]) { max-width: none; } /* Tighter side padding on mobile, embed pages only (2026-08-25, per direct request) - the embed widget's own photo grid pairs this exact 8px with a matching negative-margin/width bleed on its own .epx-jrow rows (see resources/js/widget/main.ts in the event_pix_hub repo) so photos reach the real viewport edge instead of sitting inset twice (once from this padding, once from the widget's own). Scoped to :has([data-eventpixhub- embed]) - any page with an embed mounted, not just the single-event view - rather than the narrower :has(...[data-current-view="event"]) above, since the events-list toolbar also benefits from the extra width on a small screen. */ @media (max-width: 860px) { #content:has([data-eventpixhub-embed]) { padding: 0 8px; } } /* Kills the theme's own default post-content bottom spacing (.site-main's own padding-bottom plus .entry-content's margin, Twenty Twenty-One's global --global--spacing-vertical cascade) - was leaving a large empty gap between the embed widget's own content and the footer. */ .site-main { padding-bottom: 0 !important; } .entry-content, .entry-content > * { margin-bottom: 0 !important; } /* ── Footer ── */ #colophon, .site-footer { max-width: none !important; width: 100% !important; } #colophon.site-footer { background: #1B1C25; color: #fff; box-sizing: border-box; } .site-footer::before, .site-footer::after { content: none !important; display: none !important; } .epx-footer-inner { max-width: 1200px; margin: 0 auto; padding: 64px 32px 32px; } .epx-footer-top { display: grid; grid-template-columns: 2fr 1fr 1fr; gap: 48px; } .epx-footer-brand { max-width: 340px; } .epx-footer-wordmark { font-size: 28px; font-weight: 800; letter-spacing: -.02em; } .epx-footer-address { color: rgba(255,255,255,.7); font-size: 14.5px; line-height: 1.9; margin: 18px 0 0; } .epx-footer-address a { color: rgba(255,255,255,.7); text-decoration: underline; } .epx-footer-address a:hover { color: #fff; } .epx-footer-powered { color: rgba(255,255,255,.5); font-size: 13.5px; margin: 22px 0 0; } .epx-footer-powered a { color: rgba(255,255,255,.75); text-decoration: underline; } .footer-navigation { margin-top: 0; } #colophon .footer-navigation-wrapper { list-style: none; margin: 0; padding: 0; display: flex; flex-direction: column; gap: 12px; } #colophon .footer-navigation-wrapper li { line-height: 1.5; } #colophon .footer-navigation-wrapper a { color: rgba(255,255,255,.85); text-decoration: none; font-size: 15px; } #colophon .footer-navigation-wrapper a:hover { color: #fff; } .epx-footer-social { display: flex; gap: 12px; } .epx-social-icon { display: flex; align-items: center; justify-content: center; width: 38px; height: 38px; border-radius: 999px; background: rgba(255,255,255,.1); color: #fff; transition: background .15s ease, transform .15s ease; } .epx-social-icon:hover { background: #fff; color: #1B1C25; transform: translateY(-2px); } .epx-social-icon svg { width: 17px; height: 17px; } @media (max-width: 782px) { .site-header { padding: 16px 20px; gap: 24px; } .site-logo img { height: 72px; } .site-logo-text { font-size: 20px; } .primary-navigation { padding: 12px 20px; flex-wrap: wrap; row-gap: 10px; } .primary-navigation .menu-wrapper { gap: 20px; flex-wrap: wrap; justify-content: center; } .epx-footer-top { grid-template-columns: 1fr; gap: 32px; } .epx-footer-inner { padding: 48px 20px 24px; } } /* ── Mobile nav (2026-08-25) - the theme's own #primary-mobile-menu button markup was reinstated in template-parts/header/site-nav.php (see that file's own comment) after discovering the nav was unreachable below ~481px with no toggle button in the markup for style.css's default hide/show pair (.menu-button-container shown, .primary-menu-container hidden, both at max-width:481.98px) to act on. Our own header is a fully custom sticky flex row (logo centered on top, nav centered below - see .site-header/.primary-navigation above), not the stock theme's absolute-positioned top-right nav this toggle machinery/animation was originally built for. Rather than fight that stock fixed-overlay/z-index/transform choreography on top of a base layout it doesn't match, this defines its own plain open/closed treatment at the exact same 481.98px breakpoint style.css already uses for the button/menu pair, so there's no seam between "button appears" and "this styling kicks in." style.css's own JS (assets/js/ primary-navigation.js, still enqueued) is untouched - it still just toggles `.primary-navigation-open` on and handles aria-expanded/ focus-trap/Escape, all of which this reuses as-is. Burger on the left, cart pinned right (2026-08-25, per direct request: "480px and below show proper burger menu and cart on the right side") - `justify-content: space-between` on the now 2-visible-child row (.menu-button-container + .primary-navigation__cart; .primary-menu- container is display:none until opened, so it doesn't occupy a third flex slot in between them). ── */ @media only screen and (max-width: 481.98px) { /* Two real style.css leftovers found live (2026-08-25) - both built for the stock theme's own absolute-positioned top-right nav (logo left, menu button/nav pinned top-right beside it), which this site's fully custom header never used at all: - `.site-header.has-logo.has-title-and-tagline.has-menu { justify- content: space-between; }` (4-class specificity, beats our own plain `.site-header { justify-content: center }`) - with `#masthead` now holding only the logo as its one child (see the single-row redesign below), space-between would left-align it instead of centering it (space-between collapses to flex-start with a single item). - `.site-header.has-logo.has-title-and-tagline.has-menu .site-branding { max-width: calc(100% - 160px); }` - reserved room for a menu button that, in this header, was never actually beside the logo in the first place. No longer visibly clips anything at the smaller logo size below, but left in place it's still a landmine waiting for the next size change - direct request: "there is no rule for this needed... its fine for it to be 100% if needed to." */ .site-header.has-logo.has-title-and-tagline.has-menu { justify-content: center; } .site-header.has-logo.has-title-and-tagline.has-menu .site-branding { max-width: none; } /* Single row - burger, logo, cart - instead of two stacked rows (2026-08-25, per direct request: "on smaller devices maybe we can fit logo between burger and cart and some spacing, its ok that its a bit smaller"). `#masthead` (the logo) and `.primary-navigation` (burger/ nav-list/cart) are separate top-level siblings in the actual markup (see header.php/site-header.php - moved apart back on 2026-08-24 for an unrelated sticky-positioning fix), not two children of one shared flex container, so there's no DOM-only way to interleave them into a literal single row. Instead, `#masthead` is pulled out of the normal document flow entirely (position: absolute) and overlaid directly on top of `.primary-navigation`'s own row - same top offset, same height, transparent background - so the logo appears to sit "in" that row without actually needing to. `.primary-navigation`'s own `justify-content: space-between` already keeps the burger flush left and cart flush right, leaving the whole middle open for the logo to occupy with real spacing on both sides. */ #masthead { /* position: fixed, not absolute (2026-08-25, real bug found live - "when scrolling logo is not fixed together with the rest of the menu"). position: absolute here was relative to #page (the whole document's own height), so it stayed pinned to the *page's* top edge and scrolled away with the rest of the content while .primary-navigation (position: sticky) stayed pinned to the *viewport's* top edge - the two drifted apart the moment the page scrolled. Both need to track the viewport the same way. fixed with top: 0 always lands in the same spot .primary-navigation's own sticky top: 0 does (whether unscrolled - masthead is out of flow so nav is the first in-flow element and naturally starts at y:0 anyway - or scrolled past that point, where sticky pins nav at y:0 too), so the two stay visually locked together at every scroll position. #page's own position: relative (needed for the old absolute approach) is no longer needed either. */ position: fixed; top: 0; left: 0; right: 0; height: 68px; /* .primary-navigation's own real rendered height here - confirmed via getBoundingClientRect(), not guessed */ padding: 0; background: transparent; /* Transparent everywhere except the logo's own pixels, so the burger/ cart underneath (in z-order) stay visible and clickable through it - only the logo's own link needs pointer-events re-enabled below. */ pointer-events: none; z-index: 150; /* above .primary-navigation's own z-index: 100 */ } /* Only the actual link, not .site-branding itself (2026-08-25, real bug found live) - .site-branding is a flex item with no explicit width, sized as wide as #masthead's own flex row lets it be, well beyond the logo's own visible pixels; giving IT pointer-events:auto reopened a wide invisible hit-area that blocked clicks meant for the burger button underneath, confirmed via Playwright ("site-branding intercepts pointer events" on a click aimed at #primary-mobile-menu). The link tightly hugs the actual logo image, so scoping pointer-events:auto to just that keeps the passthrough everywhere else intact. */ #masthead .site-branding a { pointer-events: auto; } /* Real overlap found live at 320px (2026-08-25) - a fixed height:40px always renders this logo's wide (~5:1) aspect ratio at ~200px wide regardless of viewport, which doesn't leave enough of the ~193px available between the burger (ends ~63px in) and cart (starts ~64px from the right edge) on the narrowest real phones. `max-height` + `max-width` together (both `auto` dimensions, no fixed `height` this time) let the browser shrink proportionally to whichever constraint actually binds - full 40px tall from ~375px up, narrower than that only on genuinely tight widths - rather than a fixed height that can overflow, or a fixed max-width alone that would squish the aspect ratio instead of shrinking it cleanly. A second real bug caught before shipping: `max-width` as a plain `%` resolves against `.site-logo` (the wrapping ), which shrink-wraps to its own content's *preferred* size - computed from `max-height` alone, ignoring the percentage max-width dependency, i.e. it always shrink-wraps to ~200px (the height:40px-implied width) regardless of the percentage rule sitting right next to it. That gave `calc(100% - 150px)` a fixed 200px to resolve against, not the viewport, so the image itself then shrank to just 50px (calc(200px - 150px)) while its own parent stayed at the full 200px - miles smaller than intended, confirmed via computed-style + parent-width inspection before finding the fix. Using `100vw` instead of `100%` resolves against the actual viewport width directly, sidestepping this shrink-wrap circularity entirely - #masthead already spans the full viewport width edge to edge here anyway, so this is the same real quantity either way, just without the broken indirection. */ .site-logo img { height: auto; width: auto; max-height: 40px; max-width: calc(100vw - 150px); } /* Burger a bit closer to the left edge, cart a bit closer to the right (2026-08-25, per direct request: "move hamburger a bit more left - maybe 20px just estimating - for minicart icon maybe 5px to the right just to save a bit of space on mobile") - overrides the 20px/20px symmetric inset inherited from the 782px breakpoint above with separate, smaller values for each side. */ .primary-navigation { justify-content: space-between; gap: 0; padding-left: 8px; padding-right: 15px; } .menu-button-container { position: static; padding: 0; } .menu-button-container #primary-mobile-menu { display: flex; align-items: center; gap: 8px; padding: 6px; color: #fff; font-size: 14px; font-weight: 600; background: transparent; } .menu-button-container #primary-mobile-menu .dropdown-icon { gap: 6px; } /* ~18% bigger than the original 22px (2026-08-25, per direct request - "make it a bit bigger, not much maybe 10-20% bigger"), now that the button is icon-only (see site-nav.php's own comment) with no adjacent text to visually balance against any more. */ .menu-button-container #primary-mobile-menu svg { width: 26px; height: 26px; } /* Closed by default - style.css's own transform/opacity/visibility choreography is overridden wholesale here rather than layered on top of, since it assumes a different (absolute-positioned) base layout. */ .primary-navigation > .primary-menu-container { display: none; } .primary-navigation-open .primary-navigation > .primary-menu-container { display: block; position: absolute; top: 100%; /* Explicit, not left off (2026-08-25, real bug found live) - style.css's own base rule sets `inset: 0` (a shorthand for top/right/bottom/left all 0), and since this rule never named `bottom` itself, that longhand kept winning underneath it. With both top (100%, i.e. the bottom edge of .primary-navigation) and bottom (0, the same edge) pinned to the identical point, height:auto had nothing to resolve to but 0 - the dropdown collapsed to just its own padding (28px) with the real menu list rendering, but clipped away beneath it. Confirmed via computed-style inspection before landing this fix. */ bottom: auto; left: 0; right: 0; height: auto; z-index: 200; visibility: visible; opacity: 1; transform: none; border: none; background: #1B1C25; padding: 8px 20px 20px; } .primary-navigation .menu-wrapper { flex-direction: column; align-items: stretch; gap: 4px; } .primary-navigation .menu-wrapper > li > a { display: block; padding: 10px 0; } /* Keep the button's own dark styling instead of style.css's default light --global--color-background swap, which would clash with this header's black background. */ .primary-navigation-open .menu-button-container { width: auto; background-color: transparent; } .primary-navigation__cart { order: 2; } /* Real bug found live (2026-08-25) - "mobile menu should also be position absolute when open... it should go over the content not extend the header." style.css's own open-state rule (`.primary- navigation-open .primary-navigation { width: 100%; position: fixed; z-index: 2; }`) swaps our own `.primary-navigation` from `position: sticky` (which reserves its own ~68px in the page's normal flow, same as before opening) to `position: fixed` (which reserves none) - so the instant the menu opens, that reserved 68px vanishes from flow and every real page element below shifts up to fill the gap, underneath the now-floating nav + its absolutely-positioned dropdown. Visually indistinguishable from "the dropdown pushed the header taller" in a single screenshot, but confirmed via computed-style inspection this was really a flow-collapse, not the dropdown's own sizing. Fixed by keeping `.primary-navigation` on `position: sticky` in the open state too (equal 2-class specificity to style.css's own selector, wins here on source order since this file loads after style.css) - its own box height never changes between open/closed (always just the burger+cart row; `.primary-menu-container` was already taken out of flow via `display: none`/`position: absolute` in both states), so opening the menu no longer shifts anything below it - the dropdown (already `position: absolute`, `z-index: 200`) purely overlays whatever page content happens to sit underneath it. */ .primary-navigation-open .primary-navigation { position: sticky; width: auto; } } /* ── Grappling Industries brand pass (2026-10-10) - header/footer cloned from grapplingindustries.com's own real Elementor kit colors (#1B1C25 dark bg, #E17E26 accent, Roboto/Roboto Slab) rather than the site's own generic dark theme above - additive only, doesn't touch any of the hard-won responsive/sticky fixes already in this file. ── */ @import url('https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;600;700&family=Roboto+Slab:wght@600;700&display=swap'); body, .primary-navigation .menu-wrapper > li > a, .site-logo-text { font-family: 'Roboto', Arial, sans-serif; } .epx-footer-wordmark { font-family: 'Roboto Slab', serif; } /* Real accent color on hover/active instead of the generic opacity dim - matches grapplingindustries.com's own nav hover treatment. */ .primary-navigation .menu-wrapper > li > a:hover, .primary-navigation .menu-wrapper > li.current-menu-item > a { opacity: 1; color: #E17E26; } /* ── Dropdown submenus (Events > Upcoming/Past, Info > Rules/Divisions) - the theme's own wp_nav_menu() output already nests these as a plain