/* Form 3 (Auto Quote, Conversational) -- restyles Gravity Forms' default
 * multi-page markup into the one-question-per-screen card UI validated in
 * the EverQuote/Compare.com research. Scoped to #gform_wrapper_3 so it
 * never touches Form 1 or Form 2. */

/* Capped and centered rather than stretching to the full .wrap shell
   width -- acrisure.com's own reference form reads the same way, and a
   two-column field grid this wide starts looking sparse/hard to scan
   at full desktop width otherwise. Scoped to this form specifically,
   not the site-wide .wrap class -- this is about form/interactive-
   content width, not the "don't cap body/article text" call made
   elsewhere on the site. max-width alone (no extra media query) is
   enough for "adjust accordingly as it shrinks": below 960px this
   simply stops being the constraint and the form fills the .wrap
   shell's own width like before. */
#gform_wrapper_3 {
	max-width: 960px; margin-left: auto; margin-right: auto;
}
#gform_wrapper_3 .gform_heading { display: none; }
/* GF's own native progress bar ("Step X of Y") duplicates the custom
   .enxura-progress-zone bar built for this form -- form settings has
   pagination.type still set to "percentage" (a save through the admin
   UI, or an API update that didn't explicitly carry this setting
   forward, appears to have turned it back on at some point), but the
   custom bar is the one actually meant to show. */
#gform_wrapper_3 .gf_progressbar_wrapper { display: none; }
/* The "(Required)" text next to every question is redundant with GF's own
   validation message, which already appears under a field if it's left
   blank on submit -- this only removes the always-on label, not that
   built-in blank-field error. */
#gform_wrapper_3 .gfield_required { display: none; }

#gform_wrapper_3 .enxura-progress-zone {
	padding: 20px 0 16px;
	margin-bottom: 20px;
}
#gform_wrapper_3 .enxura-progress-track {
	height: 6px; border-radius: 3px; background: #E8F1FB; overflow: hidden; margin-bottom: 8px;
}
#gform_wrapper_3 .enxura-progress-fill {
	height: 100%; background: #1B6FC4; border-radius: 3px; transition: width .25s ease;
}
#gform_wrapper_3 .enxura-progress-label {
	font-size: 12px; color: #767992; line-height: 1.25;
}

#gform_wrapper_3 fieldset.gfield--type-radio {
	border: none; padding: 0; margin: 0;
}
#gform_wrapper_3 .gfield--type-radio legend.gfield_label,
#gform_wrapper_3 .gfield--type-radio .gform-field-label__text {
	/* margin:0 -- fieldset.gfield--type-radio above already zeroes the
	   fieldset's own margin, but a <legend> carries its own separate
	   browser-default margin regardless of its parent fieldset's --
	   caught live via DevTools showing a real margin-bottom box under
	   the legend text, sitting between the question and its own Yes/No
	   choices. */
	font-size: 20px; font-weight: 600; letter-spacing: -0.01em; color: #000033;
	line-height: 1.25; margin: 0;
}

#gform_wrapper_3 .ginput_container_radio .gfield_radio {
	display: grid; grid-template-columns: repeat( 2, 1fr ); gap: 10px; margin-top: 16px;
}
/* Matches EverQuote's column counts at each breakpoint. */
@media (min-width: 768px) {
	#gform_wrapper_3 .ginput_container_radio .gfield_radio { grid-template-columns: repeat( 3, 1fr ); }
}
@media (min-width: 1024px) {
	/* Flex-wrap, not CSS grid -- repeat(4,1fr) fixed the column count
	   regardless of how many choices a given question actually has,
	   leaving a 2 or 3-choice question (Yes/No) narrower than the 960px
	   container. An auto-fit/minmax grid (tried first) fixes that
	   single-row case correctly, but a *multi-row* list (year, make, a
	   10+-model list) still failed the same way on its own trailing
	   partial row: grid's auto-fit only collapses a column that's
	   unused across every row, and a make/model list's first N-1 rows
	   are always full, so the 2 leftover items on the final row stayed
	   at their normal 220px width instead of expanding into the empty
	   columns next to them -- caught live via a screenshot of a
	   10-model GMC list whose last row (2 models) sat at half width
	   with visible dead space beside it, same shape of bug as the
	   Yes/No case but one grid's `auto-fit` genuinely can't reach.
	   Flex-wrap has no such row/column bookkeeping -- flex-grow
	   redistributes each ROW's own leftover space among that row's own
	   items independently, so a full row of 4 renders identically to
	   the old grid (each item's 220px basis grows to the same ~232px
	   auto-fit already produced) and a trailing partial row of 2 (or a
	   whole 2-choice question) still splits its row's full width
	   evenly, everywhere, not just when it's the only row. */
	/* flex-direction: row explicit -- Gravity Forms' own core CSS
	   already sets `.gfield_radio` (a GF-native class) to
	   display:flex; flex-direction:column, sensible as GF's own plain-
	   vertical-list default. That was harmless under this rule's
	   previous display:grid (flex-direction has no effect on a grid
	   container), but switching to display:flex here exposed it: every
	   choice card started stacking full-width in a single column
	   instead of wrapping left-to-right, confirmed live via a
	   computed-style check showing flex-direction:column and a 220px-
	   tall, 960px-wide choice card instead of the other way around. */
	#gform_wrapper_3 .ginput_container_radio .gfield_radio { display: flex; flex-direction: row; flex-wrap: wrap; }
	#gform_wrapper_3 .ginput_container_radio .gfield_radio > .gchoice { flex: 1 1 220px; }
}
#gform_wrapper_3 .ginput_container_radio .gchoice {
	/* Gravity Forms' own base CSS sets this to display:grid with no
	 * explicit track sizing, which stops the label's width:100% below
	 * from resolving against the card's true width. Overriding to a
	 * plain block container removes that unintended nested-grid
	 * interaction entirely. */
	display: block;
	margin: 0; border: 1px solid #E2E5EB; border-radius: 10px; background: #FFFFFF;
	transition: border-color .12s ease, background .12s ease;
	position: relative;
}
#gform_wrapper_3 .ginput_container_radio .gchoice:hover {
	border-color: #1B6FC4; background: #E8F1FB;
}
#gform_wrapper_3 .ginput_container_radio .gchoice input.gfield-choice-input {
	position: absolute; inset: 0; width: 100%; height: 100%; margin: 0;
	opacity: 0; cursor: pointer;
}
#gform_wrapper_3 .ginput_container_radio .gchoice label {
	/* GF's base CSS puts a 12px left margin here, meant to space its own
	 * native radio dot from the text. That dot is hidden in this design
	 * (input is the invisible full-card click target), so the leftover
	 * margin just pushes a 100%-width label past the card's right edge. */
	margin: 0;
	display: flex; align-items: center; justify-content: space-between; gap: 10px;
	width: 100%; box-sizing: border-box;
	padding: 17px 16px; font-size: 18px; font-weight: 600; color: #000033;
	cursor: pointer; line-height: 1.25;
}
/* Visible radio circle -- the input itself is an invisible full-card
 * click target (below), so the selected state needs its own dot here
 * rather than relying on the browser's native radio appearance. */
#gform_wrapper_3 .ginput_container_radio .gchoice label::after {
	content: ''; flex: none; width: 20px; height: 20px; border-radius: 50%;
	border: 2px solid #C7C9DC; box-sizing: border-box;
	transition: border-color .12s ease, background .12s ease, box-shadow .12s ease;
}
#gform_wrapper_3 .ginput_container_radio .gchoice input.gfield-choice-input:checked ~ label {
	color: #1B6FC4;
}
#gform_wrapper_3 .ginput_container_radio .gchoice input.gfield-choice-input:checked ~ label::after {
	border-color: #1B6FC4; background: #1B6FC4; box-shadow: inset 0 0 0 4px #fff;
}
#gform_wrapper_3 .ginput_container_radio .gchoice:has(input.gfield-choice-input:checked) {
	border-color: #1B6FC4; background: #E8F1FB;
}

#gform_wrapper_3 .enxura-search-wrap { position: relative; margin: 16px 0 6px; }
#gform_wrapper_3 .enxura-search-wrap input {
	width: 100%; height: 56px; border-radius: 10px; border: 1px solid #E2E5EB;
	background: #FFFFFF; color: #000033; font-family: inherit; font-size: 16px;
	/* !important -- this and the generic #gform_wrapper_3 input[type="text"]
	   rule (added later in this file, round 6) are tied in specificity
	   (1 id + 1 class + 1 tag vs 1 id + 1 attribute + 1 tag), so the later
	   one in source order was winning and collapsing this input's left
	   padding from 40px down to its own generic 14px -- shoving the
	   placeholder text straight under the search icon at left:13px.
	   Caught live via a screenshot of the make-search box with "Type to
	   search makes..." overlapping the magnifying glass. */
	padding: 0 14px 0 40px !important; outline: none; box-sizing: border-box;
}
#gform_wrapper_3 .enxura-search-wrap input:focus { border-color: #1B6FC4; }
#gform_wrapper_3 .enxura-search-wrap svg {
	position: absolute; left: 13px; top: 50%; transform: translateY(-50%);
	pointer-events: none; color: #767992;
}
#gform_wrapper_3 .enxura-search-count { font-size: 12.5px; color: #767992; margin: 8px 0; line-height: 1.25; }
#gform_wrapper_3 .gchoice.enxura-filtered-out,
#gform_wrapper_3 .gchoice.enxura-collapsed,
#gform_wrapper_3 .gchoice.enxura-year-gated { display: none; }

#gform_wrapper_3 .enxura-show-more {
	/* font-size 20px -- matches the question label ("What is your
	   vehicle's model year?"), was 14.5px (matched the Next button
	   instead). */
	display: flex; align-items: center; gap: 6px; margin: 14px auto 0;
	background: none; border: none; color: #1B6FC4; font-weight: 600;
	font-size: 20px; cursor: pointer; padding: 8px; font-family: inherit;
	line-height: 1.25; outline: none;
}
#gform_wrapper_3 .enxura-show-more:hover { text-decoration: underline; }

#gform_wrapper_3 .gform_page_footer {
	border-top: none;
	display: flex; align-items: center; justify-content: space-between; gap: 16px;
}
/* A small text-link "Back", not a full button -- available to fix a
 * mistake without competing visually with the forward-progress flow. */
#gform_wrapper_3 button.gform_previous_button {
	/* font-size 14.5px -- matches .gform_next_button below exactly; was
	   13.5px, a 1px mismatch with no evident reason, caught live via a
	   side-by-side screenshot of the two buttons on the same row. */
	background: none !important; border: none !important; outline: none !important;
	box-shadow: none !important; color: #767992; font-size: 14.5px;
	font-weight: 600; padding: 8px 0; cursor: pointer; order: -1;
	line-height: 1.25;
}
#gform_wrapper_3 button.gform_previous_button:hover { color: #1B6FC4; }
/* GF's own "Save and Continue Later" link -- Save and Continue stays
 * enabled server-side (it's what actually persists a resume token on
 * every page transition), but the resume UX is our own custom "Welcome
 * back" prompt instead of this native link/email flow -- see
 * auto-quote-conversational.js. */
#gform_wrapper_3 .gform_save_link { display: none !important; }
/* GF's own base CSS absolutely-positions the loading spinner centered on
 * this button, which lands on top of the "Back" text now that the
 * button is shrunk down to a text link. Pulling it back into normal
 * flow puts it right after the text instead. */
#gform_wrapper_3 .gform_previous_button .gform-loader {
	position: static !important; display: inline-block; vertical-align: middle;
	margin-left: 6px; width: 14px; height: 14px;
}
/* Same fix, same reason -- GF injects the identical absolutely-positioned
 * spinner into Next and the final-page Submit button, landing centered on
 * top of the "Next"/"Submit" text during page-advance. */
#gform_wrapper_3 .gform_next_button .gform-loader,
#gform_wrapper_3 .gform_button .gform-loader {
	position: static !important; display: inline-block; vertical-align: middle;
	margin-left: 6px; width: 14px; height: 14px;
}
#gform_wrapper_3 .gform_next_button, #gform_wrapper_3 .gform_button {
	background: #1B6FC4; border: none; color: #fff; border-radius: 10px;
	padding: 12px 22px; font-weight: 600; font-size: 14.5px; line-height: 1.25;
}
#gform_wrapper_3 .gform_next_button:disabled, #gform_wrapper_3 .gform_button:disabled {
	background: #C7C9DC; cursor: not-allowed;
}

#gform_wrapper_3 .enxura-other-message {
	margin-top: 16px; padding: 14px 16px; border-radius: 10px;
	background: #E8F1FB; border: 1px solid #C9DEF3;
	color: #000033; font-size: 16px; line-height: 1.25;
}
#gform_wrapper_3 .enxura-other-message a { color: #1B6FC4; font-weight: 700; }

/* Same box treatment as .enxura-other-message -- a separate class since
 * this one is reassuring ("great news") rather than a stop-and-call
 * notice, but the visual container language is the same established
 * info-callout look. */
#gform_wrapper_3 .enxura-multi-vehicle-message {
	margin-top: 16px; padding: 14px 16px; border-radius: 10px;
	background: #E8F1FB; border: 1px solid #C9DEF3;
	color: #000033; font-size: 16px; line-height: 1.25;
}

#gform_wrapper_3 .enxura-model-loading {
	padding: 24px 0; color: #767992; font-size: 14px; text-align: center; line-height: 1.25;
}
#gform_wrapper_3 .enxura-model-note {
	margin-top: 16px; font-size: 13px; color: #767992; line-height: 1.25;
}
#gform_wrapper_3 .enxura-model-grid {
	display: grid; grid-template-columns: repeat( 2, 1fr ); gap: 10px; margin-top: 16px;
}
@media (min-width: 768px) {
	#gform_wrapper_3 .enxura-model-grid { grid-template-columns: repeat( 3, 1fr ); }
}
@media (min-width: 1024px) {
	/* Flex-wrap, not CSS grid -- same fix, same reasoning as the
	   radio-choice grid above: an auto-fit/minmax grid only collapses a
	   column that's unused across *every* row, so a model list's
	   trailing partial row (e.g. 10 models = 2 full rows of 4 then 2
	   left over) still rendered that last row's real items at a fixed
	   220px-ish width with dead space beside them, since columns 3-4
	   are very much in use by the earlier full rows. Flex-grow
	   redistributes each row's own leftover space among that row's own
	   items independently, so this actually reaches every row,
	   including the last one -- caught live via a screenshot of a
	   10-model GMC list. */
	#gform_wrapper_3 .enxura-model-grid { display: flex; flex-wrap: wrap; }
	#gform_wrapper_3 .enxura-model-grid > .enxura-model-opt { flex: 1 1 220px; }
}
#gform_wrapper_3 .enxura-model-opt {
	display: flex; align-items: center; justify-content: space-between; gap: 10px;
	width: 100%; box-sizing: border-box; margin: 0;
	border: 1px solid #E2E5EB; border-radius: 10px; background: #FFFFFF;
	padding: 17px 16px; font-size: 18px; font-weight: 600; color: #000033;
	font-family: inherit; cursor: pointer; text-align: left;
	transition: border-color .12s ease, background .12s ease;
}
/* Only labels long enough to wrap (e.g. "TRANSIT WAGON - LOW ROOF 12
 * PASS ICE") get extra breathing room between lines -- short ones like
 * "ES 350" stay exactly as tight as they've always been. Applied via
 * enxura-model-opt--wrapped, set in JS after actually measuring which
 * buttons wrap, since CSS alone can't detect that. */
#gform_wrapper_3 .enxura-model-opt.enxura-model-opt--wrapped { line-height: 1.25; }
#gform_wrapper_3 .enxura-model-opt:hover { border-color: #1B6FC4; background: #E8F1FB; }
#gform_wrapper_3 .enxura-model-opt::after {
	content: ''; flex: none; width: 20px; height: 20px; border-radius: 50%;
	border: 2px solid #C7C9DC; box-sizing: border-box;
	transition: border-color .12s ease, background .12s ease, box-shadow .12s ease;
}
#gform_wrapper_3 .enxura-model-opt.selected { border-color: #1B6FC4; background: #E8F1FB; color: #1B6FC4; }
#gform_wrapper_3 .enxura-model-opt.selected::after {
	border-color: #1B6FC4; background: #1B6FC4; box-shadow: inset 0 0 0 4px #fff;
}
#gform_wrapper_3 .enxura-model-opt.enxura-filtered-out { display: none; }

#gform_wrapper_3 .enxura-manual-entry {
	/* order:2 -- appended to the fieldset last in the DOM (see
	   relocateMakeOtherInput()), but the field is a flex column whose
	   choices grid (.ginput_container_radio) carries an explicit order:1
	   of its own; without a competing order here this fell back to the
	   implicit order:0 it shares with the legend, which flex ranks by
	   order first and DOM position only as a tiebreak -- so it was
	   rendering ABOVE the choice grid instead of below it, ahead of even
	   the question text in some cases. Caught live via a screenshot
	   showing "Type your vehicle make" above the Harley-Davidson/Honda/...
	   grid instead of below it as the border-top divider styling above
	   clearly intends. */
	order: 2; margin-top: 18px; padding-top: 16px; border-top: 1px solid #E2E5EB;
}
#gform_wrapper_3 .enxura-manual-entry label {
	/* margin-bottom 16px, not 8 -- matches the gap between the main
	   question legend and its own search bar just above this block
	   (.enxura-search-wrap's margin-top). Caught live via a
	   getBoundingClientRect diff after a screenshot comparison: this
	   label sat half as far from its own input (8px) as the question
	   sits from its search bar (16px), even though both are meant to
	   read as the same kind of "label above its own control" spacing. */
	display: block; font-size: 16px; font-weight: 600; color: #767992; margin-bottom: 16px;
	line-height: 1.25;
}
#gform_wrapper_3 .enxura-manual-entry-row { display: flex; gap: 8px; }
#gform_wrapper_3 .enxura-manual-entry-row input {
	flex: 1; min-width: 0; max-width: none; height: 56px; border-radius: 10px; border: 1px solid #E2E5EB;
	background: #FFFFFF; color: #000033; font-family: inherit; font-size: 16px;
	padding: 0 14px; outline: none; box-sizing: border-box;
}
#gform_wrapper_3 .enxura-manual-entry-row input:focus { border-color: #1B6FC4; }

/* ===== Page 1 "Get Started" -- Name/DOB/Marital/Email/Phone/Address/
   County, front-loaded like acrisure.com's Get Started step instead of
   this form's usual one-question-per-screen pattern. Standard GF field
   markup (not a hand-built picker like the pages above), so styling
   targets GF's own classes directly. ===== */
/* Sizes originally matched against acrisure.com's own headline+
   description (checked live in devtools: 40px/64px headline, 20px/24px
   description, jumping at their own min-width:1440 breakpoint). The
   1440px jump was dropped once #gform_wrapper_3 got its own 960px
   max-width cap (see the top of this file) -- past that cap the form's
   actual rendered width stops changing at all past 960px, so scaling
   text against viewport width beyond that point no longer serves the
   proportion it was matching on Acrisure's own uncapped layout. Flat
   40px/20px now, every width.
   Font-family/weight deliberately NOT copied along with the sizes --
   theirs is a light-weight serif (Cambon) and this site's single-
   typeface Inter/bold treatment is an explicit, protected brand
   decision, not something this request touched.
   .gform-field-label__text / .gfield_description (the selectors this
   rule used before) don't actually exist on a Section field -- GF
   renders one as <h3 class="gsection_title"> +
   <div class="gsection_description"> directly, no such wrapper spans.
   Confirmed live: the previous rule never matched anything here at
   all, and the "correctly styled" look before this fix was pure
   coincidence -- bold from the browser's own default <h3> weight, navy
   from an inherited page-wide text color, 16px from context, not from
   this block. */
#gform_wrapper_3 .gfield--type-section .gsection_title {
	font-size: 40px; font-weight: 600; letter-spacing: -0.01em; color: #000033;
	line-height: 1.1; text-align: center;
}
#gform_wrapper_3 .gfield--type-section .gsection_description {
	font-size: 20px; color: #5A6C7D; line-height: 1.4; margin-top: 12px;
	text-align: center;
}
/* GF's own default Section-field border-bottom, not something this
   theme ever added on purpose -- removed per request, along with the
   progress bar's own intentional border-bottom right above it (see
   .enxura-progress-zone near the top of this file), so nothing divides
   the progress bar from the headline from the fields below it either. */
#gform_wrapper_3 .gfield--type-section.gsection {
	border-bottom: none;
}

/* .gform_fields, not #gform_fields_3 -- every page's own fields grid
   carries a per-page id (gform_fields_3, gform_fields_3_2, _3_3, ...) but
   they all share this class, so keying off the class applies the grid
   form-wide instead of just page 1. (Not .gform_page_fields -- that's a
   separate OUTER per-page visibility wrapper one level up, with exactly
   one child: this .gform_fields div. Grid-ing the outer wrapper instead
   just stretches its single child to fill one of the two 1fr columns,
   leaving the second empty and squashing every field inside it -- caught
   live via computed widths after the first deploy of this fix.) */
#gform_wrapper_3 .gform_fields {
	/* Row gap 32px. Was 24px (matched to acrisure.com's own computed
	   gap), tried at 20px per an initial ask -- but that 24px had always
	   been stacked on top of the legend's own separate default
	   margin-bottom, which got zeroed in the same round (see the radio
	   legend rule above), so the real drop in total spacing was bigger
	   than either change looked like alone: confirmed live (20px measured
	   exactly via getBoundingClientRect) but still read as visually too
	   tight once the legend's own margin was gone too. 32px restores
	   comfortable breathing room between stacked questions. grid `gap`
	   only ever applies BETWEEN rows -- never before the first field or
	   after the last -- so "every question except the first" falls out
	   automatically, no extra selector needed. Column gap (16px, between
	   side-by-side pairs like First/Last Name) is unrelated to this and
	   left as-is. */
	display: grid; grid-template-columns: 1fr 1fr; gap: 32px 16px;
}
#gform_wrapper_3 .gfield--type-section {
	grid-column: 1 / -1;
}
/* GF's own Orbital theme sets grid-column: 1/-1 directly on every .gfield
   (full-width by default, GF's own layoutGridColumnSpan mechanism) --
   this parent grid alone doesn't touch that, so the fields meant to pair
   up need their own override back down to a single track. */
#gform_wrapper_3 .gfield--type-date,
#gform_wrapper_3 .gfield--type-select,
#gform_wrapper_3 .gfield--type-email,
#gform_wrapper_3 .gfield--type-phone,
#gform_wrapper_3 .gfield--type-text {
	grid-column: span 1 !important;
}
/* ...except when one of those types is the ONLY field on its page (the
   vehicle model question, alone on its own page, is exactly this) --
   half-width only makes sense when there's a second field to pair with;
   otherwise it just strands the field in the left column with the
   right half of the container sitting empty. Caught live via a
   screenshot of the model picker (a .gfield--type-text) using only
   about half the page width with nothing to its right. :only-child
   catches "genuinely alone in the DOM," not just currently the only
   *visible* field -- a field with a conditionally-hidden sibling (like
   the carrier select's own "why not insured" follow-up) still counts
   as having a sibling and keeps the half-width pairing behavior, which
   is fine there since a dropdown doesn't need the full 960px anyway.
   Higher specificity than the type-based rule above (3 classes vs 1,
   same single #gform_wrapper_3 id), so it correctly wins on the fields
   both rules match, regardless of which is declared first. */
#gform_wrapper_3 .gform_fields > .gfield:only-child {
	grid-column: 1 / -1 !important;
}
#gform_wrapper_3 .gfield--type-section { margin-bottom: 10px; }

/* Floating labels: the label sits inside the box like a placeholder
   until the field has focus or a value, then shrinks to a small caption
   pinned to the top -- acrisure.com's "Your Details" pattern. Built with
   :has() (already relied on elsewhere in this file, e.g. the checked-
   choice highlight above) rather than JS, so it needs no page-transition
   re-wiring the way the hand-built pickers on other pages do. Every
   field on this page is a simple one-label-one-input field now (Name
   and Address used to be compound GF fields with their own group-
   heading label and per-sub-input floating labels -- split into
   individual top-level fields since, so that distinction, and the
   .gfield--type-name/-address exclusions and .ginput_complex/
   .gform-field-label--type-sub selectors it required throughout this
   block, no longer apply to anything on this page). */
#gform_wrapper_3 .gfield:not(.gfield--type-section),
#gform_wrapper_3 .enxura-combobox {
	position: relative;
}
/* GF inserts "This field is required." as a normal block element
   BETWEEN the label and .ginput_container -- in DOM order that's fine,
   but it pushes the actual input box down while the floating label
   above stays anchored to the field's own (now taller) box, so the
   label visually detaches from its input, and two paired fields where
   only one errors end up with mismatched input positions. Flexing the
   field and moving the message after the input keeps the input (and
   the label anchored to it) exactly where it was regardless of
   whether an error is showing beneath. */
#gform_wrapper_3 .gfield:not(.gfield--type-section) {
	display: flex; flex-direction: column;
}
#gform_wrapper_3 .gfield:not(.gfield--type-section) > .ginput_container {
	order: 1;
}
#gform_wrapper_3 .gfield:not(.gfield--type-section) > .validation_message {
	order: 2; margin-top: 6px;
}
/* Floating label (sits inside the input box at rest, mimicking
   placeholder text, then shrinks to a small caption above it once
   focused/filled) -- page 1 only, deliberately. Client's own call: the
   material-style treatment reads right for the short, familiar fields
   on the very first screen (First Name, Email, ...), but on every later
   page it looked "carried over" rather than intentional, especially on
   longer questions -- caught live via a screenshot of "What is the
   model of your 2022 Harley-Davidson?" rendering with this same
   material treatment instead of the plain static label every other
   page 2+ element (radio legends, the "Don't see your exact model?"
   manual-entry label) already uses. Scoped via #gform_page_3_1, GF's
   own real per-page id -- not #gform_fields_3, which turned out to be
   the wrong thing to key form-wide rules off of earlier this session
   (it's the inner fields grid one level down, not this page wrapper),
   but is exactly the right thing to scope TO here since the intent this
   time is genuinely page-1-only. See the plain static label rule below
   for every other page. */
#gform_wrapper_3 #gform_page_3_1 .gfield:not(.gfield--type-radio) .gfield_label {
	/* Fixed pixel, not top:50%+translateY -- the field is a flex column
	   now (see the reorder rule above), so its own height grows to fit
	   the validation message sitting below the input when one shows.
	   A percentage here would keep re-centering against that taller
	   total height and drift down whenever an error message appears;
	   an 18px offset targets the input's own 56px box directly; (56 -
	   20px line-height) / 2 = 18, regardless of what's below it. */
	position: absolute !important; left: 15px; top: 18px !important; transform: none;
	margin: 0; font-size: 16px; font-weight: 400; color: #767992;
	pointer-events: none; transition: top .12s ease, font-size .12s ease, font-weight .12s ease;
	z-index: 1; white-space: nowrap; overflow: hidden; text-overflow: ellipsis;
	max-width: calc(100% - 30px);
}
#gform_wrapper_3 #gform_page_3_1 .gfield:not(.gfield--type-radio):has(input:focus) .gfield_label,
#gform_wrapper_3 #gform_page_3_1 .gfield:not(.gfield--type-radio):has(select:focus) .gfield_label,
#gform_wrapper_3 #gform_page_3_1 .gfield:not(.gfield--type-radio):has(input:not(:placeholder-shown)) .gfield_label,
/* :has(select:valid) below is only meaningful for a plain, still-visible
   native select -- GF doesn't actually set the HTML `required` attribute
   on these (only aria-required, a hint for screen readers, not a real
   constraint), so an untouched required-looking select reports :valid
   unconditionally regardless of its value. That's fine as a proxy for
   "has this been touched" on a genuinely visible select, but once a
   field is converted to a combobox (State, Marital Status) its native
   select is hidden and permanently reports :valid this same way,
   incorrectly shrinking the label even while empty -- excluded here,
   since :has(input:not(:placeholder-shown)) above already covers those
   correctly via the real visible text input instead. */
#gform_wrapper_3 #gform_page_3_1 .gfield:not(.gfield--type-radio):not(:has(.enxura-combobox-native)):has(select:valid) .gfield_label,
#gform_wrapper_3 #gform_page_3_1 .enxura-combobox:has(input:focus) .enxura-combobox-label,
#gform_wrapper_3 #gform_page_3_1 .enxura-combobox:has(input:not(:placeholder-shown)) .enxura-combobox-label {
	top: 9px !important; transform: none !important; font-size: 12px; font-weight: 600; color: #5A6C7D;
}
/* Plain static label -- every page except page 1 (see above). Same
   look the "Don't see your exact model? Type it below." manual-entry
   label and every radio question's own legend already use: sits in
   normal flow above the input, one constant size, never floats or
   shrinks. Size/weight/color match the radio legend rule above exactly
   (20px/600/#000033) -- every question on the form reads the same
   regardless of field type, per your own request after comparing a
   select's label (was 16px/#767992, noticeably smaller and lighter)
   against a radio question's legend side by side. */
#gform_wrapper_3 .gform_page:not(#gform_page_3_1) .gfield:not(.gfield--type-radio) .gfield_label {
	display: block !important; position: static !important; margin: 0 0 8px !important;
	font-size: 20px; font-weight: 600; color: #000033; line-height: 1.25;
	white-space: normal; max-width: none;
}
#gform_wrapper_3 input[type="text"],
#gform_wrapper_3 input[type="email"],
#gform_wrapper_3 input[type="tel"],
#gform_wrapper_3 select,
#gform_wrapper_3 .datepicker {
	width: 100%; height: 56px; box-sizing: border-box; border-radius: 10px;
	border: 1px solid #E2E5EB; background: #FFFFFF; color: #000033;
	font-family: var(--sans, inherit); font-size: 16px; line-height: 20px;
	/* Centered padding -- (56 - 20px line-height) / 2 = 18 each side.
	   Correct default now that the label sits in normal flow above the
	   box on every page except page 1 (see the plain static label rule
	   above); page 1 overrides this back to the asymmetric version its
	   own floating label needs room for, right below. */
	padding: 18px 14px; outline: none;
}
#gform_wrapper_3 #gform_page_3_1 input[type="text"],
#gform_wrapper_3 #gform_page_3_1 input[type="email"],
#gform_wrapper_3 #gform_page_3_1 input[type="tel"],
#gform_wrapper_3 #gform_page_3_1 select,
#gform_wrapper_3 #gform_page_3_1 .datepicker {
	padding: 22px 14px 6px;
}
/* The date field's container also holds the calendar-toggle button
   alongside the input (flex row) -- with the box styling above living
   on the input alone, the input was the one item flex-shrinking to
   make room for the button, so the visible white box read as shorter
   than every other field's. Move the box itself onto the container
   (the button then sits inside that same box instead of past its
   right edge) and let the input go borderless/transparent inside it. */
#gform_wrapper_3 .ginput_container_date {
	height: 56px; box-sizing: border-box; border-radius: 10px;
	border: 1px solid #E2E5EB; background: #FFFFFF; position: relative;
}
#gform_wrapper_3 .ginput_container_date .datepicker {
	border: none; background: transparent; padding-right: 40px;
}
#gform_wrapper_3 .ginput_container_date:has(.datepicker:focus) {
	border-color: #1B6FC4;
}

/* Calendar popup restyle (acrisure.com reference) -- GF's own default
   renders two stacked selector rows (year above month), each with its
   own prev/next arrows and a bordered native <select> box, plus a
   "Press F1 for help" footer left over from the widget's own
   accessibility hint, not something worth showing here. Kept the year
   and month <select>s themselves as the real value/submission source --
   removing fast year-jump would make picking an older birth year
   impractical -- but replaced their own native OS dropdown list (can't
   be restyled at all) with a custom grid picker; see
   enhanceDatepickerHeader()/buildDatepickerGridPicker() in
   auto-quote-conversational.js. Also redrew the nav arrows as simple
   chevrons and dropped the year row's own prev/next (the grid picker
   already jumps to any year in one tap, strictly faster). Font sizes
   are deliberately untouched from GF's own defaults -- only color,
   weight, spacing, and the removed chrome are new here. */
#gform_wrapper_3 .gform-datepicker-calendar {
	border: none; border-radius: 12px; padding: 16px 14px;
	font-family: var(--sans, inherit);
}
#gform_wrapper_3 .gform-datepicker-calendar .monthMessage { display: none; }
/* The trigger button that replaces each native <select> -- the select
   itself is still in the DOM (reuses .enxura-combobox-native to stay
   hidden-but-functional, same as the State/Marital Status combobox) so
   GF still submits whatever it's set to. !important throughout: GF's
   own native button theme CSS puts a bordered, shadowed box on plain
   <button> elements here too, at a specificity this scoped selector
   doesn't clear on its own -- same fight already documented elsewhere
   in this file against "GF Orbital theme framework CSS". */
/* A visible border here is deliberate (not left over from GF's own
   native <select> box) -- plain text alone didn't read as clickable, so
   this gives month/year their own pill so people know they can tap
   them; the nav arrows next to them stay plain (see
   .enxura-datepicker-header-arrow below), since only these two actually
   open something. Both triggers get relocated into
   .enxura-datepicker-header-row (built in enhanceDatepickerHeader() in
   the JS) so month and year sit side by side on one line rather than
   GF's own two stacked rows -- margin:0 here (not auto-centered) since
   that flex row, not this element's original table cell, now controls
   its position. */
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger {
	appearance: none !important; -webkit-appearance: none !important; -moz-appearance: none !important;
	box-shadow: none !important; border: 1px solid #E2E5EB !important;
	background-color: #FFFFFF !important; width: auto !important; height: auto !important;
	margin: 0 !important; display: block !important; cursor: pointer; flex: none;
	padding: 6px 26px 6px 12px !important; border-radius: 8px !important;
	font-family: inherit !important; font-size: 16px !important;
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='10' height='7' viewBox='0 0 12 8'%3E%3Cpath d='M1 1l5 5 5-5' fill='none' stroke='%23767992' stroke-width='1.6'/%3E%3C/svg%3E") !important;
	background-repeat: no-repeat !important; background-position: right 10px center !important;
	transition: border-color .12s ease, color .12s ease;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger--year {
	color: #767992; font-weight: 400 !important;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger--month {
	color: #000033; font-weight: 700 !important;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger:hover,
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger.open {
	color: #1B6FC4; border-color: #1B6FC4 !important;
}
/* Month + year on one line ("‹ August 2026 ›") -- built fresh each
   enhancement pass in enhanceDatepickerHeader(), replacing GF's own two
   stacked year/month <tr>s (hidden via inline style, not removed --
   their <select>s and prev/next <td>s are still functionally needed). */
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-row {
	display: flex; align-items: center; justify-content: center; gap: 10px;
	padding: 2px 0 6px;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow {
	appearance: none !important; -webkit-appearance: none !important;
	border: none !important; box-shadow: none !important; background-color: transparent !important;
	padding: 0 !important; outline: none; flex: none;
	position: relative; width: 28px !important; height: 28px !important;
	color: #767992; cursor: pointer; border-radius: 6px;
	transition: background .12s ease, color .12s ease;
}
/* currentColor (used for the arrow's own <td> fallback above) doesn't
   work here -- confirmed live, GF's own button-theme CSS applies more
   broadly to real <button> elements than it did to the <td>-as-button
   arrows, and was forcing this ::before's border-color to white,
   invisible on the white pill. Explicit colors + !important sidestep it
   entirely rather than fighting inheritance. */
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow::before {
	content: "" !important; position: absolute !important; top: 50% !important; left: 50% !important;
	width: 7px !important; height: 7px !important; margin: -4px 0 0 -4px !important;
	border: none !important;
	border-right: 1.5px solid #767992 !important; border-top: 1.5px solid #767992 !important;
	background: none !important;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow--prev::before { transform: rotate(-135deg); }
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow--next::before { transform: rotate(45deg); }
/* :focus-visible only (not :focus), same reasoning as the trigger's own
   arrow fallback above -- a mouse click shouldn't show it, keyboard nav
   should. */
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow:hover,
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow:focus-visible {
	background-color: #F1F3F7 !important; color: #000033;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow:hover::before,
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow:focus-visible::before {
	border-right-color: #000033 !important; border-top-color: #000033 !important;
}
/* Grid picker panel -- takes over the exact spot the day grid normally
   occupies (see the tbody rule below, which hides the day rows while
   this is open) rather than floating over them, so there's no overlay
   positioning to keep in sync with the calendar's own size. */
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-panel {
	display: none; grid-template-columns: repeat(4, 1fr); gap: 2px;
	padding: 10px 2px 4px;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-panel.open {
	display: grid;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-panel--year {
	max-height: 220px; overflow-y: auto;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-cell {
	appearance: none !important; -webkit-appearance: none !important;
	border: none !important; box-shadow: none !important; background: transparent !important;
	cursor: pointer; padding: 9px 4px !important; border-radius: 8px !important;
	font-family: inherit !important; font-size: 14px !important; font-weight: 400 !important;
	color: #000033; text-align: center; transition: background .12s ease, color .12s ease;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-cell:hover {
	background: #E8F1FB !important;
}
#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-cell.selected {
	background: #1B6FC4 !important; color: #FFFFFF; font-weight: 600 !important;
}
/* While a grid picker is open, hide the day-of-week header and day rows
   (everything in the table except the year/month header rows, which
   stay visible so their trigger remains reachable to close it) -- the
   picker panel above then sits right where they were. */
#gform_wrapper_3 .gform-datepicker-calendar.enxura-datepicker-open .calendar tbody > tr:not(.yearSelector):not(.monthSelector) {
	display: none;
}
/* The year row's own prev/next controls are redundant with the select
   above (and much slower) -- visibility:hidden rather than display:none
   so the cell keeps its width and the year select stays centered under
   the same 3-cell [arrow][select][arrow] structure the month row below
   it uses; it also drops these from the tab order, unlike opacity:0. */
#gform_wrapper_3 .gform-datepicker-calendar tr.yearSelector td.nav.btn {
	visibility: hidden;
}
#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.btn {
	position: relative; color: #767992; cursor: pointer; outline: none;
	width: 28px; border-radius: 6px; transition: background .12s ease, color .12s ease;
}
#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.btn span {
	display: none;
}
#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.btn::before {
	content: ""; position: absolute; top: 50%; left: 50%;
	width: 7px; height: 7px; margin: -4px 0 0 -4px;
	border-right: 1.5px solid currentColor; border-top: 1.5px solid currentColor;
}
#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.prev::before { transform: rotate(-135deg); }
#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.next::before { transform: rotate(45deg); }
/* Hover and keyboard focus share the same subtle background instead of
   the browser's own default focus ring -- that default outline is a
   hard rectangle around this circular button, which read as a stray
   square box rather than a focus state. :focus-visible only (not
   :focus) so a mouse click doesn't also trigger it -- keyboard nav
   still gets a clearly visible state, just not a squared-off one. */
#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.btn:hover,
#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.btn:focus-visible {
	background: #F1F3F7; color: #000033;
}
#gform_wrapper_3 .gform-datepicker-calendar th.week {
	color: #8A93A8; font-weight: 600; letter-spacing: 0.02em; padding: 10px 0 6px;
}
/* Two-letter weekday abbreviations (Su/Mo/Tu...) instead of GF's default
   single letters. Column order itself is Sunday-first via WordPress's
   own start_of_week option (0), which GF's calendar JS reads directly
   (localized as gform_i18n.datepicker.wdOffset) -- that's a site-wide
   setting, not scoped to just this field, flagged since it'd affect any
   other GF date field the same way. Given that fixed order, nth-child
   can safely target each column directly here. font-size:0 on the real
   span hides GF's own single-letter text without removing it (still
   there for anything reading the DOM/accessibility tree); the
   replacement text goes on ::before instead, at the header's normal
   size. */
#gform_wrapper_3 .gform-datepicker-calendar th.week span {
	font-size: 0;
}
#gform_wrapper_3 .gform-datepicker-calendar th.week span::before {
	font-size: 12px;
}
#gform_wrapper_3 .gform-datepicker-calendar th.week:nth-child(1) span::before { content: "Su"; }
#gform_wrapper_3 .gform-datepicker-calendar th.week:nth-child(2) span::before { content: "Mo"; }
#gform_wrapper_3 .gform-datepicker-calendar th.week:nth-child(3) span::before { content: "Tu"; }
#gform_wrapper_3 .gform-datepicker-calendar th.week:nth-child(4) span::before { content: "We"; }
#gform_wrapper_3 .gform-datepicker-calendar th.week:nth-child(5) span::before { content: "Th"; }
#gform_wrapper_3 .gform-datepicker-calendar th.week:nth-child(6) span::before { content: "Fr"; }
#gform_wrapper_3 .gform-datepicker-calendar th.week:nth-child(7) span::before { content: "Sa"; }
#gform_wrapper_3 .gform-datepicker-calendar td.day {
	color: #000033; text-align: center; padding: 3px 0; cursor: pointer;
}
#gform_wrapper_3 .gform-datepicker-calendar td.day span {
	display: inline-flex; align-items: center; justify-content: center;
	width: 30px; height: 30px; border-radius: 50%;
	transition: background .12s ease, color .12s ease;
}
#gform_wrapper_3 .gform-datepicker-calendar td.day:hover span {
	background: #E8F1FB;
}
#gform_wrapper_3 .gform-datepicker-calendar td.day.selected span {
	background: #1B6FC4; color: #FFFFFF; font-weight: 600;
}
/* GF's own select styling sets a 38px line-height -- taller than the
   26px this padding actually leaves for content (56px box minus 2px
   border minus 28px padding), so its line box overflowed the visible
   area and clipped descenders (the tail on "g", "y", ...). The line-
   height above fixes it for every field type at once. */
/* The datepicker's own "mm/dd/yyyy" placeholder would sit on top of the
   floating label while empty -- keep it invisible until focus, by which
   point the label has already shrunk out of the way. Scoped to page 1
   specifically -- floating labels only exist there since round 5 of
   this session (every other page uses a plain static label instead,
   with nothing for a visible placeholder to collide with) -- this rule
   wasn't scoped down to match at the time, so it was still hiding the
   search box's "Type to search..." and the manual-entry "Type your
   ..." placeholders on every later page until the field was clicked,
   with no floating label there to have been protecting against in the
   first place. Caught live via a screenshot of the BMW model page
   showing both placeholders blank at rest. */
#gform_wrapper_3 #gform_page_3_1 input:not(:focus)::placeholder {
	color: transparent;
}
/* Selects on this page are always behind an .enxura-combobox now (State,
   Marital Status) -- this styles the rare native <select> that isn't
   (currently none visible, kept as a safety net) so it doesn't render
   unstyled if a future field skips the combobox treatment. */
#gform_wrapper_3 select {
	appearance: none; -webkit-appearance: none;
	background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='12' height='8' viewBox='0 0 12 8'%3E%3Cpath d='M1 1l5 5 5-5' fill='none' stroke='%235A6C7D' stroke-width='1.6'/%3E%3C/svg%3E");
	background-repeat: no-repeat; background-position: right 14px center; padding-right: 34px;
}
#gform_wrapper_3 input:focus,
#gform_wrapper_3 select:focus { border-color: #1B6FC4; }

/* State combobox -- native select stays functional (GF still submits
   its value) but visually hidden behind the type-to-filter input. */
#gform_wrapper_3 .enxura-combobox-native {
	position: absolute; opacity: 0; height: 0; width: 0; pointer-events: none;
}
#gform_wrapper_3 .enxura-combobox-input { cursor: text; }
#gform_wrapper_3 .enxura-combobox-panel {
	display: none; position: absolute; left: 0; right: 0; top: calc(100% + 4px);
	background: #FFFFFF; border: 1px solid #E2E5EB; border-radius: 10px;
	box-shadow: 0 12px 24px -8px rgba(0,0,0,0.2); max-height: 240px; overflow-y: auto;
	z-index: 5; padding: 6px;
}
#gform_wrapper_3 .enxura-combobox.open .enxura-combobox-panel { display: block; }
#gform_wrapper_3 .enxura-combobox-item {
	padding: 10px 10px; border-radius: 6px; font-size: 15px; color: #000033; cursor: pointer;
}
#gform_wrapper_3 .enxura-combobox-item:hover,
#gform_wrapper_3 .enxura-combobox-item.highlighted { background: #E8F1FB; }
#gform_wrapper_3 .enxura-combobox-item.selected { color: #1B6FC4; font-weight: 600; }
#gform_wrapper_3 .enxura-combobox-empty { padding: 10px; font-size: 14px; color: #767992; }

/* Error state -- GF adds gfield_error to the field itself once validated
   as invalid (on a failed submit, matching the no-persistent-"(Required)"
   behavior above: nothing shows until they've actually left it blank). */
#gform_wrapper_3 .gfield_error input,
#gform_wrapper_3 .gfield_error select {
	border-color: #C0392B;
}
/* DOB's own visible box border lives on .ginput_container_date, not the
   <input> itself (the input was made borderless so the calendar-toggle
   button could share its box without squeezing it short -- see that
   fix's comment above) -- the rule above alone never reaches it. */
#gform_wrapper_3 .gfield_error .ginput_container_date {
	border-color: #C0392B;
}
#gform_wrapper_3 .gfield_error .gfield_label {
	color: #C0392B;
}
#gform_wrapper_3 .gfield_error .gfield_validation_message,
#gform_wrapper_3 .gfield_error .validation_message {
	color: #C0392B; font-size: 13px; margin-top: 4px;
}

/* ===== "Welcome back" resume prompt ===== */
/* Appended to <body>, not the form wrapper -- it needs to sit above the
 * whole page, including the site header, not just this form's own
 * card. Deliberately NOT scoped under #gform_wrapper_3 for that reason. */
.enxura-resume-overlay {
	position: fixed; inset: 0; z-index: 9999;
	background: rgba(0, 0, 51, 0.55);
	display: flex; align-items: center; justify-content: center;
	padding: 20px;
}
.enxura-resume-card {
	background: #FFFFFF; border-radius: 16px; padding: 28px 24px;
	max-width: 400px; width: 100%;
	box-shadow: 0 20px 50px rgba(0, 0, 51, 0.25);
	text-align: center;
}
.enxura-resume-title {
	font-size: 20px; font-weight: 700; color: #000033;
	margin: 0 0 8px;
}
.enxura-resume-body {
	font-size: 15px; line-height: 1.4; color: #5A6C7D;
	margin: 0 0 20px;
}
.enxura-resume-actions {
	display: flex; flex-direction: column; gap: 10px;
}
.enxura-resume-continue, .enxura-resume-restart {
	font-family: inherit; font-size: 15px; font-weight: 700;
	border-radius: 10px; padding: 12px 16px; cursor: pointer;
	border: none;
}
.enxura-resume-continue {
	background: #1B6FC4; color: #FFFFFF;
}
.enxura-resume-continue:hover { background: #17599F; }
.enxura-resume-restart {
	background: none; color: #767992;
}
.enxura-resume-restart:hover { color: #000033; }

@media (prefers-color-scheme: dark) {
	.enxura-resume-card { background: #14152A; box-shadow: 0 20px 50px rgba(0, 0, 0, 0.5); }
	.enxura-resume-title { color: #F1F2F8; }
	.enxura-resume-body { color: #B9BCD9; }
	.enxura-resume-restart { color: #8A8DAD; }
	.enxura-resume-restart:hover { color: #F1F2F8; }
}

@media (prefers-color-scheme: dark) {
	#gform_wrapper_3 .enxura-progress-zone { border-color: #272A45; }
	#gform_wrapper_3 .enxura-progress-track { background: #1A2A3E; }
	#gform_wrapper_3 .enxura-progress-fill { background: #5B9EE0; }
	#gform_wrapper_3 .gfield--type-radio legend.gfield_label,
	#gform_wrapper_3 .gfield--type-radio .gform-field-label__text { color: #F1F2F8; }
	#gform_wrapper_3 .ginput_container_radio .gchoice { background: #14152A; border-color: #272A45; }
	#gform_wrapper_3 .ginput_container_radio .gchoice label { color: #F1F2F8; }
	#gform_wrapper_3 .enxura-search-wrap input { background: #14152A; color: #F1F2F8; border-color: #272A45; }
	#gform_wrapper_3 .enxura-other-message { background: #1A2A3E; border-color: #2A4A6E; color: #F1F2F8; }
	#gform_wrapper_3 .enxura-other-message a { color: #5B9EE0; }
	#gform_wrapper_3 .enxura-multi-vehicle-message { background: #1A2A3E; border-color: #2A4A6E; color: #F1F2F8; }
	#gform_wrapper_3 .gform_next_button:disabled, #gform_wrapper_3 .gform_button:disabled { background: #3A3D5A; }
	#gform_wrapper_3 .enxura-model-opt { background: #14152A; border-color: #272A45; color: #F1F2F8; }
	#gform_wrapper_3 .enxura-model-loading, #gform_wrapper_3 .enxura-model-note { color: #8A8DAD; }
	#gform_wrapper_3 .enxura-manual-entry { border-color: #272A45; }
	#gform_wrapper_3 .enxura-manual-entry label { color: #8A8DAD; }
	#gform_wrapper_3 .enxura-manual-entry-row input { background: #14152A; color: #F1F2F8; border-color: #272A45; }
	#gform_wrapper_3 .gfield--type-section .gsection_title { color: #F1F2F8; }
	#gform_wrapper_3 .gfield--type-section .gsection_description { color: #8A8DAD; }
	#gform_wrapper_3 .gfield_label { color: #8A8DAD; }
	#gform_wrapper_3 input[type="text"],
	#gform_wrapper_3 input[type="email"],
	#gform_wrapper_3 input[type="tel"],
	#gform_wrapper_3 select,
	#gform_wrapper_3 .datepicker {
		background: #14152A; color: #F1F2F8; border-color: #272A45;
	}
	#gform_wrapper_3 .gform-datepicker-calendar { background: #14152A; }
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger {
		border-color: #272A45 !important; background-color: #14152A !important;
	}
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger--year { color: #8A8DAD; }
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger--month { color: #F1F2F8; }
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger:hover,
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-trigger.open {
		color: #5B9EE0; border-color: #5B9EE0 !important;
	}
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow { color: #8A8DAD; }
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow::before {
		border-right-color: #8A8DAD !important; border-top-color: #8A8DAD !important;
	}
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow:hover,
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow:focus-visible {
		background-color: #1A2A3E !important; color: #F1F2F8;
	}
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow:hover::before,
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-header-arrow:focus-visible::before {
		border-right-color: #F1F2F8 !important; border-top-color: #F1F2F8 !important;
	}
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-cell { color: #F1F2F8; }
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-cell:hover { background: #1A2A3E !important; }
	#gform_wrapper_3 .gform-datepicker-calendar .enxura-datepicker-cell.selected { background: #5B9EE0 !important; color: #14152A; }
	#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.btn { color: #8A8DAD; }
	#gform_wrapper_3 .gform-datepicker-calendar tr.monthSelector td.nav.btn:hover { background: #1A2A3E; color: #F1F2F8; }
	#gform_wrapper_3 .gform-datepicker-calendar th.week { color: #6C6F8C; }
	#gform_wrapper_3 .gform-datepicker-calendar td.day { color: #F1F2F8; }
	#gform_wrapper_3 .gform-datepicker-calendar td.day:hover span { background: #1A2A3E; }
	#gform_wrapper_3 .gform-datepicker-calendar td.day.selected span { background: #5B9EE0; color: #14152A; }
}