/* Trigger Button Base */
.tg-oc-trigger {
    border: none;
    cursor: pointer;
    display: inline-flex;
    align-items: center;
    gap: 10px;
    transition: all 0.3s ease;
}

/* Ensure icons are visible and aligned */
.tg-oc-icon {
    display: inline-flex;
    line-height: 1;
    align-items: center;
    justify-content: center;
}

.tg-oc-icon i {
    width: 1em;
    height: 1em;
    font-size: 1.2em;
    display: block;
}

.tg-oc-icon svg {
    width: 20px;
    height: auto;
    fill: currentColor;
}

/* Overlay (Hidden by Default) */
.tg-oc-overlay {
    position: fixed;
    inset: 0;
    z-index: 99998;
    opacity: 0;
    visibility: hidden;
    transition: opacity 0.4s ease, visibility 0.4s ease;
    /*
     * A CLOSED overlay must never be hit-testable — structurally, not by looking invisible.
     *
     * opacity and visibility are both reachable by Elementor's per-instance CSS, which outranks
     * this rule; when the Overlay Opacity control held the closed overlay at 0.6 it stayed a
     * full-viewport clickable layer and swallowed every click on the page (the hamburger included
     * — elementFromPoint over the button returned the overlay). pointer-events is not driven by
     * any control, so it stays a reliable floor: even if some future rule makes the closed overlay
     * visible again, it cannot intercept input.
     */
    pointer-events: none;
}

.tg-oc-overlay.tg-oc-active {
    opacity: 1;
    visibility: visible;
    pointer-events: auto;
}

/* Panel Structure (Hidden by Default) */
.tg-oc-panel {
    position: fixed;
    top: 0;
    bottom: 0;
    height: 100vh;
    z-index: 99999;
    overflow-y: auto;
    box-shadow: 0 0 40px rgba(0,0,0,0.15);
    transition: transform 0.4s cubic-bezier(0.77, 0, 0.175, 1);
    /* Sane default size + fill. The per-instance width/background Elementor generates is scoped
       `.elementor-<post> .elementor-element-<id> .tg-oc-panel`, so it always wins over these. They
       exist purely so the panel can never render unusable if that scoped rule doesn't match (stale
       regenerated CSS, an unexpected wrapper) — without a width the panel shrinks to its content. */
    width: 320px;
    /*
     * The PANEL's own Width control governs — never the bound template, never an arbitrary cap.
     *
     * This was `max-width: 85vw`, a plugin-imposed limit that silently overrode the user's setting:
     * a panel configured to 800px on mobile rendered at 301px (85% of 354) with no indication why,
     * so the Width control simply looked broken on phones.
     *
     * The only cap that remains is the screen itself, because a drawer wider than the viewport
     * cannot be reached. --tg-oc-vw is the measured visual viewport (see the directional block
     * below), so the panel honours whatever width is configured, right up to full-screen, and stays
     * flush to the edge at every size.
     */
    max-width: var(--tg-oc-vw, 100vw);
    /*
     * The template inside must never widen the panel.
     *
     * A bound template is arbitrary user content and routinely contains fixed-width containers
     * (the live home page has one hardcoded to 1200px). Without this, such content spills out of
     * the drawer and drags a horizontal scrollbar across the page. Clipping on the panel keeps the
     * panel's own width authoritative WITHOUT restyling the template itself — no widths, colours or
     * spacing inside the template are touched, so it still renders exactly as designed.
     */
    overflow-x: hidden;
    background-color: #fff;
}

/*
 * Directional sliding logic — anchored to the LEFT edge in both directions, deliberately.
 *
 * A right-anchored drawer (`right: 0`) is positioned against the right edge of the containing
 * block. That edge is not something this plugin controls: any theme, page or template can widen
 * the layout with horizontally-overflowing content, and the drawer then slides to the right edge
 * of the OVERFLOW rather than of the screen — opening completely outside the visible viewport.
 *
 * Measured on the live home page at a 430px viewport: one Elementor container carried a hardcoded
 * `width: 1200px` with no mobile override, centring at x=-385 and pushing document.scrollWidth to
 * 815. The drawer opened correctly against 815 and was therefore never on screen. Nothing was
 * wrong with the drawer; it was anchored to a box the page had stretched.
 *
 * `left: 0` cannot be moved by right-side overflow, so it is a stable origin on every site. The
 * drawer is then placed with a transform measured against the real viewport:
 *
 *   closed → translateX(--tg-oc-vw)            (just past the right edge of the screen)
 *   open   → translateX(--tg-oc-vw - 100%)     (flush to the right edge; % = the panel's own width)
 *
 * --tg-oc-vw is published by tiger-offcanvas-script.js from visualViewport.width (falling back to
 * documentElement.clientWidth), so it tracks the SCREEN,
 * never the document. The 100vw fallback
 * keeps this correct if the script is unavailable, and both stay animatable because only
 * `transform` changes. Fixed-position elements do not contribute to scrollable overflow, so a
 * drawer parked off-screen this way cannot itself introduce a horizontal scrollbar (verified:
 * removing the portal changed document.scrollWidth by 0).
 *
 * Left-hand drawers were never exposed to this — their anchor is the same stable edge — so their
 * geometry is unchanged.
 */
/*
 * Viewport re-measure must not animate.
 *
 * tiger-offcanvas-script.js sets this class for one frame while it updates --tg-oc-vw. Without it
 * the CLOSED drawer transitioned between the old and new viewport widths — a mobile-to-desktop
 * switch swept it across the whole screen and read as a blink. Scoped to this one mutation, so the
 * open/close slide is unaffected.
 *
 * !important is required and safe here: Elementor's per-instance rule sets transition-duration at
 * a higher specificity, and this state lasts a single frame.
 */
.tg-oc-vw-sync .tg-oc-panel,
.tg-oc-vw-sync .tg-oc-overlay {
    transition: none !important;
}

.tg-oc-dir-left {
    left: 0;
    right: auto;
    transform: translateX(-105%);
}

.tg-oc-dir-right {
    left: 0;
    right: auto;
    transform: translateX(var(--tg-oc-vw, 100vw));
}

.tg-oc-dir-left.tg-oc-active {
    transform: translateX(0);
}

.tg-oc-dir-right.tg-oc-active {
    transform: translateX(calc(var(--tg-oc-vw, 100vw) - 100%));
}

/* Close Button */
.tg-oc-close {
    position: absolute;
    top: 15px;
    right: 20px;
    background: transparent;
    border: none;
    font-size: 30px;
    line-height: 1;
    cursor: pointer;
    z-index: 2;
    transition: transform 0.3s ease;
}

.tg-oc-close:hover {
    transform: rotate(90deg);
}

/* Content Wrapper */
.tg-oc-content {
    position: relative;
    z-index: 1;
    height: 100%;
    /*
     * Give the template a box that is exactly the panel's inner width to lay out against, so
     * percentage- and full-width sections resolve to the DRAWER rather than to the page. This is a
     * containing-block constraint, not styling: no template rule is overridden, nothing inside is
     * restyled — the template simply renders into the width the off-canvas is configured to be.
     */
    max-width: 100%;
}
/* ==========================================================
   NO THEME ISOLATION HERE — deliberately.

   The off-canvas panel is a CONTAINER for arbitrary user widgets, not a menu. An earlier
   version carried the same link-reset the menu widgets use:

       .tg-oc-panel a { color: inherit; background: none; box-shadow: none; }

   `background` is the SHORTHAND, so it also reset background-image — which silently killed the
   gradient on every `.tiger-cbtn--gradient` button dropped into a panel. The button kept its
   white text and lost its background: invisible on a white panel, and it looked like the widget
   had vanished entirely.

   Isolation is correct for the MENU widgets, whose links we own and which a theme's `a` rules
   would otherwise capture. It is wrong here: the panel must render whatever the user built,
   untouched. Panel = transport, not stylist.
   ========================================================== */


` and it was injecting spacing into the menu in the
       editor while the front end (portaled out of that scope) showed none. Still below any
       Elementor control (0,4,2), so user settings continue to win, and no !important. */
    margin-block-start: 0;
    margin-block-end: 0;
}