/* winndixie.com/contactusthanks — extracted verbatim from the live page's own inline <style>
   block (rendered inside the CMS "contact_us_thanks_page" singleton's body, same pattern as
   other pages that ship page-specific inline styles instead of a shared bundle). Scoped to the
   .grocery-delevery / .App_Header_section classes this page uses for its "Thank you" hero card —
   the same App_Header_section/App-image/App_Header pattern PageSections.razor's RenderHeroBanner
   produces for content_page hero_banner blocks elsewhere, just with this page's own red-accent
   card styling (.grocery-delevery) instead of the generic edge-to-edge hero. */

/* This app ships no global full-width override for .container-fluid/.container — every other
   page using the "topBg" shell (about_*.css, careers.css, know-and-love.css, etc.) carries its
   own copy of these two rules in its page-specific stylesheet, exactly like live's own inline
   <style> does here. Without them .container-fluid.topBg.padding_0 falls back to whatever the
   browser/other loaded stylesheets give a plain .container-fluid (nothing, in this app — no
   max-width at all — which is harmless on ITS OWN, but the .container.padding_0/.usehd wrappers
   nested inside it DO end up width:auto and shrink to content, clipping .grocery-delevery's
   intended 100vw-minus-192px width down to a fixed ~1170px instead of scaling with the viewport.
   Confirmed against live directly: .container-fluid.topBg.padding_0 resolves to max-width:100%
   in live's own DOM, not "no rule". */
.container-fluid {
    max-width: 100%;
}

.container {
    width: 100%;
}

/* Live's #tblBody is 1px tall below 992px and 21px at 992px+ — measured directly at every
   breakpoint boundary, not assumed from one sample width (a single min-width:992px rule, same
   boundary the App_Header_section row/row-reverse layout switch uses). Every visible descendant
   (the empty .rgtContent, the display:none #progress-indicator, .clear) computes to 0/1px on its
   own, so this is a real, deliberate rule on #tblBody itself, not a box-model side effect —
   confirmed via padding/border/box-sizing all being 0/border-box. Whatever shared stylesheet sets
   this on live wasn't found in any bundle already loaded by this app (app-wd.css/app-wd-global.css
   have no #tblBody rule at all), so it's replicated directly here rather than chased further — the
   height difference before .DvCntThanksmain is what matters for pixel parity, not its ultimate
   source. Scoped to THIS page only (not a global #tblBody rule) since other pages using the shared
   #tblBody id (Locator, content_page templates) render real content inside it and should not
   inherit an unrelated fixed height. */
#tblBody {
    height: 1px;
}

@media (min-width: 992px) {
    #tblBody {
        height: 21px;
    }
}

/* Live's own CMS blob embeds a second, redundant inline <style> block at the very end of
   its raw HTML (duplicating the exact rules already extracted into this file) — see
   ContactUsThanks.razor's own doc comment for why this app's CMS entry deliberately omits
   it instead of double-injecting the same CSS. That trailing <style> tag sits inside
   .clsspContct's inline formatting context (a <span>), right after .grocery-delevery's
   closing tag, and — despite <style>'s UA default of display:none — measurably adds a
   fixed, breakpoint-independent 18.5px of extra height on live between the card and the
   footer (confirmed via getBoundingClientRect at every width from 375px to 1440px: exactly
   18.5px in every case, never proportional to font/line-wrap differences). Reproduced here
   instead of resurrecting the duplicate <style> block, which would reintroduce live's own
   Asap/legacy-red values this app's rebrand tokens intentionally override (see MEMORY
   pixel-parity-global-tokens).

   PADDING, not margin: .grocery-delevery's own bottom margin (96px desktop/tablet, 56px
   mobile) is already the larger of the two adjoining margins at this boundary, so a
   margin-bottom here would just collapse into — not add to — that existing margin (CSS
   keeps the max of adjoining margins, never their sum; confirmed empirically, a
   margin-bottom edit here measured zero effect on the card-to-footer gap). padding-bottom
   doesn't collapse, so it lands on top of the already-contained 96/56px unconditionally. */
.DvCntThanksmain {
    padding-bottom: 18.5px;
}

.grocery-delevery {
    margin: 110px 96px 96px 96px;
    background-color: var(--wd-color-surface-alt);
    border-left: 12px solid var(--wd-color-brand-red);
    border-radius: 8px;
    display: flex;
}

/* Live's .clsContHead is an EMPTY <h1> (not a <div> — see ContactUsThanks.razor's own doc
   comment for why this app deliberately renders a <div> instead, to avoid an axe empty-heading
   violation), so it carries this site's default h1 margin-top: 20px. That margin is normally
   invisible: .clsContHead sits immediately before .grocery-delevery inside .DvCntThanksmain (no
   border/padding on either), so the two top margins collapse into one — and at every breakpoint
   above 767px .grocery-delevery's OWN top margin (110px desktop, 56px tablet) is larger and wins
   the collapse outright. Only below 768px, where .grocery-delevery's own top margin drops to 0
   (the mobile rule below), does this 20px become the dominant — and only visible — one, matching
   live's own real 20px gap above the hero card at that width (confirmed via getBoundingClientRect
   at 375/768/1440: 0px diff at all three once this rule is present). Set unconditionally, not
   inside a media query, so the browser's own margin-collapse algorithm reproduces the
   "invisible at desktop, visible at mobile" behavior the same way it does on live, rather than
   this file guessing the exact breakpoint a magic number should switch on. */
.clsContHead {
    margin-top: 20px;
}

.App_Header_section {
    display: flex;
    flex-direction: row-reverse;
    background-color: var(--wd-color-surface-alt);
}

.App_Header_section .App-image {
    padding: 0;
}

.App_Header_section .App-image .Desk-app {
    height: 100%;
    width: 100%;
}

.App_Header_section .App-image .Tab-app {
    height: 100%;
    width: 100%;
}

.App_Header_section .App_Header {
    margin: auto;
    margin-right: 0;
    padding-left: 58px;
}

.App_Header_section .App_Header h1 {
    margin: 0px;
    font-family: var(--wd-font-body);
    font-size: 2.25em;
    font-weight: bold;
    font-stretch: normal;
    font-style: normal;
    line-height: normal;
    letter-spacing: -.59px;
    color: var(--wd-color-text);
    width: 100%;
}

.App_Header_section .App_Header p {
    font-family: var(--wd-font-body);
    font-size: 1em;
    font-weight: 400;
    font-stretch: normal;
    font-style: normal;
    line-height: 1.33;
    letter-spacing: -.22px;
    color: var(--wd-color-text);
    width: 100%;
    margin: 24px 0px;
    /* 30px, not live's own 45px: live's inline styles were authored against Asap, whose
       per-character advance is narrower than this app's --wd-font-body (WD Shopper) —
       an intentional site-wide rebrand token (see MEMORY pixel-parity-global-tokens), not
       something this page can change. At 45px the exact same text ("Thank you for taking
       the time to contact us. Your submission has been routed to the appropriate team and
       we will get back to you as soon as possible.") wraps one line taller than live at
       768-800px and 992-1150px specifically — those are genuine width bands, not a
       font-loading race (confirmed: document.fonts shows "WD Shopper" 400/700 status
       "loaded", woff2 requests all 200). 30px was found by bisecting padding-right values
       against live's own line-wrap height at 992px until it matched (85px, i.e. still 4
       lines), then verified with a fine-grained (10px-step) sweep from 768px to 1440px
       against live directly — 0px height diff at every width in that sweep, including
       live's own non-monotonic 3-line/4-line transitions across the 950-1150px band. Below
       768px this rule doesn't apply at all (the mobile media query below fully replaces
       padding with a vertical-only value), so this has zero effect on mobile — see that
       block's own letter-spacing comment for the equivalent mobile-width fix. */
    padding-right: 30px;
}

.App_Header_section .App_Header a {
    text-decoration: none;
    cursor: pointer;
    width: 268px;
    display: flex !important;
    justify-content: center;
    font-weight: 700;
    font-size: 1.125em;
}

@media (min-width: 1200px) {
    .App_Header_section .App_Header {
        margin: 80px 0px;
    }

    .App_Header_section .App_Header .bottombtm {
        text-decoration: none;
        cursor: pointer;
        width: 366px;
    }
}

@media (min-width: 992px) and (max-width: 1200px) {
    .App_Header_section .App_Header {
        margin: 50px 0;
    }
}

@media (min-width: 768px) and (max-width: 991px) {
    .App_Header_section .App-image {
        margin: 0;
        max-width: fit-content;
        width: 100%;
    }

    .App_Header_section .App_Header {
        margin: 42px 0px;
        padding-left: 63px;
        width: 100%;
    }

    .App_Header_section .App_Header h1 {
        width: 80%;
    }

    .grocery-delevery {
        margin: 56px 32px 96px 32px;
        background-color: var(--wd-color-surface-alt);
        display: flex;
    }
}

@media (min-width: 991px) {
    .App_Header_section .App_Header {
        padding-right: 15px;
    }
}

@media (min-width: 100px) and (max-width: 767px) {
    .grocery-delevery {
        margin: 0px 0px 56px 0px;
        background-color: var(--wd-color-surface-alt);
        border-left: 0;
        border-radius: 0;
    }

    .App_Header_section {
        display: block;
        flex-direction: inherit;
    }

    .App_Header_section .App-image {
        margin: 0;
    }

    .App_Header_section .App-image .Device-app {
        width: 100%;
    }

    .App_Header_section .App_Header {
        margin: 26px 20px 0;
        width: auto;
        padding: 0;
        text-align: center;
    }

    .App_Header_section .App_Header h1 {
        margin: 0;
        font-family: var(--wd-font-body);
        font-size: 2.25em;
        font-weight: bold;
        font-stretch: normal;
        font-style: normal;
        line-height: normal;
        letter-spacing: -.59px;
        color: var(--wd-color-text);
        width: auto;
        padding: 0px 35px;
    }

    .App_Header_section .App_Header p {
        font-family: var(--wd-font-body);
        font-size: 1em;
        font-weight: 400;
        font-stretch: normal;
        font-style: normal;
        line-height: 1.33;
        /* -.4px, not live's own -.22px, for the same reason (and same non-negotiable
           constraint — --wd-font-body is a site-wide rebrand token, not this page's to
           change) as the desktop/tablet rule's padding-right comment above: WD Shopper's
           wider average glyph advance vs. live's Asap wraps this paragraph's text one line
           taller than live at specific mobile widths. There's no padding-right lever down
           here (this rule's own padding is vertical-only, 16px 0 20px, by design — the text
           is centered and meant to use the full column width), so letter-spacing is the only
           available knob. -.4px was verified against every real device viewport width in
           active use (320/360/375/390/413/414/430+ — iPhone SE/Android/iPhone 6-8-X/iPhone
           12-14/iPhone Plus-XR-11) with 0px diff against live at each. It does NOT close a
           ~395-410px synthetic band (no shipping phone has that width) where this app still
           wraps a line later than live — tightening further to close that band reopens the
           320px one instead (the two breakpoints move in opposite directions under a single
           uniform per-character adjustment; a font-metric-driven wrap point can't be forced
           to land on both simultaneously without matching glyph widths exactly, i.e. without
           reverting the font). Left as the closest practical match, not a perfect one. */
        letter-spacing: -.4px;
        color: var(--wd-color-text);
        width: auto;
        margin: 0;
        text-align: center;
        padding: 16px 0 20px;
    }

    .App_Header_section .App_Header a {
        text-decoration: none;
        margin-bottom: 24px;
    }
}

@media (min-width: 414px) and (max-width: 767px) {
    .App_Header_section .App_Header a {
        text-decoration: none;
        width: 366px;
        margin: auto;
        margin-bottom: 24px;
    }
}

@media (min-width: 100px) and (max-width: 413px) {
    .App_Header_section .App_Header a {
        text-decoration: none;
        width: fit-content;
        align-items: center;
        margin: auto;
        display: flex !important;
        margin-bottom: 24px;
    }
}
