/* Theme Name: Levis Child Template: levis Theme URI: https://1.envato.market/wp-levis Description: Insurance WordPress Theme Author: AwaikenThemes Author URI: https://awaikenthemes.com/ Version: 1.0.0 Text Domain: levis-child */ /* Hero carousel: clips a taller figure image to its frame so the figure appears to stand in the section, cut off at the bottom edge. !important is needed here: Elementor's own per-element generated CSS redundantly emits a literal `overflow:visible` on this container regardless of its Overflow control setting, loading after this stylesheet, so a plain declaration gets silently overridden. */ .tnc-hero-figure-frame { overflow: hidden !important; height: 480px; } @media (max-width: 1024px) { .tnc-hero-figure-frame { height: 440px; } } @media (max-width: 767px) { .tnc-hero-figure-frame { height: 360px; } } /* KNOWN PLUGIN WORKAROUND — ElementsKit Advanced Slider fade effect. Confirmed 2026-08-10: cycling through the hero carousel, slides stayed visible after they stopped being active — they piled up instead of fading out. Read Swiper's own fade-effect source (elementor/assets/lib/swiper/v8/swiper.js, function EffectFade): with the default `fadeEffect.crossFade:false` (which this widget has no UI control to change), the opacity formula only fades a slide out once its progress goes negative (already passed); a slide that hasn't yet become active keeps opacity 1 the whole time it's translated into place, relying entirely on Swiper's translate3d positioning — not opacity — to stay out of view. If anything about that offset/position math doesn't resolve the way Swiper expects (we can't confirm exactly why without live devtools), the result is every slide sitting at opacity 1 with no positional offset separating them. Fix: assert the opacity outcome directly from the swiper-slide-active class instead of relying on Swiper's own fade math. This is more robust than patching fadeEffect.crossFade because it doesn't depend on Swiper's internal progress/offset calculation being correct — it just overrides Swiper's own inline opacity styles (hence !important; Swiper re-asserts inline `style="opacity:..."` via jQuery .css() on every transition, which otherwise beats any non-!important stylesheet rule). Scoped tightly to `.hero-slider` — a custom class applied ONLY to this one widget instance (see the slider's own settings in Elementor) — so it cannot affect the ~13 other .swiper-slide elements elsewhere on this page (testimonials, blog cards, etc.) or any other elementskit-advanced-slider instance elsewhere on the site that might use a non-fade effect. If ElementsKit ever exposes a crossFade control or fixes this in the plugin itself, this block can be removed. */ .hero-slider .swiper-slide { opacity: 0 !important; transition: opacity 0.8s ease !important; } .hero-slider .swiper-slide.swiper-slide-active { opacity: 1 !important; } /* Temporarily hides the Home page "Pricing Plan" and "Our Team Support" sections (requested 2026-08-12). Remove this rule (and the tnc-hidden-section CSS class on those two Elementor containers, IDs 6398c21 and 90af8fe) to bring them back. */ .tnc-hidden-section { display: none !important; } /* "More Information" sidebar phone number wrapping (2026-08-12 fix, superseded 2026-09-02): the old fix below patched only the original phone widget's font-size via hardcoded widget IDs (9ad72f8/d281548), working around a global-typography link that made the description text render at an uncontrolled 36px at desktop widths. That link has since been removed at the source — description_typography_typography on all 3 CTA rows (phone/mobile/email, both templates) is now a literal, non-responsive 16px set directly in each widget's own Elementor settings, which is stable across every breakpoint without needing a CSS patch. This hardcoded override became actively harmful once the Mobile/Email rows were added alongside the phone row: being keyed to the phone widget's specific IDs only, it kept forcing 28px/8px-padding on that one row while the new rows correctly rendered the real 16px/ 14px-padding settings, so the three rows disagreed with each other. Removed rather than extended — the root-cause fix in the widget settings makes this file-level patch unnecessary. */ /* Header logo (2026-08-12) — sat hard against the browser edge (20px fixed padding, same at every width) instead of lining up with where the site's boxed page content actually starts. Every content section on this site centers to the Elementor kit's own container_width (confirmed: 1300px, Site Settings > Layout > Content Width) via max-width + auto-centering, not a fixed padding value — so a single fixed px number here could only ever look "aligned" at one specific viewport width. This reproduces that same 1300px cap as a left-padding push on the header's own full-width row (.elementor-element-374d69b), which already carries a plain 10px left/right padding. FIRST ATTEMPT put this same padding on the logo's own narrow flex column (.elementor-element-cbb16b9, width:15% of the row — ~285px at 1920px) instead of the full row. That's structurally wrong: the calc() below evaluates to ~310px at wide viewports, and 310px of padding does not fit inside a ~285px column — confirmed live, it collapsed the column's content box and made the whole logo disappear (0-computed width) rather than just inset it. The full-width row has actual room to absorb this, so the fix lives there instead. Net effect: the whole header's content (logo + nav + "Get A Quote" button) shifts right together, not just the logo — the alignment goal only asked about the logo, but there was no way to move only it without breaking the column, and shifting the row is a legitimate width-changed-so-widget-adjusts state, not a fixed-property crop — this is more consistent besides, since the right side had the exact same "hard against the edge" problem. max(10px, ...) keeps today's 10px floor once the viewport drops to/under 1300px, where the real boxed content itself stops growing too. !important for the same load-order reason documented above this block. */ .elementor-element-374d69b { padding-left: max(10px, calc((100vw - 1300px) / 2)) !important; } /* Green→blue rebrand: overrides parent theme's wp-content/themes/levis/style.css gradient rules, which still hardcode the old teal (rgba(0,79,76,...) / rgba(40,108,94,...)) rather than reading a CSS variable. Editing that parent file directly isn't allowed except for css-variable.css (the one approved exception), so these rules are duplicated here instead, same selector, same specificity, loaded after the parent stylesheet (levis-child-style depends on levis-style) — later source wins on equal specificity. Alpha values and gradient stop positions are copied unchanged from the parent rule; only the RGB triplet changed (#071A51 = rgb(7,26,81)). */ .page-header::before { background: linear-gradient(270deg, rgba(7, 26, 81, 0) 12.16%, rgba(7, 26, 81, 0.00463538) 12.16%, rgba(7, 26, 81, 0.9) 82.49%); } /* BOOKING BUTTON CASING (2026-09-29) — the buttons are stored as "Book a Meeting" (checked: the raw text node is exactly that), but render as "Book A Meeting". The capital A is not in the content: Elementor's global "Accent" typography sets text-transform:capitalize, which is applied to every button on the site via --e-global-typography-accent-text-transform. Fixed here rather than in that global setting, because the global governs every button sitewide — "Send Message", "Contact Now", "Get A Quote" and the rest — and turning capitalize off for all of them to correct one word would be a site-wide restyle nobody asked for. Matched on the Calendly destination rather than on a hand-added class or on element ids: these buttons are defined by where they go, they currently live across five different posts (the header template, three hero slide posts, About Us and Insurance), and keying on the href means any booking button added later picks this up without someone remembering to tag it. !important is needed: Elementor emits per-element rules such as `.elementor-7331 .elementor-element.elementor-element-4e2351e .elementor-button` (four classes) in its per-post CSS, which outranks any reasonable selector written here, and there is one such file per post involved. */ a.elementor-button[href*="calendly.com"], a.elementor-button[href*="calendly.com"] .elementor-button-text { text-transform: none !important; } /* BREADCRUMB FALLBACK (2026-09-29) — reported from the live GoDaddy site as "header breadcrumb becomes a bulleted list on mobile"; the screenshot shows it rendering as `1. Home 2. • 3. Insurance`, stacked and indented. Not a mobile bug, and not a viewport bug — which is why it would not reproduce in a desktop browser's device emulation. The widget outputs `
    ` with one
  1. per crumb, and EVERY part of its appearance (list-style:none, margin/padding reset, display:flex, wrap, alignment, the per-item spacing) comes from a single rule block in elementskit PRO's widget-styles-pro.css, gated behind `.ekit-wid-con`. Checked: elementskit-LITE's copy of that same filename contains no breadcrumb rules at all (zero matches for "ekit-breadcrumb"). So wherever the pro plugin is not active — or its stylesheet does not load, e.g. a host optimiser deferring or stripping it — the
      falls straight back to the browser default of decimal markers, block display and the default indent. That is exactly what the screenshot shows, and it would look the same on that host's desktop view too. These rules restate the structural parts in the child theme, which always loads and does not depend on the pro plugin. Deliberately keyed on `.ekit-breadcrumb` alone rather than `.ekit-wid-con .ekit-breadcrumb`, so it still holds if the wrapper class is absent for the same reason the stylesheet is. Purely structural — colours, fonts and sizing are left to whatever else is loaded, so when the pro stylesheet IS present this changes nothing visible (its rules are identical and win on specificity anyway). Only the decorative `color:red` / `color:#00f` declarations from the pro file are not reproduced; they are overridden downstream in every case. */ .ekit-breadcrumb { margin: 0; padding: 0; list-style: none; display: flex; flex-wrap: wrap; align-items: center; } .ekit-breadcrumb > li { padding-right: 5px; } .ekit-breadcrumb .ekit_breadcrumbs_start { display: flex; justify-content: center; align-items: center; } .ekit-breadcrumb > li i, .ekit-breadcrumb > li svg { position: relative; display: block; width: 1em; height: 1em; } /* Parent's .page-hero-lg::before rule carries !important, so this override needs it too — !important beats specificity/source-order regardless. */ .page-hero-lg::before, .page-hero-lg .elementor-background-video-container::before { /* Peak alpha lowered 0.9 -> 0.55 (2026-09-28), applied site-wide once all sixteen Family A banners were rebuilt. The rebuilt banners sit the photo on a flat #071A51 field instead of a smeared one, and against that the 0.9 overlay read as too much shading closing in from both sides, leaving the photograph muddy. It costs nothing in title contrast, which is why it is safe to go this far: the baked fill and this overlay are the SAME colour, so the flat navy either side renders identically at any alpha and only the photo is affected — and at desktop widths the h1 sits over that flat navy, not over the photo. Measured on About Us: 10.6:1 at 0.9 vs 11.8:1 at 0.55 (1440px), and 15.1:1 vs 13.5:1 at 390px where the h1 does overlap the photo. Everything tested stayed far above the 4.5:1 threshold; 0.40 was also built and is available if more is ever wanted. Stop positions are deliberately unchanged from the original rule. */ background: linear-gradient(270deg, rgba(7, 26, 81, 0) 12.16%, rgba(7, 26, 81, 0.004) 12.16%, rgba(7, 26, 81, 0.55) 82.49%) !important; } .contact-cta-image::before { background: linear-gradient(270deg, rgba(7, 26, 81, 0) 40.47%, rgba(7, 26, 81, 0.009) 40.47%, rgba(7, 26, 81, 0.9) 91.67%); } .pricing-item.highlighted-box::before { background: linear-gradient(180deg, rgba(7, 26, 81, 0) 0%, rgba(255, 255, 255, 0.12) 100%); }