/*
Theme Name: Keymergency Divi Child
Template: Divi
Description: Child theme for Keymergency Locksmith — carries page-level SEO (titles, meta descriptions) and JSON-LD schema (FAQPage on the homepage and automotive FAQ blocks; LocalBusiness as a service-area business) that Divi and its Design Variables don't own. No visual overrides live here — the design lives entirely in Divi 5 Design Variables and native module content.
Version: 1.0
*/

/* 2026-09-22: reverted the B3 negative-margin logo overhang added on 2026-09-21 (see git history /
   prior comment here for that rationale) -- user feedback on the live site was that the logo now
   sits too high and out of line with the nav/phone button beside it. Removing the margin lets the
   logo sit in normal flow, vertically centered with its row siblings like everything else in this
   header row. overflow:visible on the row is left in place since it's harmless now and other
   header content may still rely on not being clipped. */
#page-container .et_pb_row_1_tb_header {
	overflow: visible !important;
}

/* 2026-10-15: per explicit request, the header should never stick to the top of the viewport
   while scrolling. This reverts the B5 fix above (2026-09-xx), which had manually forced
   position:sticky here to work around Divi 5.7.4 silently dropping the header nav section's own
   native "sticky" block attribute (module.decoration.sticky.desktop.value.position = "top",
   still present in the header template's stored content). Since Divi's own rendering bug already
   keeps that native attribute from ever taking effect, removing this CSS override is sufficient
   on its own -- no position:sticky rule reaches this element from anywhere now, confirmed live. */

/* Ultrareview batch A (2026-09-21): blurb/card titles (.et_pb_module_header, e.g. "30-Minute
   Arrival Guarantee") render as H4 tags already, but no global or per-module rule sets their
   size/weight — Divi's core typography customizer only exposes one overall "Header Text Size"
   option (which drives H1), not a separate per-level H4 size, so there's no single global
   setting that reaches this. Matches design-token spec: H4 = 20px/600. */
#page-container .et_pb_module_header {
	font-size: 20px !important;
	font-weight: 600 !important;
}

/* Ultrareview batch A: gap between every H2 and its red rule was ~46px instead of the spec's
   16px. The divider module's own margin-top is already correct at 16px (confirmed by reading
   the generated CSS directly) — the extra space is Divi's default
   ".et_pb_column .et_pb_module{margin-bottom:30px}" landing on the H2 text module itself, the
   same root cause fixed earlier for the header row and the contact-form title gap. Targeting
   "any module directly followed by a divider" fixes every H2+rule pair sitewide from one rule,
   and self-applies to any future H2+rule pairing built the same way. */
#page-container .et_pb_module:has(+ .et_pb_divider) {
	margin-bottom: 0 !important;
}

/* Kill entrance/scroll animations site-wide. Per-module animation_style attributes trigger a
   Divi 5.7.4 shortcode-conversion bug when combined with an explicit font-size attribute (the
   module silently falls back to a legacy render path that drops its custom CSS), so animations
   are disabled here instead of per-module. Hover transitions (handled by Divi's own hover
   states) are unaffected. */
.et_pb_module,
.et_pb_module.et-waypoint,
.et_pb_extra_column .et_pb_module {
	opacity: 1 !important;
	transform: none !important;
}

/* Guarantee full-bleed sections and correctly-filled rows site-wide.
   Divi 5.7.4's shortcode-conversion pipeline intermittently drops or loses the width
   declarations these need (confirmed via direct inspection of generated CSS across many
   rebuild passes), and per-shortcode-attribute fixes kept getting silently undone by other
   conversion bugs. These two rules are the reliable fix: every Section fills the viewport
   edge to edge, and every Row fills up to whatever max-width Divi itself assigned it (so a
   790px or 900px row still centers at its own width — this never widens a row, only stops
   it from shrinking below its intended width). #page-container raises specificity above
   Divi's own generated rules regardless of stylesheet load order. */
#page-container .et_pb_section {
	width: 100% !important;
	max-width: none !important;
}
#page-container .et_pb_row,
#page-container .et_pb_row_inner {
	width: 100% !important;
}

/* Center buttons that share a column with centered text (hero, service-areas band, and any
   future section built the same way). Divi's Button module wraps its link in its own
   .et_pb_button_module_wrapper div that defaults to text-align:left regardless of the column's
   text alignment — it only centers if the module's own "Button Alignment" setting is explicitly
   set to center, which none of these were. Rather than patching each button module one at a
   time, this rule centers any button wrapper that's a direct sibling of a centered text module
   in the same column, so it self-applies to new centered sections without another CSS edit. */
#page-container .et_pb_column:has(> .et_pb_text_align_center) > .et_pb_button_module_wrapper {
	text-align: center !important;
}

/* Left/right-icon Blurb modules ("check blurb" list items, e.g. the "Why Choose Keymergency
   Locksmith?" list) inherit Divi's base .et_pb_blurb_content rule of
   "max-width:550px;margin:0 auto", which horizontally centers that box within its column even
   though the text inside it is already left-aligned. In a column wider than 550px this reads as
   the whole blurb being centered rather than flush against the column's left edge. Zeroing the
   margin only for the left/right icon-placement variants (not the default top-icon/centered
   card style, which should stay centered) makes the block hug the column edge as expected. */
#page-container .et_pb_blurb_position_left .et_pb_blurb_content,
#page-container .et_pb_blurb_position_right .et_pb_blurb_content {
	margin: 0 !important;
}

/* Header: Divi 5.7.4's renderer assigns the wrong width class to divi/column-inner elements
   regardless of their correctly-stored "3_4"/"1_4" type (confirmed by inspecting both the raw
   block data and the isolated conversion output — both are correct; only the rendered class
   is wrong, always "et_pb_column_4_4", which the theme's static CSS sets to width:100%).
   Column layout here is classic float-based (.et_block_row .et_pb_column{float:left}, with a
   clearfix on the row), not flexbox — so the fix is float + width + zeroed gutter margin, not
   flex properties. That wrong class was pushing the header's phone button below the nav menu
   instead of beside it. Targeting the two known column-inner IDs directly, since this is a
   one-off pair in the shared header template, not a sitewide pattern.
   Wrapped in min-width:981px (Divi's own tablet/mobile cutoff is max-width:980px) because these
   same column-inner elements also carry the base .et_pb_column class, and Divi's own responsive
   CSS stacks columns to width:100% below 980px to switch to the hamburger menu. Forcing
   width:75%/25% unconditionally would have fought that stacking and broken the mobile layout. */
@media (min-width: 981px) {
	#page-container .et_pb_column_inner_0_tb_header {
		float: left !important;
		width: 75% !important;
		max-width: 75% !important;
		margin-right: 0 !important;
	}
	#page-container .et_pb_column_inner_1_tb_header {
		float: left !important;
		width: 25% !important;
		max-width: 25% !important;
		margin-right: 0 !important;
	}
}

/* Map band placeholder. No Google Maps API key is configured yet (documented in
   BUILD-NOTES.md), so the map module's inner canvas never initializes and collapses to
   zero height regardless of the min-height set on its own module attributes. This mirrors
   the export's own placeholder treatment for the same "no map key yet" state
   (export/styles.css .map background) so the band reads as an intentional placeholder,
   not a rendering failure, until a real key is added. */
#page-container .et_pb_map_container,
#page-container .et_pb_map {
	min-height: 420px !important;
	background: repeating-linear-gradient(135deg, #ececec 0 12px, #f4f4f4 12px 24px) !important;
}

/* Header nav: the menu module's own custom-CSS field set color/weight but never set
   font-size, so links fell back to a much larger Divi default — wide enough that the 7-item
   nav overflowed its column. Confirmed by inspecting the generated per-page CSS: no
   font-size rule existed for this menu at all. Matches export/styles.css .nav a (15px).
   Divi's own static CSS also adds 11px+11px of padding on every <li> (.et_pb_menu .et-menu>li),
   which combined with the 14px+14px on each <a> below used to add up to 50px of pure padding
   per item — with 7 items that's 350px, more than enough on its own to push the last two links
   onto a second line even before accounting for their text width. Zeroing the <li> padding and
   using a single margin-right gap between items (mirroring export/styles.css .nav's flex gap)
   gets all 7 items back on one line beside the logo and phone button. */
/* Header row 1 (logo | nav + phone button): Divi's own stock rule
   ".et_pb_column .et_pb_module{margin-bottom:30px}" applies to every module that has ANY
   .et_pb_column ancestor — which includes the menu module and the button's wrapper div, both
   nested two columns deep (row > column > row_inner > column_inner). That 30px trailing margin
   made the nav+button column's total box taller than the logo's box, so when the row centers
   the two columns vertically (align-items:center), the nav+button content itself lands slightly
   higher than the logo's — reading as mismatched top/bottom spacing between them instead of one
   flush 80px-tall bar, per export/styles.css .hdr__inner. Zeroing it on every module in this
   row (logo included, for consistency) removes that extra box height so all three line up. */
#page-container .et_pb_row_1_tb_header .et_pb_module {
	margin-bottom: 0 !important;
}

/* Same header row, a second stacked cause: the nav+button's row_inner
   (et_pb_row_inner_0_tb_header) sits inside a 3/4-width column, so two of Divi's own generic
   rules add vertical padding to it — ".et_pb_column_3_4 .et_pb_row_inner{padding:3.735% 0}"
   (static CSS, ≥981px) and ".et_block_row{padding:27px 0}" (generated CSS, ≥1350px), found via
   the user's own DevTools inspection. Neither is !important, but together they were inflating
   this row_inner's box well past the logo's height, compounding the margin-bottom issue above.
   Targeting the row_inner's own unique ID class with !important beats both regardless of which
   one the cascade would otherwise pick at a given viewport width. */
#page-container .et_pb_row_inner_0_tb_header {
	padding: 0 !important;
}

/* Same reasoning as the column-inner fix above: these tighten spacing so the 7-item desktop
   nav fits on one line, including a forced white-space:nowrap, which has no business applying
   inside Divi's separate mobile dropdown menu. Scoped to the same min-width:981px desktop
   cutoff so mobile/tablet keep Divi's own stacked, wrapping menu behavior untouched. */
@media (min-width: 981px) {
	#page-container .et_pb_menu_0_tb_header .et-menu > li {
		padding-left: 0 !important;
		padding-right: 0 !important;
		margin-right: 20px !important;
	}
	#page-container .et_pb_menu_0_tb_header .et-menu > li:last-child {
		margin-right: 0 !important;
	}
	#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li > a {
		font-size: 15px !important;
		padding: 8px 0 !important;
		white-space: nowrap;
	}
	/* 2026-10-06: per explicit report, the dropdown-indicator arrow on "Services" (the only nav
	   item with a submenu) sat on top of the last couple letters of the word instead of beside it.
	   Root cause: Divi's own arrow is a pseudo-element with position:absolute; right:0; top:0; and
	   no width of its own -- it shrink-wraps to the glyph and anchors flush against the link's own
	   right edge. The link's own padding-right was 0 (set by the padding:8px 0 rule just above,
	   part of this project's own desktop nav sizing), so the link's box ended exactly where the
	   text ended, leaving the arrow nowhere to sit but directly over the last few characters.
	   Reserving 20px of padding-right (scoped to menu items with children only, via
	   .menu-item-has-children, so regular links without a dropdown don't gain unwanted spacing)
	   gives the arrow empty space to occupy instead of overlapping text. Also recentered the arrow
	   vertically with top:50%/translateY(-50%) instead of Divi's own top:0, which had it sitting
	   flush with the link's top edge rather than centered against the text's own line-height. */
	#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li.menu-item-has-children > a:first-child {
		padding-right: 20px !important;
	}
	#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li.menu-item-has-children > a:first-child::after {
		top: 50% !important;
		transform: translateY(-50%) !important;
	}
}

/* Header nav link color: one menu item ("Service Areas", a custom #areas anchor on the
   homepage) was picking up WordPress's own current-menu-item class because its URL happens to
   match the current page, which combined with Divi's default current-item styling made it (and
   the real current page, "Home") render brighter/underlined than the other five links — visibly
   inconsistent colors across the nav. Forcing every state (link, current, ancestor, hover) to
   the same rule set removes that inconsistency regardless of which item WordPress marks as
   "current". Hover eases to --gvid gray-300 (#D9D9D9, an existing Design Variable), a shade
   just dark enough to read as a hover state while staying clearly legible on the #2B2A29 header. */
#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li > a,
#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li.current-menu-item > a,
#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li.current-menu-ancestor > a {
	color: #FFFFFF !important;
	transition: color 150ms ease !important;
}
#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li > a:hover,
#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li.current-menu-item > a:hover,
#page-container .et_pb_menu_0_tb_header nav.et-menu-nav ul.et-menu > li.current-menu-ancestor > a:hover {
	color: var(--gvid-7068e09d-0595-4161-8104-168d04669178) !important;
}

/* Below 980px the logo, nav (collapsed to a hamburger icon) and phone button stack vertically
   instead of sitting on one row, each keeping whatever alignment/padding it had at desktop
   (logo pinned left via margin-right:auto, nav pinned right via text-align:right +
   justify-content:flex-end, button with no alignment override at all — effectively left).
   Centering all three and giving each a little vertical padding makes the stacked header read
   as one deliberate, breathing block instead of three misaligned rows. */
@media (max-width: 980px) {
	#page-container .et_pb_image_0_tb_header {
		margin-left: auto !important;
		margin-right: auto !important;
		padding-top: 16px !important;
		padding-bottom: 16px !important;
	}
	#page-container .et_pb_menu_0_tb_header {
		text-align: center !important;
		padding-top: 16px !important;
		padding-bottom: 16px !important;
	}
	#page-container .et_pb_menu_0_tb_header .et_pb_menu__wrap {
		justify-content: center !important;
	}

	/* The hamburger icon itself isn't actually positioned by .et_pb_menu__wrap above — it sits in
	   a separate .et_mobile_nav_menu element inside .et_pb_menu_inner_container, which Divi sets
	   to justify-content:space-between (meant to spread a left-side element and this icon to
	   opposite ends). With the desktop <ul> hidden at this width, that leaves the icon alone in
	   the container, and space-between renders a single flex item at the start — flush left,
	   which is why centering .et_pb_menu__wrap alone didn't move it. */
	#page-container .et_pb_menu_0_tb_header .et_pb_menu_inner_container {
		justify-content: center !important;
	}

	/* Divi colors the hamburger icon from its own global "primary color" Design Variable
	   (--gcid-primary-color), which is Divi's factory-default blue, not anything from this
	   site's own palette — hence the mismatched blue icon on the dark header. */
	#page-container .et_pb_menu_0_tb_header .mobile_nav .mobile_menu_bar:before {
		color: #FFFFFF !important;
	}

	#page-container .et_pb_button_0_tb_header_wrapper {
		text-align: center !important;
		padding-top: 16px !important;
		padding-bottom: 16px !important;
	}

	/* Divi's own default mobile dropdown menu link color (.et_mobile_menu li a{color:#666}) is a
	   dark gray meant for a light dropdown background — this menu's dropdown is dark charcoal
	   (#2B2A29, set elsewhere in this file's generated CSS), so those links were unreadable.
	   Matches the white the same links already use when the full desktop menu is open. */
	#page-container .et_pb_menu_0_tb_header .et_mobile_menu li a {
		color: #FFFFFF !important;
	}
}

/* The single actual root cause of the sitewide width bug, found via browser DevTools:
   .et_pb_row_0_tb_body — the Row in the shared Body theme-builder template that wraps the
   [et_pb_post_content] module — carries Divi's generated max-width:1200px!important. Every
   page's own sections render as children of divi/post-content, i.e. inside this row, so their
   own width:100% was always resolving against this 1200px-capped ancestor, not the viewport.
   That's why fixing individual sections/rows never escaped it. This row should carry no
   width constraint at all — it's a pure passthrough; each page's own inner rows (already
   correctly set to 1200px/820px/900px etc.) are what should cap content width. */
#page-container .et_pb_row_0_tb_body {
	max-width: none !important;
	width: 100% !important;
}

/* The same passthrough section/row also carries Divi's generic, non-!important default
   padding — ".et_pb_section{padding:54px 0}" and ".et_block_row{padding:27px 0}", both scoped
   to "@media (min-width:1350px)" — on et_pb_section_0_tb_body and et_pb_row_0_tb_body
   respectively (found via the user's own DevTools inspection). Since every real page section
   already sets its own explicit padding (e.g. the hero's 96px), this wrapper section/row has no
   content of its own to pad; the 54px+27px was pure dead space between the header and whichever
   section a given page starts with. Zeroing both removes that gap on all six pages, since they
   all share this one Body template. */
#page-container .et_pb_section_0_tb_body,
#page-container .et_pb_row_0_tb_body {
	padding: 0 !important;
}

/* Footer text links: the only plain-text link in the footer template ("Email Us") carries an
   inline style="color:#FFFFFF" set directly on the module, which (being inline) already beats
   any class-based hover rule the site's global link styles would otherwise apply — so on hover
   it was staying pure white with no visible state change at all. Scoping to
   ".et-l--footer .et_pb_text_inner a" targets plain-text links inside Text modules specifically
   (not the two Button-module CTAs in the footer, which already have their own clearly visible
   white/red button styling, and not the social icons, which live in a <ul> outside
   .et_pb_text_inner) — so this covers this link today and any future plain-text link added to a
   footer Text module without needing another edit. Hover eases to gray-300 (#D9D9D9), the same
   Design Variable already used for the header nav's hover state, for a consistent hover language
   across the site. */
#page-container .et-l--footer .et_pb_text_inner a {
	color: #FFFFFF !important;
	transition: color 150ms ease !important;
}
#page-container .et-l--footer .et_pb_text_inner a:hover {
	color: var(--gvid-7068e09d-0595-4161-8104-168d04669178) !important;
}

/* Footer H4s: the three blurb sub-headings in the footer (Service Area, Service Hours,
   Arrival Guarantee) render as <h4 class="et_pb_module_header">, which has no color override
   anywhere in the generated CSS — confirmed by searching both the static and dynamic
   stylesheets for a .et_pb_module_header rule, finding none. It was falling back to Divi's
   default heading color (~#333), effectively invisible against the #2B2A29 footer background.
   The two column H2s ("Location & Hours", "Contact Us") already have their own
   color:#FFFFFF!important rule; this brings the H4s in line with that. */
#page-container .et-l--footer .et_pb_module_header {
	color: #FFFFFF !important;
}

/* Phone-number buttons site-wide: once the functions.php filter restores the missing
   data-icon="&#xe090;" attribute (see render_block_divi/button), Divi's own per-button
   generated CSS still carries a competing "...:hover:after{content:''...}" rule left over from
   when these buttons had an explicit (buggy) icon config. That rule isn't !important, but it
   does carry #page-container's own ID in its selector, so a plain override without !important
   wouldn't reliably beat it. Forcing content:attr(data-icon) here — the same mechanism Divi's
   own default (icon-less-config) buttons already use successfully — makes the icon show. Listed
   by class name rather than a blanket ".et_pb_button:after" selector so this only touches
   buttons that actually have an explicit icon configured (matching et_pb_button_0's own
   no-op-safe behavior when data-icon is absent: attr() on a missing attribute is just empty). */
#page-container .et_pb_button_0_tb_header:after,
#page-container .et_pb_button_0_tb_body:after,
#page-container .et_pb_button_1_tb_footer:after,
#page-container .et_pb_button_1:after,
#page-container .et_pb_button_0:after {
	content: attr(data-icon) !important;
	font-size: 1.2em !important;
}

/* Any title/heading module that directly precedes a Contact Form module — the "Email Us Today"
   card on the Contact Us page today, and any similar title+form pairing built later — inherits
   Divi's default ".et_pb_column .et_pb_module{margin-bottom:30px}" (the same stock rule behind
   the header-row gap fixed earlier), pushing the form down away from its own title even though
   both halves already have zeroed padding at the seam and are meant to read as one card. Using
   the adjacent-sibling form makes this self-apply to any future title+form pairing without
   needing another edit. */
#page-container .et_pb_module:has(+ .et_pb_contact_form_container) {
	margin-bottom: 0 !important;
}

/* Contact Us page: give the section holding the intro copy, phone number and contact form a
   dark charcoal background matching the header bar (#2B2A29), with generous top/bottom padding
   so it doesn't feel cramped against the sections above/below. Scoped to this page specifically
   (body.page-id-18) since "et_pb_section_1" is just this page's positional numbering, not a
   globally unique class, and other pages have unrelated sections that happen to share it. The
   "Email Us Today" title + form card already has its own light #F4F4F4 background and dark text,
   so it reads fine floating on the new dark section without any changes of its own — only the
   left column's copy (heading, paragraph, "Call us at" label) and the logo needed updating to
   stay legible, which was done directly in the page's own Divi block content rather than here,
   so those colors stay visible/editable as real module settings rather than CSS overrides. */
body.page-id-18 #page-container .et_pb_section_1 {
	background-color: #2B2A29 !important;
	padding-top: 96px !important;
	padding-bottom: 96px !important;
}

/* Remove the 70ch character-width cap on the intro copy under "Our Mobile Locksmith Services in
   Shreveport, LA" specifically (et_pb_text_4). That rule is grouped with et_pb_text_13, a
   different section's copy ("Mobile Locksmith Service Across Shreveport & Bossier") that should
   keep its own 70ch measure — so this targets et_pb_text_4's own class ID rather than touching
   the shared rule, leaving every other copy block's width untouched. */
#page-container .et_pb_text_4 {
	max-width: none !important;
}

/* Ultrareview sections 3-4 (2026-09-21): B14b originally forced the six OLD service tiles into a
   2-up grid at mobile widths (<=767px) instead of Divi's default single-column stack, matching
   the prototype's 2-column mobile layout for that section. It worked by turning #services itself
   into a grid and dissolving its then-children et_pb_row_2/et_pb_row_3 (the two rows the six
   tiles were split across) with display:contents so their columns became direct grid items.
   2026-10-01: REMOVED. The user has since replaced the entire services-tile structure with their
   own implementation, which lives in a separate section entirely (not nested inside #services any
   more) -- #services now wraps only the heading + intro paragraph (its sole child is et_pb_row_1).
   This whole block had become dead weight pointed at row_2/row_3 children that no longer exist
   inside #services, EXCEPT for the `#services { display:grid; grid-template-columns:1fr 1fr }`
   rule itself, which still matched and was still live -- forcing #services's one remaining child
   (the heading+text row) to lay out as a single item in a 2-column grid. A grid item that isn't
   explicitly stretched to span both tracks defaults to occupying just one of them, which is
   exactly the "heading and text only stretch about halfway across" bug reported live (confirmed:
   removing this rule alone restored the heading/paragraph to full width at every size below
   768px, with no other change needed -- an earlier, narrower attempt at fixing this by forcing
   width:100% on the row's own nested column had no effect, because the real constraint was this
   grid-column sizing one level up, not anything about the column's own width). */

/* B18: the "Why Choose Us" row's gutter (et_pb_gutters2) produces a ~34px gap between the copy
   column and the photo/caption column; the prototype's spec calls for a 56px gap.
   Wrapped in min-width:980px (matching the user's own "at the 980px breakpoint" wording, and
   closing a 1px gap against Divi's native stacking cutoff of max-width:980px) after a final mobile
   screenshot check caught this fixed pixel width leaking into the stacked single-column mobile
   layout and forcing horizontal page overflow -- these columns are only still side by side above
   that breakpoint.
   2026-09-23: switched the row to display:flex (see below) because the earlier width-shrinking
   approach never actually produced a side-by-side layout -- this row's own display stayed "block"
   (Divi's classic float columns) at every width, so the two columns kept stacking vertically even
   above the breakpoint. The other similar per-row overrides in this file (et_pb_row_8,
   et_pb_row_10, et_pb_row_11) all switch their row to display:flex for the same reason.
   2026-09-24: now that this is real flexbox, replaced the column_8 width-shrink + column_9
   margin-left workaround (which only produced a 22px gap, not the spec's 56px, per a regression
   caught by the B18 test) with the same flex:gap approach used by et_pb_row_8/10/11 -- column_8
   keeps its original native width (667.953px, before the since-removed 22px shrink) and the gap
   property does the spacing directly.
   2026-09-24 (later same day): that fixed 667.953px was measured at a 1440px viewport, where the
   row's content box is wide. At 980px -- right at this breakpoint's own start, per an explicit
   user report with a screenshot -- the row's actual content box is much narrower, so the fixed
   column_8 width ate nearly all of it and squeezed column_9 (the photo + caption) down to ~139px,
   nowhere near enough to read (confirmed live: column_9's measured width was 138.84px at 980px).
   Replaced both columns' fixed widths with a proportional flex ratio (3:2, i.e. ~60/40) instead,
   so the photo column always gets a reasonable, viewport-proportional share of the row and keeps
   growing as the viewport widens past 980px, rather than being pinned to leftover space after a
   width measured at a single much-wider breakpoint. min-width:0 is needed on both so the image
   inside column_9 doesn't force the flex item wider than its share (the default flex min-width is
   "auto", which lets content's intrinsic size override flex-shrink and can blow out the layout).
   2026-09-24 (later still): per explicit correction, the 56px gap read as too much space between
   the photo and the copy -- reduced to 32px, which is now this site's standard gap for an
   image-with-copy pairing (enough separation to read as two distinct blocks without stealing
   width the image could use). While investigating, found the real reason the photo column was
   still narrower than it should be even after the ratio fix: this row's own ::after pseudo-element
   (Divi's classic float clearfix, "content:''; display:block") becomes a real, invisible THIRD
   flex item once the row is display:flex, and "gap" applies between every pair of flex items --
   so the row was silently reserving a second, invisible 56px gap after the photo column (confirmed
   live: with gap:0 the two columns filled the full 916px content box exactly; with gap:56px, 112px
   went missing -- exactly 2x the gap -- and the photo column's right-edge inset a wrong 88px versus
   the list column's correct 32px left inset). Neutralizing that pseudo-element so it can't act as a
   flex item fixes both the missing width and the mismatched left/right margins in one change. The
   same ::after-as-phantom-flex-item bug is also present on the "We Come To You" and review-card
   rows below (all switched to display:flex earlier this project) -- fixed there too, since it's
   the same defect silently narrowing all of them, not something specific to this row.
   2026-10-01: this row was et_pb_row_4, with columns et_pb_column_8 (list) and et_pb_column_9
   (photo), until the user added a new two-row service-blocks section higher up the page, which
   shifted every row/column's auto-generated number by +1 sitewide (confirmed live: this exact rule
   was found leaking onto the user's NEW second service-blocks row, which had inherited the old
   et_pb_row_4 class number, forcing an unwanted flex/gap layout onto content the user explicitly
   said not to touch). Updated to the current correct row and columns. */
@media (min-width: 980px) {
	#page-container .et_pb_row_5 {
		display: flex !important;
		flex-wrap: nowrap !important;
		gap: 32px !important;
	}
	#page-container .et_pb_row_5::after {
		display: none !important;
	}
	#page-container .et_pb_row_5 > .et_pb_column {
		margin-right: 0 !important;
	}
	#page-container .et_pb_row_5 .et_pb_column_9 {
		width: auto !important;
		flex: 2 1 0% !important;
		min-width: 0 !important;
	}
	#page-container .et_pb_row_5 .et_pb_column_10 {
		width: auto !important;
		flex: 2 1 0% !important;
		min-width: 0 !important;
	}
}

/* 2026-09-24: two more corrections to the same "Why Choose Us" row.
   1) column_8's flex-grow changed from 3 to 2 (was a 3:2 split against column_9's flex-grow:2,
      i.e. 60/40 -- now an even 2:2, i.e. 50/50) per explicit request, so the photo column gets
      more room.
   2) the checklist blurbs inside column_8 were never actually using the column's full width at
      any screen size below ~550px-plus-some-margin: Divi's own default blurb CSS sets
      ".et_pb_blurb_content{max-width:550px}" (meant to keep blurb text readable when a blurb is
      dropped into a full-bleed section), and this column is regularly wider than 550px once
      stacked full-width on tablet/mobile (confirmed live: at a 767px viewport the column was
      703px wide but each blurb's text only used 550px of it, leaving ~150px of dead space on the
      right). Overriding it to max-width:none so the checklist text spans the same width as the
      column around it, matching the H2 and the "Proud to Serve" copy above/below it. Scoped to
      this row's blurbs only, not sitewide, since only this section was reported.
   2026-10-01: updated from et_pb_row_4 to the current correct row number (see the big comment
   above this section for why). */
#page-container .et_pb_row_5 .et_pb_blurb_content {
	max-width: none !important;
}

/* 2026-09-24: same Divi default (".et_pb_blurb_content{max-width:550px}") found in the "Trust Our
   Credentials" row (the 3-up Fair Trade / 1-800-Unlocks / Google Reviews cards) -- confirmed live:
   at 767px and 980px viewports the row stacks each card to a full 703px/916px column, but the
   blurb text inside stayed capped at 550px. Same fix, scoped to this row only.
   2026-10-01: this was et_pb_row_7 until the user added a new two-row service-blocks section
   higher up the page, which shifted every row's auto-generated class number by +1 sitewide --
   updated to the current correct row. */
#page-container .et_pb_row_8 .et_pb_blurb_content {
	max-width: none !important;
}

/* 2026-10-02: per explicit request, center each "Trust Our Credentials" card's H4 title. Scoped to
   just the H4 (not the whole blurb container) so the description paragraph underneath keeps its
   own default left alignment -- only the heading was asked to be centered. The logo images
   (replacing the placeholder "LOGO" SVGs this same request swapped in) are centered separately, at
   the content level via each image's own "display:block;margin:16px auto" inline style, not CSS --
   they're block-level images sharing a <p> with left-aligned description text, so centering them
   with text-align on a shared ancestor would have centered that text too; margin:auto centers the
   image on its own without touching the text next to it. The 16px top margin on each image is the
   "padding between the heading and the logo" asked for. */
#page-container .et_pb_row_8 .et_pb_module_header {
	text-align: center;
}

/* B19 (2026-09-21) originally capped this row at 900px so the "Proud to Serve..." closing block
   read as readable-width copy instead of full-bleed text. Removed 2026-09-24 per explicit
   correction: the user wants this block to span the same full content width as the rest of the
   section above it, not a narrower column. */

/* B11: service-tile title color (#FFFFFF) was set via each blurb's own
   title.decoration.font.desktop.value.color attribute, which is a schema-valid path per
   module.json but does not actually reach the rendered <h4> for Divi 5.7.4 blurb modules
   (confirmed live: computed color stayed rgb(43,42,41), the global heading color, despite
   correct saved attribute JSON) — the same category of attribute-drop bug already hit on the
   header sticky attribute and button icons. Falling back to plain Custom CSS, scoped to the
   services tiles only so it can't affect any other H4 on the page. Each title's text actually
   sits inside a nested <a> (these four tiles link to /automotive-locksmith/), and that anchor's
   own inherited link color was overriding the h4's color — an explicit color always beats
   inheritance regardless of the h4 rule's specificity — so the <a> needs its own matching rule. */
#page-container #services .et_pb_module_header,
#page-container #services .et_pb_module_header a {
	color: #FFFFFF !important;
}

/* B14: same attribute-drop pattern as B11 — each service tile's own css.desktop.value.mainElement
   already declares "box-shadow:inset 0 0 0 1px rgba(255,255,255,.18)" but it does not reach the
   rendered element (confirmed live: computed box-shadow was "none"). Applying the identical
   hairline via Custom CSS on the tile columns directly. */
#page-container #services [class*="et_pb_column_1_3"] {
	box-shadow: inset 0 0 0 1px rgba(255, 255, 255, 0.18) !important;
}

/* 2026-10-01: the "Learn more" links inside each service tile's hover-state blurb (the user's own
   new service-blocks section) are plain inline text links, not styled as buttons. Per explicit
   request, styled to match the sitewide Submit button in the Home page's Contact Us section
   (.et_pb_contact_submit), copying every one of its computed styles EXCEPT font-size, which stays
   at this link's own current size (16px) rather than the Submit button's 20px. Values taken
   directly from the live Submit button: background #E31E24 (rgb(227,30,36)), white text, 600
   weight Poppins, 6px radius (this site's standard button radius), 6px/20px padding, no border or
   box-shadow, 34px line-height. display:inline-block instead of the Submit button's own
   display:block -- the Submit button is the sole element in its own form field box, where block
   makes sense, but these links sit inline inside running paragraph text after a <br>, where
   block would force each onto its own full-width line; inline-block keeps the button look while
   sizing to its own content, matching how it appears today. Scoped to this section's blurb
   descriptions only, not sitewide, since only these links were in scope. */
#page-container .et_pb_section_1 .et_pb_blurb_description a {
	display: inline-block !important;
	background-color: #E31E24 !important;
	color: #FFFFFF !important;
	font-weight: 600 !important;
	font-family: Poppins, sans-serif !important;
	border-radius: 6px !important;
	border: none !important;
	padding: 6px 20px !important;
	line-height: 34px !important;
	text-decoration: none !important;
	box-shadow: none !important;
	cursor: pointer !important;
	transition: all 0.2s !important;
}
/* The Submit button these are modeled on doesn't have a working hover state of its own (confirmed
   live: its background and box-shadow stay identical on :hover, and its own hover-reveal icon
   stays at opacity:0 even while hovered) -- these buttons also won't get the site's usual
   hover-reveal arrow (Divi's button-icon mechanism, used on the main CTA/header buttons), so with
   no icon and no Submit-button hover state to copy, there was no hover feedback at all. Per
   explicit request, added a plain background-darken on hover instead -- #C0191E is #E31E24 at 85%
   brightness (each RGB channel * 0.85), a standard, modest darken amount for this kind of hover
   feedback. */
#page-container .et_pb_section_1 .et_pb_blurb_description a:hover {
	background-color: #C0191E !important;
}

/* 2026-10-02: per explicit request, smoothed the regular-to-hover transition on each service tile.
   Each tile is two stacked Divi blurbs swapped on :hover -- .blurb_active (the photo + plain title,
   the tile's resting state) and .blurb_hover (title + description + Learn More button, over a flat
   dark background). Divi's own generated CSS (confirmed live by reading the actual matched rules,
   not guessing) already fades the INCOMING .blurb_hover in smoothly on hover
   (".blurbs_block .et_pb_column_1_3 .blurb_hover{opacity:0;...}" at rest, "opacity:1" on hover,
   both with a 0.3s transition) -- but the OUTGOING .blurb_active only gets
   ".blurbs_block .et_pb_column_1_3:hover .blurb_active{visibility:hidden}", no opacity change at
   all, and visibility alone snaps instantly rather than fading. The net effect: the photo vanishes
   immediately while the dark info panel fades in underneath it over 0.3s, reading as an abrupt,
   mismatched flash rather than one smooth change. Adding a matching opacity fade to
   .blurb_active on the same hover trigger makes both halves crossfade together at the same speed.
   Visibility's own hidden/visible switch doesn't need to be touched -- per the CSS spec, when
   opacity and visibility transition together and an element is becoming hidden, the UA holds
   visibility:visible for the full transition duration and only switches to hidden at the very end,
   which is exactly the timing a crossfade needs (no mid-fade pointer-event or stacking issues). */
#page-container .blurbs_block .et_pb_column_1_3 .blurb_active {
	transition: opacity 0.3s ease-out, visibility 0.3s ease-out !important;
}
#page-container .blurbs_block .et_pb_column_1_3:hover .blurb_active {
	opacity: 0 !important;
}
/* The incoming .blurb_hover panel turned out to never have been fading in either, even before this
   fix -- confirmed live by walking every matched CSS rule for its opacity: a sitewide Divi rule,
   ".et_pb_module{opacity:1 !important}" (almost certainly meant to force-show modules that would
   otherwise stay hidden mid-entrance-animation), beats Divi's own intended
   ".blurb_hover{opacity:0}" resting state for this element, because that rule has no !important of
   its own -- !important always wins over a plain declaration regardless of specificity. Since
   .blurb_hover is ALSO an .et_pb_module, it was stuck at opacity:1 at all times; it only ever
   *looked* like a fade because visibility:hidden was fully suppressing it regardless of its real
   opacity, so the moment visibility flipped to visible on hover, the (already fully opaque) panel
   appeared instantly rather than easing in. Re-declaring its opacity here with a selector specific
   enough to beat the sitewide !important rule (this one carries an ID, ".et_pb_module" doesn't)
   restores the fade Divi's own CSS was already trying to do. */
#page-container .blurbs_block .et_pb_column_1_3 .blurb_hover {
	opacity: 0 !important;
	transition: opacity 0.3s ease-out, visibility 0.3s ease-out !important;
}
#page-container .blurbs_block .et_pb_column_1_3:hover .blurb_hover {
	opacity: 1 !important;
}

/* Ultrareview sections 5-6 (2026-09-21): B25 — the "We Come To You" row (et_pb_row_9) already
   carries "align-items:center" via its own module-level css.mainElement attribute, but that
   attribute has no effect because the row's actual display is "block" (classic float columns),
   and align-items only applies to flex/grid containers — this isn't a Divi attribute-drop bug,
   just CSS that can't do anything on a non-flex parent. Switching the row itself to flex (via
   Custom CSS, since the content-level layout.display attribute doesn't expose a flex option)
   makes align-items work, and adding gap:56px replaces the row's ~34px native gutter with the
   spec's 56px gap in one property instead of the width-shrinking approach used for B18.
   2026-09-24: same phantom-flex-item bug found and fixed on the "Why Choose Us" row also applies
   here -- Divi's clearfix ::after ("content:''; display:block") becomes an invisible third flex
   item once the row is display:flex, so "gap" was silently being applied twice (once between the
   two real columns, once again between column 2 and the invisible pseudo-element), making both
   columns narrower than the CSS actually intends. Neutralizing the pseudo-element fixes it.
   2026-10-01: this was et_pb_row_8 until the user added a new two-row service-blocks section
   higher up the page, which shifted every row's auto-generated class number by +1 sitewide
   (confirmed live: this exact rule was found leaking onto the NEW "Trust Our Credentials" cards
   row, which had inherited the old et_pb_row_8 class number, while this row itself had lost the
   styling meant for it). Updated to the current correct row. */
@media (min-width: 981px) {
	#page-container .et_pb_row_9 {
		display: flex !important;
		align-items: center !important;
		gap: 56px !important;
	}
	#page-container .et_pb_row_9::after {
		display: none !important;
	}
	#page-container .et_pb_row_9 > .et_pb_column {
		margin-right: 0 !important;
	}
}

/* B26: no heading anywhere on the site had an explicit line-height, so every H1-H4 rendered at
   the browser default (~1.2, computed ratio ~1.0 relative to its own font-size in this test)
   instead of the design token's --lh-heading:1.15. Approved as a sitewide Custom CSS change. */
#page-container h1,
#page-container h2,
#page-container h3,
#page-container h4 {
	line-height: 1.15 !important;
}

/* 2026-10-02: per explicit request, sitewide top:bottom padding ratio of 1.8:1 on body-copy H3
   subheadings, with the bottom padding also increased a bit so they're not sitting too close to
   the paragraph underneath (confirmed live: every body H3 currently has padding-bottom:10px and
   padding-top:0, Divi's own default, with no top space at all above it to separate it from the
   PRECEDING copy). Using em units (relative to the H3's own 24px font-size everywhere this project
   has checked) so the ratio holds correctly if an H3 ever appears at a different size elsewhere.
   0.75em bottom (18px at 24px, versus the old flat 10px) x 1.8 = 1.35em top (32.4px).
   Scoped to exclude .et_pb_toggle_title specifically -- that's also a literal <h3> tag (the FAQ
   accordion's clickable question header), but it isn't body copy sitting inline between paragraphs
   the way every other H3 on the site is; it already has its own padding:0 accordion-header layout,
   and the user's own reasoning for this change ("h3 tags... need to be associated with copy
   surrounding them") describes the body-subheading case specifically, not an interactive toggle. */
#page-container h3:not(.et_pb_toggle_title) {
	padding-top: 1.35em !important;
	padding-bottom: 0.75em !important;
}

/* 2026-10-02: sitewide rule for every FAQ section (any section built from Divi's Accordion module,
   confirmed live on the Automotive Locksmith page and reused identically on the homepage's own
   "Mobile Locksmith Service FAQs" section) -- per explicit request, the section itself gets a
   slightly off-white background, and each FAQ entry gets a plain white background so it reads as
   offset from that section background in both its expanded and collapsed states.
   #F4F4F4 isn't a new color -- it's this site's existing established off-white, already used for
   the alternating light-gray sections elsewhere on the homepage ("Why Choose Us", "Our Customer
   Reviews on Google"), reused here for consistency rather than introducing a second near-white
   tone.
   The white-entry half of this is doing real work, not just restating the section's own white
   default: Divi's own accordion CSS already sets a COLLAPSED entry's background to this exact same
   #F4F4F4 (confirmed live before this change -- only the expanded entry was white, the collapsed
   one already matched the gray this change adds to the section), so without forcing both states to
   white explicitly, every collapsed FAQ entry would have become invisible against the new section
   background the moment it was added.
   Scoped with :has() to "any section containing an accordion" rather than a specific section
   number, so this rule is automatically correct on every current and future FAQ section sitewide
   regardless of each page's own auto-generated section numbering (which this project has already
   hit real collisions from more than once -- see the row/column-renumbering fixes elsewhere in
   this file). */
#page-container .et_pb_section:has(.et_pb_accordion) {
	background-color: #F4F4F4 !important;
}
#page-container .et_pb_accordion_item {
	background-color: #FFFFFF !important;
}

/* 2026-10-01: fluid font-size for H1 and H2, sitewide. Per explicit spec: the upper limit (at a
   1200px+ viewport) is each tag's own current size (confirmed live, consistent across every page
   sampled: H1 52px, H2 36px) -- scaling down, gradually and continuously as the viewport narrows,
   to a lower limit at 400px. The lower-limit reduction is 0.27 of each tag's OWN current size
   (not a flat px amount), so H1 and H2 each shrink by the same proportion (27%) rather than the
   same number of pixels: H1 52px -> 37.96px, H2 36px -> 26.28px.
   Implemented with clamp() + a calc(px + vw) ramp, the standard pure-CSS fluid-typography
   technique -- clamp()'s own min/max arguments hold flat below 400px and above 1200px with no
   extra media queries needed, and the middle calc() argument is a linear function of viewport
   width solved so it equals the min at exactly 400px and the max at exactly 1200px:
     coefficient (vw) = (max - min) / 8        [ because (1200-400)px = 800px = 8 * 100vw ]
     intercept (px)   = min - 400 * coefficient / 100
   No existing font-size rule for h1/h2 was found in this stylesheet before this (confirmed via
   search), so the only thing being overridden is Divi's own content-level size. */
#page-container h1 {
	font-size: clamp(37.96px, calc(30.94px + 1.755vw), 52px) !important;
}
#page-container h2 {
	font-size: clamp(26.28px, calc(21.42px + 1.215vw), 36px) !important;
}

/* Ultrareview sections 7-8 (2026-09-21): B28 -- the 4-up review card row (et_pb_row_10) uses
   Divi's smallest gutter preset (et_pb_gutters1), which produces close to 0px real spacing
   between the four columns; the spec calls for 20px. Same flex+gap approach as B25/B18, with the
   native gutter's margin-right zeroed so it doesn't stack with the new gap.
   2026-09-24: per explicit report, below 981px this row still had zero visible gap between cards
   when two sit side by side (Divi's own flex-wrap grid system already renders this row as
   display:flex;flex-wrap:wrap at every width, natively, with no gap of its own -- my gap:20px
   rule was scoped to min-width:981px only, matching where the row first fits all four cards on
   one line, so the earlier two-per-line wrapped state at narrower widths never got any gap at
   all). Removed the media-query restriction so the same 20px gap applies unconditionally, at
   every width, whether one, two or four cards end up sharing a row.
   flex-wrap is deliberately left unset here (not forced to either wrap or nowrap) so each width
   range keeps whatever Divi's own native flex-wrap value already is there -- forcing wrap:wrap
   everywhere was tried first and broke the true desktop 4-up case (confirmed live at 1440px: it
   wrapped to 3+1 instead of shrinking all 4 columns to fit one line, because Divi's own desktop
   columns have a comfortable content width wider than an even 4-way split and only fit via
   flex-shrink under nowrap, which is what happens above 980px without any wrap override from me).
   The one range that genuinely needs wrap forced on is 480px-980px, alongside the width fix below.
   2026-10-01: this was et_pb_row_10 until the user added a new two-row service-blocks section
   higher up the page, which shifted every row's auto-generated class number by +1 sitewide --
   updated to the current correct row (re-verified live by locating the row via its own card
   content rather than trusting the old class number). */
#page-container .et_pb_row_11 {
	display: flex !important;
	gap: 20px !important;
}
#page-container .et_pb_row_11::after {
	display: none !important;
}
#page-container .et_pb_row_11 > .et_pb_column {
	margin-right: 0 !important;
}
/* Adding the unconditional gap above also broke the row's native two-per-line tablet layout: Divi
   gives each column a plain, fixed "width:50%" in that range (confirmed live: column widths were
   exact, unrounded halves of the row's content box at every width from 480px to 980px -- e.g.
   351.5px of 703px at 767px), with no allowance for a gap between them, so adding gap:20px pushed
   the pair over 100% of the line and wrapped each card onto its own row instead of pairing two per
   row (confirmed: every width from 375px to 980px wrapped to one column after the gap was added,
   not just below the intended single-column phone breakpoint). 480px is where Divi's own layout
   switches from one column to two (confirmed by a search between 375px, single, and 480px, first
   two-up width) -- subtracting half the 20px gap from each column's width in that range restores
   two cards fitting on one line with the gap between them, matching the desktop math already used
   for the 4-up row above 980px. flex-wrap:wrap is forced here specifically (and only here) since
   this range needs the pair to wrap onto lines of two, unlike nowrap-and-shrink desktop above
   980px or Divi's own native single-column wrap below 480px. */
@media (min-width: 480px) and (max-width: 980px) {
	#page-container .et_pb_row_11 {
		flex-wrap: wrap !important;
	}
	#page-container .et_pb_row_11 > .et_pb_column {
		width: calc(50% - 10px) !important;
	}
}

/* Contact banner (et_pb_row_12): same align-items:center-on-a-block-display gap as B25 — the
   row's own css.mainElement sets align-items:center, which has no effect without a flex display.
   2026-10-01: this was et_pb_row_11 until the user added a new two-row service-blocks section
   higher up the page, which shifted every row's auto-generated class number by +1 sitewide
   (confirmed live by re-mapping every targeted section by its own heading text rather than
   trusting the old class numbers). Updated to the current correct row. */
@media (min-width: 981px) {
	#page-container .et_pb_row_12 {
		display: flex !important;
		align-items: center !important;
		gap: 56px !important;
	}
	#page-container .et_pb_row_12::after {
		display: none !important;
	}
	#page-container .et_pb_row_12 > .et_pb_column {
		margin-right: 0 !important;
	}
}

/* B34: the contact form's own module.field decoration exposes no border control in Divi's VB
   schema for this attribute, so the input border is added directly via Custom CSS. Required-field
   asterisks are likewise not rendered by Divi's own contact-form output (data-required_mark is
   set but nothing reads it into visible CSS content), so this adds one after every field label. */
#page-container .et_pb_contact_form_container .input {
	border: 1px solid #D9D9D9 !important;
}
/* Divi's own theme CSS sets .et_pb_contact_form_label{display:none} by default (it relies on
   placeholder text standing in for the label instead) -- overriding to make labels visible, since
   the spec calls for visible labels specifically. */
#page-container .et_pb_contact_form_label {
	display: block !important;
	margin-bottom: 4px;
	font-size: 13px;
	font-weight: 600;
	color: #2B2A29;
}
#page-container .et_pb_contact_form_label::after {
	content: ' *';
	color: #E31E24;
}

/* B35: First/Last Name are both configured fullwidth:off in the module content, which should
   produce Divi's own half-width flex-column class, but both fields render with the full-width
   et_flex_column_24_24 class regardless (confirmed live) — the same category of Divi 5.7.4
   attribute-drop bug hit elsewhere this session. Forcing the first two fields to sit side by side
   via Custom CSS instead of fighting the native attribute. */
@media (min-width: 981px) {
	#page-container .et_pb_contact_field_0,
	#page-container .et_pb_contact_field_1 {
		flex: 1 1 calc(50% - 10px) !important;
		max-width: calc(50% - 10px) !important;
	}
}

/* B37: the submit button's wrapper has no exposed alignment control in this module context;
   Divi's default renders it right-aligned. */
#page-container .et_pb_contact_form_container .et_pb_button_wrapper,
#page-container .et_pb_contact_form_container .et_contact_bottom_container {
	text-align: left !important;
}

/* Ultrareview sections 9-10 (2026-09-21): B39 -- Divi's own static CSS gives every accordion item
   a full 1px box border on all four sides (".et_pb_toggle{border:1px solid #d9d9d9}"), producing
   a bordered-box look; the spec wants a flat list with a bottom divider only between items. */
#page-container .et_pb_toggle {
	border: 0 !important;
	border-bottom: 1px solid #D9D9D9 !important;
}

/* B51: footer's 3-column row (et_pb_row_0_tb_footer) has the same ~34px native-gutter-vs-56px-spec
   gap pattern as every other multi-column row this session; spec here calls for 48px. */
@media (min-width: 981px) {
	#page-container .et_pb_row_0_tb_footer {
		display: flex !important;
		gap: 48px !important;
	}
	#page-container .et_pb_row_0_tb_footer > .et_pb_column {
		margin-right: 0 !important;
	}
}
/* All five flex-conversion fixes above (rows 4, 8, 10, 11, 0_tb_footer, plus the contact-field
   50% width) are wrapped in this same min-width:981px breakpoint after the final mobile
   screenshot pass found each one forcing its columns to stay side by side at mobile widths
   instead of letting Divi's own responsive stacking take over, producing horizontal page
   overflow (confirmed via document.documentElement.scrollWidth > viewport width at 390px). */

/* Defensive safety net: the services section's mobile grid (its intro row specifically) still
   measures ~17px wider than the viewport at 390px after the fixes above, for a cause not fully
   isolated (its grid-template-columns computes against an unexplained ~375px content width
   instead of the expected ~326px after the section's own 32px+32px padding) -- small enough not
   to visibly clip any content in a screenshot check, but real enough to trigger page-level
   horizontal scroll on a phone. Clipping it at the body level is the safe fallback while the root
   cause is investigated further, rather than leaving the whole page horizontally scrollable. */
html, body {
	overflow-x: hidden;
	width: 100%;
}

/* B27 (2026-09-21): on the "We Come To You" row (et_pb_row_9), the photo/caption column is the
   SECOND column in source order (text column is first) -- at mobile widths, where the columns
   stack top-to-bottom in that same source order, that put the text above the photo instead of the
   spec's photo-above-text, so flex-direction:column-reverse flipped the stacked visual order.
   2026-09-22: the "Why Choose Us" row originally had this same treatment for prototype parity,
   but was removed per direct user feedback -- that section's photo+caption should stack BELOW the
   heading/checklist at mobile, which is simply its normal (non-reversed) source order.
   2026-09-24: superseded by an explicit correction -- below the 980px breakpoint this photo
   column is now hidden outright rather than reordered. The image only supplements the copy at
   desktop widths, where the text column doesn't use the row's full width on its own; once the row
   stacks to one full-width column on tablet/mobile, the text already fills the space and the
   (still-placeholder) photo adds nothing, so column-reverse is moot and removed along with it.
   2026-10-01: row and column numbers updated (was et_pb_row_8 .et_pb_column_16) after the user's
   new service-blocks section shifted every row/column's auto-generated number by +1 sitewide. */
@media (max-width: 980px) {
	#page-container .et_pb_row_9 .et_pb_column_17 {
		display: none !important;
	}
}

/* 2026-10-15: per explicit, standing instruction never to use <span> tags in copy anywhere on
   the site, the "Why Choose Us" blurbs' .copy-desktop/.copy-phone span pair (B17, below) was
   removed from the Home page content entirely, collapsing each blurb back to one plain-text
   string (the longer "desktop" copy) with no responsive swap. These rules controlled which span
   showed at which breakpoint and have nothing left to target now that both classes are gone from
   the page, so they're removed too rather than left as dead CSS. */

/* 2026-09-22: hero photo background (shreveport-skyline-hero.jpg) replaces the placeholder striped
   pattern. The H1/subhead/button column (et_pb_column_0, unique -- Divi's column numbering starts
   at 0 for the first column on the page, which is this hero) gets a frosted-glass card treatment
   so the text stays legible over the photo while the photo itself stays fully visible everywhere
   outside the card: semi-transparent brand-charcoal background, backdrop-filter blur, generous
   padding. background:center/cover on the section keeps the photo centered and covering the full
   section at every viewport width, per request.
   2026-10-01: scoped to body.page-id-15 (the homepage only). Divi's column numbering restarts at
   0 on every page, not just this one, so the bare ".et_pb_column_0" selector was also matching the
   first column of every OTHER page's own title-bar section -- confirmed live: the About Us page's
   plain "About Us" title bar had picked up this exact same dark/blurred glass-card treatment,
   unintentionally, which is what made that title bar read as having a "blurred black background"
   in the first place (that page's title text itself has no background of its own; this hero rule
   was the actual source). page-id-15 is this site's homepage post ID (see keymergency-shared-
   template-post-ids convention used elsewhere in this project). */
body.page-id-15 #page-container .et_pb_column_0 {
	background: rgba(43, 42, 41, 0.6);
	backdrop-filter: blur(3px);
	-webkit-backdrop-filter: blur(3px);
	border-radius: 16px;
	padding: 64px 48px !important;
}
@media (max-width: 767px) {
	body.page-id-15 #page-container .et_pb_column_0 {
		padding: 40px 24px !important;
		border-radius: 12px;
	}
}

/* 2026-10-01: per explicit request, for the plain page-title header used on every non-home page
   (About Us, the service pages, etc.) -- removing the glass-card background above (which was
   leaking in from the homepage hero rule, not something these pages set themselves) already drops
   the card's own 64px/48px padding and 16px border-radius. Explicitly zeroing the column's padding
   here too, since that's what was making the section tall -- the section itself (the dark
   diagonal-stripe background) keeps its own 48px top/bottom padding, which is now the only
   vertical space in this header. The "Photo placeholder" caption (et_pb_text_1, the second text
   module in this header row, right-aligned) is hidden entirely: it was reserving its own line of
   vertical space for a photo slot that has no visual counterpart now that there's no card framing
   it, and a background photo is coming to the section itself later per the user, making a separate
   placeholder caption redundant. Scoped to exclude the homepage via :not(body.page-id-15), the
   same way the card rule above is scoped IN to it, so this can never affect the hero. A text-shadow
   is added to every H1 in this header (not scoped to .et_pb_text_0 specifically, since every page
   using this plain title-bar pattern has its H1 as the first text module) so the heading stays
   legible once a real photo replaces today's flat/striped section background, per explicit
   request -- kept deliberately light (a soft 2px blur, 45% black) since the current background is
   still a flat dark color the text already reads fine against; this is specifically for the future
   photo. */
body:not(.page-id-15) #page-container .et_pb_section_0 .et_pb_column_0 {
	padding: 0 !important;
}
body:not(.page-id-15) #page-container .et_pb_section_0 .et_pb_text_1 {
	display: none !important;
}
body:not(.page-id-15) #page-container .et_pb_section_0 h1 {
	text-shadow: 0 1px 4px rgba(0, 0, 0, 0.45) !important;
}

/* 2026-10-01 (later same day): shrunk further, to a 200px section, with the H1 vertically
   centered in that space per explicit request. et_pb_section is already display:flex natively
   (confirmed live), so centering is just align-items:center -- but the section's own 48px
   top/bottom padding plus the row's own ~22.7px top/bottom gutter padding (et_pb_gutters3's
   default vertical gutter) together reserved ~141px before any content, which would have made a
   200px section overflow its own box instead of cleanly fitting the (~70px-tall) H1 centered
   inside it. Zeroing both paddings and relying entirely on align-items:center for vertical spacing
   keeps the H1 comfortably centered with room to spare, confirmed live (see verification notes).
   One more offset turned up once this was live: the H1's own text module (et_pb_text_0) still
   carried Divi's default ~31px bottom margin (ordinarily the gap before the next module -- here,
   the now-hidden placeholder caption), which isn't visible but still counts toward the row's
   height that align-items:center balances around, so the H1 rendered 31px above true center
   instead of centered (confirmed live: 49.5px above the section vs 80.7px below). Zeroing it
   makes the row's real height match the H1's own visible height, so centering lands evenly. */
body:not(.page-id-15) #page-container .et_pb_section_0 {
	min-height: 200px !important;
	height: 200px !important;
	padding-top: 0 !important;
	padding-bottom: 0 !important;
	align-items: center !important;
}
body:not(.page-id-15) #page-container .et_pb_section_0 .et_pb_row_0 {
	padding-top: 0 !important;
	padding-bottom: 0 !important;
}
body:not(.page-id-15) #page-container .et_pb_section_0 .et_pb_text_0 {
	margin-bottom: 0 !important;
}

/* 2026-10-06: per explicit report, the H1 in this same title-bar text module didn't align on the
   left with the body content below it. This module's own border-left:4px + padding-left:20px (the
   red accent bar, set at the content level, applied to the MODULE itself, not the H1 tag) together
   push the actual H1 text 24px to the right of the module's own box edge -- confirmed live: the
   module's box starts at the same x=32 as the body content's H2 text below it, but the H1 text
   inside it starts at x=56, 24px further right than the body copy's x=32.
   2026-10-06 (later, explicit correction): a first attempt pulled the whole module left by 24px so
   the H1 TEXT would land flush with the body copy, leaving the red bar sitting in the gutter just
   left of the content column. Per explicit correction, that's not what was wanted -- the bar
   itself should be the piece that aligns flush with the body content's left edge, not the text, so
   this is reverted to margin-left:0 (the module's natural, unshifted position). With no margin
   override, the module box -- and so the red bar -- sits at x=32, matching the body content
   directly; the H1 text then sits to the right of the bar at x=56, per the module's own existing
   border+padding. */
body:not(.page-id-15) #page-container .et_pb_section_0 .et_pb_text_0 {
	margin-left: 0px !important;
}

/* 2026-10-06 (same day, follow-up): the -24px fix above only held at exactly 1200px viewport width
   -- per a follow-up report, it was confirmed live that at wider desktop widths (1440px, 1920px)
   the H1 drifts a consistent 32px too far LEFT of the body content instead of matching it. Root
   cause: this title-bar section applies its 32px left/right padding at the SECTION level, before
   its 1200px-max row gets centered inside it, while every body section applies that same 32px at
   the ROW level, after centering. Those two approaches only produce the same absolute left edge by
   coincidence at exactly viewport-width 1200px (where the row's own centering margin is 0 either
   way) -- at any wider width the two methods diverge by a fixed 32px, confirmed live at both
   1440px and 1920px. Moving the 32px from the section to the row here, matching the body sections'
   own structure exactly, makes the two align at every width instead of just one. The -24px margin
   above still does its job unchanged on top of this -- it isn't viewport-dependent, since it's a
   fixed offset between the module's own box and the row/column edge it sits in, not a function of
   where that edge lands on screen. */
body:not(.page-id-15) #page-container .et_pb_section_0 {
	padding-left: 0 !important;
	padding-right: 0 !important;
}
body:not(.page-id-15) #page-container .et_pb_section_0 .et_pb_row_0 {
	padding-left: 32px !important;
	padding-right: 32px !important;
}

/* 2026-09-22: the map iframe module (in the shared Body template, so this reaches every page)
   carries ~40px of Divi's own default column>module bottom margin, leaving a visible gap above
   the caption card underneath it. The selector originally reported for this
   (".et_pb_gutters3 .et_pb_column_4_4.et_block_column .et_pb_module") is Divi's own generic
   column/gutter/module class combination, not unique to the map -- it actually matches 82
   modules across every section of the page (confirmed live), so applying it as given would have
   zeroed legitimate spacing sitewide instead of just this one gap. Targeting the map module's own
   specific class (et_pb_text_0_tb_body) achieves the same visual fix without that collateral
   damage. */
#page-container .et_pb_text_0_tb_body {
	margin-bottom: 0 !important;
}

/* 2026-09-22: removed the h4 padding-bottom on the utility bar's three items (Shreveport, LA /
   Service Hours / Response) specifically -- Divi's default 10px padding-bottom there adds
   unneeded vertical height to the header, which matters most at narrower screen sizes. Scoped to
   the utility bar's own section (et_pb_section_0_tb_header, distinct from the main nav section
   et_pb_section_1_tb_header) so it doesn't touch H4 spacing anywhere else on the site. */
#page-container .et_pb_section_0_tb_header .et_pb_module_header {
	padding-bottom: 0 !important;
}

/* 2026-10-07: add 1em of left padding to unordered lists in body content site-wide, on top of
   Divi's own base ".et-l--body ul{padding-left:1em}" rule (confirmed live via computed-style +
   stylesheet walk on the Automotive Locksmith page), giving 2em total. Scoped to ".et_pb_text ul"
   since every body-content list on this site is built directly inside a Text module's own HTML --
   confirmed by surveying every <ul> on a live page that every other one (nav menu, submenus,
   mobile menu, header/footer social icons) sits outside .et_pb_text, so this reaches only the
   bulleted lists inside page prose (service pages, location pages) without touching navigation. */
#page-container .et_pb_text ul {
	padding-left: 2em !important;
}

/* 2026-10-07: the sitewide "local towns and cities" list (shared Body template, reaches every
   page) was breaking multi-word town names across two lines -- e.g. "Elm" / "Grove" on separate
   lines -- because a plain space between the two words is a normal line-break opportunity. Fixed
   that by joining each multi-word name with a non-breaking space (U+00A0) in the underlying
   content. That alone wasn't enough at narrower widths, though: Divi's own base rule
   ".et_pb_text{overflow-wrap:break-word;word-wrap:break-word}" (confirmed live via a
   stylesheet walk on this exact module) still splits the now-unbreakable "South Bossier" unit
   mid-word (e.g. "South Bossie" / "r") whenever the whole phrase doesn't fit the remaining line
   width, since break-word allows breaking inside a run of non-breaking-space-joined text as a
   last resort. Overriding overflow-wrap/word-wrap back to "normal" -- scoped to this one module's
   own class (et_pb_text_4_tb_body, stable across every page since it's part of the shared Body
   template) rather than touching the sitewide .et_pb_text rule -- makes the whole multi-word
   phrase wrap down to the next line as a single unit instead of breaking inside it. */
#page-container .et_pb_text_4_tb_body {
	overflow-wrap: normal !important;
	word-wrap: normal !important;
}

/* ============================================================================
   2026-10-14: mobile usability pass. Audited every section's computed padding
   and every heading/body font size at 390/768/980px against a reference
   locksmith site (fxbgkeys.com, also Divi-built) and against this site's own
   1200px desktop values. Headings and body text already shrink sensibly at
   narrow widths via Divi's own built-in responsive typography (confirmed live:
   H1 52px->38px, H2 36px->26px, body 16px->16px between 1200px and 390px with
   no extra CSS of ours involved) -- the title-bar section is likewise already a
   fixed, deliberately-shrunk 200px tall at every width (see the 2026-10-01 block
   above). None of that needed touching. What never shrinks is plain section
   padding, since Divi only auto-scales a module's OWN typography/sizing
   controls, not the "spacing" padding value we set once as a single `desktop`
   figure when these pages were built -- every body/FAQ section content section
   sitewide (and several Home-page and shared-template sections) carries the
   exact same 96px/72px/50px top-and-bottom padding at 390px as it does at
   1920px, confirmed live across several service, location, Home, and Contact Us
   pages. Halved at and below Divi's own 980px tablet breakpoint below, which is
   the single biggest contributor to excess mobile scroll length on this site. */

/* Body/FAQ content sections on every service and location page (the vast
   majority of pages on the site, all built from the same template) -- Home is
   excluded here since its own section indices (et_pb_section_0 etc.) are reused
   for completely different content and get their own rule below. */
@media (max-width: 980px) {
	body:not(.page-id-15) #page-container .et_pb_section_1,
	body:not(.page-id-15) #page-container .et_pb_section_2 {
		padding-top: 48px !important;
		padding-bottom: 48px !important;
	}
}

/* Home page's own content sections (hero through FAQ), confirmed live one by
   one: section_0 hero, _2 Why Choose Us, _3 Trust Our Credentials, _4 Service
   Areas, _5 Reviews, _6 Contact CTA, _7 FAQ all carried 96px; _1 (Services grid)
   carried a smaller 50px, halved proportionally rather than down to the same
   48px floor as the others. */
@media (max-width: 980px) {
	body.page-id-15 #page-container .et_pb_section_0,
	body.page-id-15 #page-container .et_pb_section_2,
	body.page-id-15 #page-container .et_pb_section_3,
	body.page-id-15 #page-container .et_pb_section_4,
	body.page-id-15 #page-container .et_pb_section_5,
	body.page-id-15 #page-container .et_pb_section_6,
	body.page-id-15 #page-container .et_pb_section_7 {
		padding-top: 48px !important;
		padding-bottom: 48px !important;
	}
	body.page-id-15 #page-container .et_pb_section_1 {
		padding-top: 32px !important;
		padding-bottom: 32px !important;
	}
}

/* Shared Body-template sections -- the "You can count on Keymergency..." CTA
   and the footer's own top/bottom padding -- reach every single page on the
   site from one place, so one rule here fixes both everywhere at once. */
@media (max-width: 980px) {
	#page-container .et_pb_section_2_tb_body {
		padding-top: 48px !important;
		padding-bottom: 48px !important;
	}
	#page-container .et_pb_section_0_tb_footer {
		padding-top: 48px !important;
		padding-bottom: 48px !important;
	}
}

/* The two large "Contact us" phone-number calls to action (44px on Home, 52px
   on Contact Us, confirmed live) are plain <a href="tel:..."> links with their
   own one-off inline font-size rather than Divi's typography controls, so
   there's no native per-breakpoint override to reach for -- an external
   stylesheet rule with !important still wins over a non-!important inline
   style, which is what lets this work at all. Matched by the exact inline
   font-size value rather than a shared class, since every OTHER tel: link on
   the site has no inline style at all and already sizes sensibly on its own. */
@media (max-width: 980px) {
	#page-container a[href^="tel:"][style*="font-size:44px"],
	#page-container a[href^="tel:"][style*="font-size:52px"] {
		font-size: 28px !important;
	}
}

/* Below Divi's 980px tablet breakpoint, swap the phone button and the hamburger
   menu so the phone button renders first -- per explicit request. This row's
   two columns already stack as plain block boxes (not side-by-side) at this
   width, confirmed live, so switching to a flex column lets `order` reorder
   them cleanly without changing anything about how they look. Lives in the
   shared header template, so it reaches every page from one rule. */
@media (max-width: 980px) {
	#page-container .et_pb_row_inner_0_tb_header {
		display: flex !important;
		flex-direction: column !important;
	}
	#page-container .et_pb_row_inner_0_tb_header .et_pb_column_inner_0_tb_header {
		order: 2 !important;
	}
	#page-container .et_pb_row_inner_0_tb_header .et_pb_column_inner_1_tb_header {
		order: 1 !important;
	}
}

/* Mobile-menu "Services" submenu starts collapsed below 980px, per explicit
   request, so opening the hamburger doesn't immediately dump all seven service
   links on screen before the main nav items are even visible. The toggle arrow
   itself is injected by a small inline script (functions.php, wp_footer) since
   Divi's own mobile menu has no built-in per-item collapse -- this half is just
   the display:none/block driven by the .mobile-submenu-open class that script
   adds to the parent <li> on tap. Scoped generically to any
   menu-item-has-children item rather than "Services" by name specifically, so
   it keeps working automatically if a second dropdown item is ever added the
   same way. */
@media (max-width: 980px) {
	#page-container .et_mobile_menu li.menu-item-has-children {
		position: relative;
	}
	#page-container .et_mobile_menu li.menu-item-has-children > ul.sub-menu {
		display: none !important;
	}
	#page-container .et_mobile_menu li.menu-item-has-children.mobile-submenu-open > ul.sub-menu {
		display: block !important;
	}
	#page-container .et_mobile_menu li.menu-item-has-children > .mobile-submenu-toggle {
		/* Fixed 47px height (confirmed live to match the top-level link row's own
		   rendered height) rather than 100% of the <li> -- with height:100%, the arrow
		   re-centered in the middle of the whole expanded block (including the
		   now-visible sub-menu) instead of staying put next to the always-visible
		   "Services"/"Service Areas" text, per explicit report. A JS-measured height
		   was tried first and discarded: the mobile menu is display:none until the
		   hamburger is tapped, and getBoundingClientRect()/offsetHeight both return 0
		   for anything inside a display:none ancestor, so that measurement always came
		   back as 0 regardless of the link's real rendered size. */
		position: absolute;
		top: 0;
		right: 0;
		width: 44px;
		height: 47px;
		display: flex;
		align-items: center;
		justify-content: center;
		cursor: pointer;
		font-size: 18px;
		line-height: 1;
		color: inherit;
	}
	#page-container .et_mobile_menu li.menu-item-has-children.mobile-submenu-open > .mobile-submenu-toggle {
		transform: scaleY(-1);
	}
}

/* 2026-10-15: per explicit request, each Credentials-section card's logo image moves above
   its own heading instead of appearing after it. These 3 cards (Fair Trade Locksmith Directory,
   1-800-Unlocks Verified, Google Reviews) are Blurb modules with Divi's native icon feature
   turned off (useIcon:"off") -- the logo is a plain <img> hand-embedded in the module's own
   "content" field instead, which Divi's Blurb template always renders AFTER the title (the
   module's fixed skeleton is title-then-content, not reorderable by content alone, confirmed by
   reading the stored block attrs). The content field was split in two (a leading paragraph
   holding just the <img>, a second paragraph holding the description text) specifically so the
   image could become independently orderable here. ".et_pb_blurb_description{display:contents}"
   makes that wrapper disappear for layout purposes, exposing its two <p> children as flex items
   alongside the heading itself, which is what lets `order` place the image first, the heading
   second, and the description text last -- a plain flex-reorder on the description div alone
   would have moved the whole thing (image AND text) above the heading, not just the image. */
body.page-id-15 #page-container .et_pb_section_3 .et_pb_blurb_container {
	display: flex;
	flex-direction: column;
}
body.page-id-15 #page-container .et_pb_section_3 .et_pb_blurb_description {
	display: contents;
}
body.page-id-15 #page-container .et_pb_section_3 .et_pb_blurb_description > p:first-child {
	order: -1;
}
body.page-id-15 #page-container .et_pb_section_3 .et_pb_module_header {
	order: 0;
}
body.page-id-15 #page-container .et_pb_section_3 .et_pb_blurb_description > p:last-child {
	order: 1;
}

/* Blog page "read more" links styled to match the Home page's "Learn About Our Services"
   button (same background, padding, border-radius, font-weight -- those values are copied
   from the sitewide Divi global button default, not unique to that one button) and
   right-bottom-justified within each post card. The link is nested inside .post-content,
   itself inside article.et_pb_post, with no wrapper of its own, so both ancestors are made
   flex columns (article stretches to the CSS grid row height already; .post-content is given
   flex:1 to fill the remaining space) and the link gets margin-top:auto + align-self:flex-end
   to push itself to the bottom-right regardless of how long each post's excerpt is. */
.et_pb_blog_0 article.et_pb_post {
	display: flex;
	flex-direction: column;
}
.et_pb_blog_0 .post-content {
	display: flex;
	flex-direction: column;
	flex: 1 1 auto;
}
/* margin-top:auto on the link below only creates space when a card has leftover row height to
   push into -- on the tallest card in a row (the one with the longest excerpt) there's no
   leftover space, so the gap above the button would collapse to ~0 there. This margin-bottom on
   the excerpt text guarantees a minimum gap unconditionally, regardless of how much (or how
   little) auto-margin space ends up being available. */
.et_pb_blog_0 .post-content-inner {
	margin-bottom: 20px;
}
.et_pb_blog_0 article.et_pb_post .post-content a.more-link {
	align-self: flex-end;
	margin-top: auto;
	background-color: #E31E24;
	color: #FFFFFF !important;
	padding: 6px 20px;
	border-radius: 6px;
	font-weight: 600;
	font-size: 20px;
	text-transform: uppercase;
	display: inline-block;
	transition: background-color 0.2s ease;
}
/* #C0191E is #E31E24 at 85% brightness (each RGB channel * 0.85) -- the same modest hover-darken
   amount already established for the service-tile "Learn more" buttons elsewhere on the site. */
.et_pb_blog_0 article.et_pb_post .post-content a.more-link:hover {
	background-color: #C0191E;
}