/* Major Mixing — order/checkout page visual refresh (2026-08-26)
 *
 * Restyles the wp-fsqm-pro (eForm) order form + surrounding page chrome to
 * match the rest of the redesign. Every rule here is purely visual
 * (color/type/spacing/radius/shadow). NOT touched by this file or its
 * companion PHP edit: the plugin's own field/validation/payment markup,
 * the per-form-ID freetype/design layout rules in order-service-page.php's
 * own inline <style> block (real functional spacing/anti-spam-field rules
 * for 13 different form IDs), and every Stripe/GTM/FB Pixel/gtag/dataLayer
 * script on this page or in header.php.
 *
 * That inline <style> block renders near the end of <body>, AFTER this
 * enqueued sheet in the DOM — so for any property it also sets, the later
 * (inline) rule normally wins on equal specificity. Every rule below that
 * touches a property the legacy block also sets uses !important + a scoped
 * ancestor selector to win regardless of DOM order, matching the pattern
 * already used elsewhere in this theme for the same kind of collision.
 */

/* 2026-08-27 (client: grey gap "like an extra element" after the form,
   before the next section): this wrapper's own background is the page's
   grey, so its 64px bottom padding was a real 64px strip of that grey
   sitting between the white price card's rounded corner and the next
   (white) section -- read as a floating box at that width rather than
   normal section spacing. Halved, not removed -- still real breathing
   room, just not enough to read as its own element. */
.service-order-wrap{
  background:var(--mm-paper-2);
  padding-block:28px 32px;
}

/* ---------- Breadcrumb ---------- */
/* 2026-08-27 (client: Back button "ugly placement"): .order-breadcrumbs
   sits directly in the plugin/MUI grid's own .mui-row with no column
   wrapper of its own, so it never got the standard page gutter every
   other row's content has -- confirmed at 0px from the viewport edge
   while the card immediately below it (border/background added earlier
   this project) starts at 20px. Match that. */
.service-order-wrap .order-breadcrumbs{
  font-family:var(--font-body);
  font-size:var(--fs-small);
  color:var(--mm-t-secondary);
  padding-inline:20px;
}
.service-order-wrap .order-breadcrumbs a{
  color:var(--mm-t-secondary);
  text-decoration:none;
  display:inline-flex;align-items:center;gap:6px;
  transition:color 150ms;
}
.service-order-wrap .order-breadcrumbs a:hover{color:var(--mm-blue);}

/* ---------- Overall form shell ---------- */
/* 2026-08-26 (speed test finding): Lighthouse measured CLS 0.637 on this
   page — the eForm plugin's own "Loading" placeholder is only ~294px
   tall (confirmed live), then gets replaced by the real ~900-1700px-tall
   form once its AJAX call resolves, so everything below (the "View all
   services" link, the footer) visibly jumps down the moment the form
   pops in. Reserving approximate space up front is a standard, low-risk
   CLS fix — doesn't need the plugin's own JS to change at all, and an
   imperfect reservation (heights vary slightly by form) still removes
   the overwhelming majority of the shift versus the current ~0px
   reservation. Cleared once the loader's own "block" state ends (its
   sibling, the real field content, provides the real height from then
   on) via :has() so a fully-loaded form isn't artificially padded.
   min-height is deliberately not !important and unconditional (not
   gated to the loading state specifically, which would need matching
   the plugin's exact undocumented show/hide mechanism) -- once the real
   form content loads it's already taller than this reservation on every
   form checked, so it naturally has no effect at that point; it only
   ever does something during the brief loading window. */
#main-content{min-height:900px;}
@media(max-width:991px){
  #main-content{min-height:1600px;}
}
.service-order-wrap .ipt-eform-width-restrain{
  max-width:1100px!important;
  margin-inline:auto!important;
}
.service-order-wrap .ipt-eform-content{
  font-family:var(--font-body)!important;
}

/* The two top-level panels only (service details / add-ons + price) — NOT
   every nested field group. .ipt_fsqm_container_col_half is reused by the
   plugin at multiple nesting depths (individual field rows inside a panel
   also carry this class), so the selector must require the outer
   .ipt-eform-layout-wrapper as the DIRECT parent or every single field
   (Full Name, Email, each checkbox row...) gets its own card — that bug
   was invisible on desktop (small boxes side by side) but broke badly on
   mobile (one giant bordered box per field, stacked full-width). */
.service-order-wrap .ipt-eform-layout-wrapper > .ipt_fsqm_container_col_half > .ipt_uif_column_inner{
  box-shadow:none!important;
  border:1px solid var(--mm-paper-3)!important;
  border-radius:var(--r-lg)!important;
  background:var(--mm-paper)!important;
  padding:28px!important;
}
/* 2026-08-27 (client: "Mastering" title overlapping the Details button):
   .ipt-eform-layout-wrapper's direct .ipt_fsqm_container_col_half children
   are NOT just "the two big panels" as assumed above -- on forms with a
   section heading + info-tooltip pair (title row, e.g. "Mastering" / "Add-
   Ons"), THAT small header row is its own direct-child .ipt_fsqm_container_
   col_half too, so it was also getting the full 28px card treatment above.
   With only ~279px of content width left after that padding, the title
   and Details button (each needing calc(50% - 15px), the fix below) no
   longer had room and started overlapping. These header rows aren't
   meant to look like cards at all -- reset them back to plain, unpadded
   rows. Identify them the same way the width fix below does: they contain
   a .tooltip__button (the Details toggle), which real content panels
   (Add-Ons, price, etc.) never do. */
.service-order-wrap .ipt-eform-layout-wrapper > .ipt_fsqm_container_col_half:has(.tooltip__button) > .ipt_uif_column_inner{
  border:none!important;
  background:none!important;
  padding:0!important;
}
/* 2026-08-26 (client screenshot: two-column layout still cramped side by
   side well into the site's own mobile-header range, "Full Name"/"Email
   Address" labels truncated to "Full…"/"Em…"): neither the plugin's own
   CSS nor order-service-page.php's inline <style> block ever collapses
   these two top-level panels to one column at ANY width — every
   responsive rule that DOES exist there only resizes field groups
   *inside* a panel (design_7/8/9…), never the panels themselves. Below
   this site's own header breakpoint (991px, see pages-shared.css
   #masthead) the two ~450px-wide panels no longer have room, so labels
   and inputs got squeezed and truncated. Stack them explicitly instead
   of waiting on a plugin behavior that was never actually there. */
@media(max-width:991px){
  .service-order-wrap .ipt-eform-layout-wrapper > .ipt_fsqm_container_col_half{
    width:100%!important;flex:1 1 100%!important;
  }
  /* 2026-08-27 (client: "extra element, different color, between Upload
     and Add-Ons -- and again after the form"): once these two panels
     stack (above), the plugin's own base .ipt_uif_column style
     (margin:2px 0 15px + padding:5px 0) leaves a real ~25px strip of the
     page's own background color between this card's rounded bottom
     corner and the next card's rounded top corner -- correct box model,
     just wide enough at this specific two-tone (white card / grey page)
     contrast to read as its own floating rectangle rather than plain
     card-to-card spacing. Tighten it; the panels' own top/bottom padding
     still keeps a little breathing room. */
  .service-order-wrap .ipt-eform-layout-wrapper > .ipt_fsqm_container_col_half{
    margin-bottom:0!important;
  }
  /* On 2 of the 13 forms (confirmed: Mastering/62, Music Editing) the
     legacy inline block's own `@media(max-width:1140px){#..._design_9,
     #..._design_10{width:95%!important}}` rule (order-service-page.php)
     was clearly written for the standalone "Add-Ons" section heading
     (design_9 on this form — no sibling, fine at 95%) but its selector
     list also swept up design_10, the service-title cell that DOES have
     a sibling (the "Details" toggle button) meant to sit next to it at
     50/50 — forcing that title to 95% overflows the row and wraps the
     Details button onto its own line below. Rather than special-case
     every affected design_N id per form (fragile — the plugin assigns
     these sequentially per form config, so the exact ids differ per
     form), target the real structural pattern directly: any
     .ipt_uif_column_inner that has a Details/tooltip button among its
     (flat, unwrapped) children gets ALL of its half-width children
     forced to a clean, gap-safe 50/50 split. First attempt used a plain
     width:50%!important, which still wrapped — these are floated, and
     the title column carries a real 15px+15px side margin (details
     carries none), so two literal 50%-wide boxes plus that margin
     together exceed 100% and wrap exactly like the original bug.
     calc(50% - 15px) + a single consistent 15px right-hand gutter
     (zeroing the left margin) makes the two columns' total width sum to
     exactly 100% regardless of which one is the margin-bearing title. */
  /* #main-content (the section id from order-service-page.php) adds ID-
     level specificity on top of these classes — needed because the
     conflicting rule is itself a bare ID selector
     (#ipt_fsqm_form_62_design_10{width:95%!important}), and per CSS
     rules an ID always outranks any number of classes regardless of
     !important on both sides; a same-tier class-only selector here would
     silently lose. */
  #main-content.service-order-wrap .ipt_uif_column_inner:has(> .ipt_uif_column_half .tooltip__button) > .ipt_uif_column_half{
    width:calc(50% - 15px)!important;
    margin-left:0!important;margin-right:15px!important;
  }
}

/* 2026-08-27 (client, drawn guide-lines on a screenshot: Quantity of
   Songs sticks out past Email Address's right edge -- confirmed real at
   962px, a "tablet" width where the top-level panels have already
   stacked to one column (>480px, so the Full Name/Email stacking rule
   below doesn't apply) but the panel is still wide enough that Full
   Name/Email stay side by side. Root cause is the exact same
   width-math bug already fixed once for the title+Details row (see that
   comment for the full derivation): Full Name's column carries a plain
   margin-right:15px on top of a plain 50% width, so the pair's total
   width is 50%+15px+50% -- 15px more than the row actually has -- and
   the excess silently comes out of Email's side, landing its right edge
   15px short of Quantity/Notes (which are plain full-width fields with
   no such margin to reconcile). Same calc(50% - 15px) + normalized
   margin fix, just scoped to the Full Name row instead of the title row. */
#main-content.service-order-wrap .ipt_uif_column_inner:has(> .ipt_uif_column_half .ipt_fsqm_container_f_name) > .ipt_uif_column_half{
  width:calc(50% - 15px)!important;
  margin-left:0!important;margin-right:15px!important;
}
/* That row-level fix alone still left Email 15px short: EVERY field row
   (half or full) also carries its own .ipt_uif_column_inner.side_margin
   with 15px of INTERNAL padding on both sides, on top of whatever the
   column's own external width/margin is. A full-width field like
   Quantity/Notes only pays that once (panel edge minus 15px). The
   rightmost field of ANY half-width pair pays it TWICE: once via the
   external pairing gap (needed so the two fields don't overflow each
   other), then again via this same internal padding on its own right
   side -- a redundant second gutter that only the rightmost column of a
   pair has, since nothing sits to its right that it needs breathing room
   from.
   2026-08-29 (client: "Quantity of tracks коротше форми імейлу" on the
   Upgrade Mixing/Complete Mixing/MIXING/Beat Mixing/Dolby Atmos/Manual
   Vocal Editing order forms): the fix below used to be hardcoded to
   .ipt_fsqm_container_email only, so it never reached the *other*
   half-pair rows in these forms (Quantity of Songs + Quantity of
   tracks). Investigated the actual DOM (not assumed): every field in
   this plugin -- half or full -- is a FLAT sibling sequence (no
   per-row wrapper at all); two-per-row is purely a CSS float side
   effect of two 50%-width boxes in a row. So "the right half of a pair"
   is really just "the even-positioned .ipt_fsqm_container_col_half
   among its own siblings" -- verified live via
   document.querySelectorAll before writing this, confirmed to match
   exactly Email, the title row's "Details" toggle, and Quantity of
   tracks, and NOT any Add-Ons/pricing field (those live under a
   *different* top-level panel, so the extra ".ipt_fsqm_container_
   col_half " ancestor requirement below excludes them: it forces the
   even-positioned match to itself be nested inside another col_half,
   which the top-level panels themselves are not). Uses the CSS
   Selectors Level 4 ":nth-child(An+B of S)" syntax (an
   already-shipping feature in Chrome/Edge 111+, Safari 9+, Firefox
   134+ -- confirmed supported in this session's own browser before
   relying on it). Still gated to >480px for the same reason as before:
   below that, the stacking rule further down makes every field in the
   pair a plain full-width field again, at which point it needs its
   internal padding back on both sides (removing it there overshot the
   others by the same 15px in the other direction -- this exact
   regression was caught once already when the Email-only version of
   this rule was first written, so re-tested at mobile width again here
   too). */
@media(min-width:481px){
  #main-content.service-order-wrap .ipt_fsqm_container_col_half :nth-child(2n of .ipt_fsqm_container_col_half) .ipt_uif_column_full > .ipt_uif_column_inner.side_margin{
    padding-right:0!important;
  }
}

/* 2026-08-27 (client: "Full Name"/"Email Address" labels truncated to
   "Full…"/"Ema…" on phones): once the top-level panels stack to one
   column above (991px), a single panel is still only ~335px wide, and a
   plain 50/50 split inside it (each half ~150px after gutters) isn't
   enough room for "Email Address" plus its icon at any real font size --
   unlike the title+Details row above, these fields have nothing that
   benefits from staying side by side. 480px (not 991px) because at
   tablet widths a stacked panel already has plenty of room for two
   fields side by side; this only bites on narrow phones. Scoped to the
   Full Name field's own unique class (.ipt_fsqm_container_f_name, one
   per form, not reused elsewhere like .ipt_uif_column_half is) so this
   can't accidentally stack unrelated half-column pairs (checkboxes,
   Add-Ons). */
@media(max-width:480px){
  #main-content.service-order-wrap .ipt_uif_column_inner:has(> .ipt_uif_column_half .ipt_fsqm_container_f_name) > .ipt_uif_column_half{
    width:100%!important;
    margin-left:0!important;margin-right:0!important;
  }
}

/* 2026-08-27 (client: Add-Ons checkboxes "in a diagonal, not 2 rows"):
   each checkbox+label pair (.ipt_uif_label_column.column_random -- the
   plugin's own class literally admits it, "random") is inline-block sized
   to its OWN text content, not a fixed column. So they flow like words
   wrapping in a paragraph: whichever pair happens to fit two-per-line
   does, and the second item's x-position depends on how wide the first
   item's label was on THAT row -- different per row, hence the
   staggered/diagonal look instead of a clean 2-column grid.
   First attempt used float:left + width:50%, which fixed the horizontal
   position but not fully: labels wrap to a different number of lines
   ("Apple Digital Masters" is 66px/2 lines, its row-mate "Stem Mastering"
   is 38px/1 line), and floats fill the next available gap rather than
   starting a strict new row -- so a later item could still float up
   beside a taller neighbor instead of beginning its own row. CSS grid
   doesn't have that failure mode: every item gets a fixed row/column
   track regardless of its own or its neighbors' height. */
.service-order-wrap .ipt_uif_question_content:has(> .ipt_uif_label_column.column_random){
  display:grid!important;
  grid-template-columns:1fr 1fr!important;
}
.service-order-wrap .ipt_uif_label_column.column_random{
  width:auto!important;
  float:none!important;
  display:block!important;
  box-sizing:border-box!important;
}

/* ---------- Typography ---------- */
.service-order-wrap .ipt_uif_heading,
.service-order-wrap h1,
.service-order-wrap h2,
.service-order-wrap h3{
  font-family:var(--font-display)!important;
  color:var(--mm-t-primary)!important;
  font-weight:700!important;
}
.service-order-wrap .ipt_uif_label,
.service-order-wrap label{
  font-family:var(--font-body)!important;
  color:var(--mm-t-secondary)!important;
}
.service-order-wrap .ipt_uif_divider_text_inner{
  font-family:var(--font-body)!important;
  color:var(--mm-t-primary)!important;
}

/* ---------- Text / email / number / textarea inputs ---------- */
.service-order-wrap .input-field input[type=text],
.service-order-wrap .input-field input[type=email],
.service-order-wrap .input-field input[type=number],
.service-order-wrap textarea.materialize-textarea{
  border:1px solid var(--mm-paper-3)!important;
  border-bottom:1px solid var(--mm-paper-3)!important;
  border-radius:var(--r-md)!important;
  background:var(--mm-paper-2)!important;
  color:var(--mm-t-primary)!important;
  font-family:var(--font-body)!important;
  box-shadow:none!important;
  padding:10px 14px!important;
  transition:border-color 150ms, background 150ms;
  /* 2026-08-27 (client: field right edges don't line up -- confirmed at
     wide desktop widths, e.g. Email's own input rendered 18px wider than
     its own container). Materialize.js sets an explicit inline pixel
     width on these text inputs (not just the textarea, see the
     box-sizing rule below), computed as box-sizing:content-box -- so our
     padding/border get added ON TOP of that fixed width instead of being
     carved out of it, pushing the input past its own container by
     however much padding this rule adds. border-box + 100% makes every
     field's actual box match its container regardless of what pixel
     width the plugin's JS decided to cache. */
  box-sizing:border-box!important;
  width:100%!important;
}
.service-order-wrap .input-field input[type=text]:focus,
.service-order-wrap .input-field input[type=email]:focus,
.service-order-wrap .input-field input[type=number]:focus,
.service-order-wrap textarea.materialize-textarea:focus{
  border-color:var(--mm-blue)!important;
  background:var(--mm-paper)!important;
  box-shadow:none!important;
}
/* 2026-08-27 (client screenshot: typed text renders under/behind the
   person/email icon on "Full Name"/"Email Address"): the uniform
   padding:14px above never accounted for the icon -- it's an absolutely-
   positioned <i class="ipticm prefix"> spanning left:10.5px to 42px
   (10.5+31.5 wide), so text starting at only 14px sits directly under it.
   Push icon-prefixed inputs' text past the icon; plain inputs (no icon)
   keep the 14px above. Notes has the exact same icon+.has-icon markup as
   Full Name/Email (a <textarea> instead of <input> is the only
   difference) and the same bug -- missed it the first pass because I'd
   only fixed input[type=...], not textarea. */
.service-order-wrap .input-field.has-icon input[type=text],
.service-order-wrap .input-field.has-icon input[type=email],
.service-order-wrap .input-field.has-icon input[type=number],
.service-order-wrap .input-field.has-icon textarea.materialize-textarea{
  padding-left:46px!important;
}
/* 2026-08-27 (client: Notes' right edge doesn't line up with Email
   Address / Quantity of Songs above it): Materialize's textarea auto-
   resize script sets an explicit inline pixel width on load, and that
   textarea alone (unlike the input fields and the select2 box) computes
   it with box-sizing:content-box -- so its padding/border get added ON
   TOP of that fixed width instead of being carved out of it, landing its
   right edge ~14-29px short of every sibling field's edge. Force
   border-box + 100% so it matches the same box model as everything else
   and stops drifting when the icon padding above changes it further. */
.service-order-wrap textarea.materialize-textarea{
  box-sizing:border-box!important;
  width:100%!important;
}
/* 2026-08-27 (client: "Notes field is small and there's no scroll when you
   type"): Materialize.js is supposed to auto-grow this textarea's height
   to fit typed content via its own JS (hence overflow-y:hidden -- no
   scrollbar needed if the box always grows to fit). That auto-grow isn't
   firing reliably here, so the box stays frozen at its tiny initial
   height (42px, room for one short line) and hidden overflow means any
   text past that is invisible with no way to reach it -- neither growing
   nor scrollable. Stop depending on the plugin's JS: give it a real
   min-height up front (matching its own rows="4" markup) and let the
   browser's native textarea scrollbar take over past that, independent
   of whatever the auto-resize script does or doesn't do. */
.service-order-wrap textarea.materialize-textarea{
  min-height:110px!important;
  overflow-y:auto!important;
}

/* 2026-08-29 (client: "фантомна форма" -- blank grey box below Upload).
   This form has a second feedback_large field ("Files", freetype index 13)
   configured with no label/icon/placeholder from the start -- confirmed
   identical on production. It was invisible before because empty fields
   collapsed to near-nothing; the min-height:110px fix above (needed for
   the real Notes field) made this blank one equally tall and suddenly
   visible as an empty grey smear. Hide it outright, using :has() to match
   only the icon-less field so the real Notes field (which has .has-icon)
   is never touched. */
.service-order-wrap .ipt_fsqm_container_feedback_large:has(.input-field:not(.has-icon)){
  display:none!important;
}

/* Select2 dropdown ("Quantity of Songs" etc.) */
/* 2026-08-27 (client, drawn guide-lines on a screenshot: Quantity of Songs
   sticks out past Email Address's right edge -- confirmed real at 962px
   viewport width, a gap between the widths already checked. Same
   box-sizing:content-box family of bug as the input/textarea fixes above,
   just on the one Select2 piece (.select2-selection, the visible styled
   box) that was never covered: its border here gets added on top of a
   plugin-computed width instead of being absorbed into it. */
.service-order-wrap .select2-container--eform-material .select2-selection{
  border:1px solid var(--mm-paper-3)!important;
  border-radius:var(--r-md)!important;
  background:var(--mm-paper-2)!important;
  height:44px!important;
  box-sizing:border-box!important;
  width:100%!important;
}
.service-order-wrap .select2-container--eform-material{
  box-sizing:border-box!important;
  width:100%!important;
}
.service-order-wrap .select2-selection__rendered{
  font-family:var(--font-body)!important;
  color:var(--mm-t-primary)!important;
  line-height:44px!important;
}

/* Checkboxes (Add-Ons list) */
.service-order-wrap [type=checkbox].filled-in:checked+span:not(.lever):after{
  background-color:var(--mm-blue)!important;
  border-color:var(--mm-blue)!important;
}
.service-order-wrap [type=checkbox].filled-in:not(:checked)+span:not(.lever):before{
  border-color:var(--mm-paper-3)!important;
}
.service-order-wrap .ipt_uif_checkbox{
  font-family:var(--font-body)!important;
  color:var(--mm-t-primary)!important;
}

/* File upload button */
.service-order-wrap .waves-effect.upload,
.service-order-wrap .fp-pick{
  background:var(--mm-ink)!important;
  color:var(--mm-t-inv)!important;
  border-radius:var(--r-md)!important;
  font-family:var(--font-body)!important;
  font-weight:600!important;
  box-shadow:none!important;
}
.service-order-wrap .file_upload_text{
  color:var(--mm-t-muted)!important;
  font-family:var(--font-body)!important;
}

/* "Details" info button — legacy .tooltip__button hardcoded #0776FE with
   !important on the same properties, so this needs the same specificity. */
.service-order-wrap .tooltip__button{
  background-color:var(--mm-blue)!important;
  border-radius:var(--r-md)!important;
  font-family:var(--font-body)!important;
}
.service-order-wrap .tooltip__text{
  border:1px solid var(--mm-paper-3)!important;
  border-radius:var(--r-lg)!important;
  box-shadow:0 16px 40px rgba(14,14,16,.14)!important;
  font-family:var(--font-body)!important;
  color:var(--mm-t-primary)!important;
}
.service-order-wrap .tooltip__text:before{display:none!important;}

/* ---------- Price / total-amount panel ---------- */
.service-order-wrap .ipt-eform-math-row{
  font-family:var(--font-body)!important;
  color:var(--mm-t-primary)!important;
}
/* .ipt-eform-math-fancy is reused at TWO nesting depths here: the outer
   full-width row (also carries .ipt_uif_column_full) that should be the
   visible black card, and the small floated price-VALUE box nested inside
   it (also carries .ipt_uif_richtext + .ipt_uif_mathematical) that should
   just be plain text. A single un-scoped rule styled both as identical
   black boxes -- the inner one then shrink-wrapped its own copy of the
   padding/background around only the digits, so it read as a second,
   too-narrow card nested in the first and clipped "$0.00" to "$0.0". */
.service-order-wrap .ipt_uif_column_full.ipt-eform-math-fancy{
  background:var(--mm-ink)!important;
  color:var(--mm-t-inv)!important;
  font-family:var(--font-display)!important;
  font-weight:700!important;
  border-radius:var(--r-md)!important;
  overflow:hidden;
  padding:10px 16px!important;
}
.service-order-wrap .ipt_uif_richtext.ipt-eform-math-fancy{
  background:none!important;
  color:inherit!important;
  font-family:inherit!important;
  font-weight:inherit!important;
  border-radius:0!important;
  overflow:visible!important;
  padding:0!important;
  width:auto!important;
  float:none!important;
  display:inline-block!important;
  /* Root cause of the clipping: the plugin nudges this box with
     position:relative; top:-14px; right:-57px so the price text lands on
     top of the ribbon-fold graphic (hidden above) instead of behind it.
     With the ribbon gone this offset just shoves the digits out of the
     card. Cancel it. */
  position:static!important;
  top:0!important;
  right:0!important;
}
/* The value ("$ X.XX") sits inside a chain of THREE more nested wrappers
   (.ipt_uif_question_content > .ipt_uif_fancy_container > the richtext box
   above), each independently float:right + shrink-to-fit per the plugin's
   own CSS. Each shrink-wraps to the next one's natural width, and small
   rounding differences compound down the chain until the innermost box's
   right edge drifts past the outer card's boundary -- invisible while the
   ribbon graphic (hidden above) used to paper over the gap. Give the
   outermost of the three an explicit, generously-sized box instead of
   letting it shrink-to-fit, and flatten the rest to plain inline content
   inside it. */
.service-order-wrap .ipt_uif_column_full.ipt-eform-math-fancy .ipt_uif_question_content{
  float:right!important;
  width:150px!important;
  text-align:right!important;
}
.service-order-wrap .ipt_uif_column_full.ipt-eform-math-fancy .ipt_uif_fancy_container{
  float:none!important;
  display:inline-block!important;
  width:auto!important;
}
/* Both "Total Amount" (a plain <label class="ipt_uif_label">, styled grey
   sitewide for labels that sit on the white card background) and the
   "$ X.XX" value (greyed by the plugin's own default) read as dim/washed
   out on this black card specifically -- client wants both pure white
   here. The sitewide label-color rule matches the label directly (not
   just via inheritance), so it has to be beaten with an equally direct,
   more specific override rather than relying on color:inherit from the
   card background. */
.service-order-wrap .ipt_uif_column_full.ipt-eform-math-fancy .ipt_uif_label,
.service-order-wrap .ipt_uif_column_full.ipt-eform-math-fancy label,
.service-order-wrap .ipt_uif_richtext.ipt-eform-math-fancy{
  color:var(--mm-t-inv)!important;
}
/* The plugin's own CSS draws two decorative "ribbon fold" notches as CSS
   border-triangles (positioned outside the box's own left/0 and right/50px
   offsets, hardcoded to Material blue). Recoloring them to match the new
   dark background (tried first) still left a visible dark triangle poking
   out past the box's rounded corner on some forms (real content height
   varies per form, so the hardcoded offsets don't always land inside the
   box). Simpler and robust across all 13 forms: hide the notches outright
   — a flat rounded rectangle fits this redesign's look better than a
   torn-paper ribbon effect anyway, no other component here uses one. */
.service-order-wrap .ipt-eform-math-fancy.ipt_uif_mathematical::before,
.service-order-wrap .ipt-eform-math-fancy.ipt_uif_mathematical::after{
  display:none!important;
}

/* ---------- Submit button ---------- */
.service-order-wrap .ipt_fsqm_form_button_submit,
.service-order-wrap .eform-material-button{
  background:var(--mm-blue)!important;
  /* Plugin's own default text color (a muted mid-blue, meant to sit on a
     light/white button) was never overridden here -- against OUR blue
     background it read as low-contrast, washed-out text ("blurry" per
     client). */
  color:var(--mm-t-inv)!important;
  border-radius:var(--r-md)!important;
  font-family:var(--font-body)!important;
  font-weight:700!important;
  box-shadow:none!important;
  transition:background 150ms;
}
.service-order-wrap .ipt_fsqm_form_button_submit:hover,
.service-order-wrap .eform-material-button:hover{
  background:var(--mm-blue-hover)!important;
}
/* 2026-08-27 (client: "some extra dark field" below Proceed to Checkout):
   the plugin's own .ipt_fsqm_form_button_container reserves padding:30px
   top AND bottom (60px total) around the button -- inside our black
   Total Amount card that reads as a big empty dark strip under the
   button, way out of proportion with the card's own 10px padding
   elsewhere. Bring it down to match. */
.service-order-wrap .ipt_fsqm_form_button_container{
  padding-top:16px!important;
  padding-bottom:16px!important;
}

/* ---------- "View all services" / back CTA below the form ---------- */
.service-order-wrap ~ section .btn-square,
section .agree_btn .btn-square{
  display:inline-flex;align-items:center;justify-content:center;
  font-family:var(--font-body)!important;
  font-weight:700!important;
  background:var(--mm-ink)!important;
  color:var(--mm-t-inv)!important;
  border-radius:var(--r-md)!important;
  padding:14px 28px!important;
  text-decoration:none!important;
}

/* ---------- Thank You page ---------- */
.mm-thankyou-wrap{
  background:var(--mm-paper-2);
  padding-block:80px;
  min-height:60vh;
  display:flex;align-items:center;justify-content:center;
}
.mm-thankyou-card{
  background:var(--mm-paper);
  border:1px solid var(--mm-paper-3);
  border-radius:var(--r-lg);
  max-width:560px;
  width:100%;
  padding:56px 40px;
  text-align:center;
  box-shadow:0 24px 60px rgba(14,14,16,.08);
}
.mm-thankyou-card__icon{
  width:64px;height:64px;margin:0 auto 24px;
  display:flex;align-items:center;justify-content:center;
  background:var(--mm-green);
  border-radius:50%;
}
.mm-thankyou-card__icon svg{width:32px;height:32px;}
.mm-thankyou-card h1{
  font-family:var(--font-display);
  font-size:var(--fs-h2);
  color:var(--mm-t-primary);
  margin-bottom:14px;
}
.mm-thankyou-card p{
  font-family:var(--font-body);
  color:var(--mm-t-secondary);
  font-size:var(--fs-body);
  line-height:var(--lh-body);
  margin-bottom:14px;
}
.mm-thankyou-card__signature{
  font-family:var(--font-body);
  font-weight:700;
  color:var(--mm-t-primary);
  margin-top:24px;
}
.mm-thankyou-card__social{
  display:flex;gap:16px;justify-content:center;margin-top:28px;
}
.mm-thankyou-card__social a{
  width:40px;height:40px;border-radius:50%;
  display:flex;align-items:center;justify-content:center;
  background:var(--mm-paper-2);
  transition:background 150ms;
}
.mm-thankyou-card__social a:hover{background:var(--mm-paper-3);}
.mm-thankyou-card__social img{width:18px;height:18px;}

@media(max-width:600px){
  .mm-thankyou-card{padding:40px 24px;}
}
