/*
 * Pro Integrate — bug-sheet fixes (Prointegrate Bugsheet - Staging).
 * Loaded after the main stylesheet so these rules win on equal specificity.
 * Each block is tagged with the bug number it addresses.
 */

/* Bug_36: invalid-email message in the sticky Enquiry form must be red, not green. */
#enq_form label.error,
#enq_form .c-status .red {
	color: #d32f2f !important;
}

/* Bug_4: home banner's scroll-position dots were right-aligned (text-align:right; right:110px),
   sitting right next to the Tawk chat bubble in the bottom-right corner. Center them instead. */
.home-sec .owl-dots {
	text-align: center !important;
	right: 0 !important;
	left: 0 !important;
}

/* Bug_5: "Know more" button on the home banner (class hvr-float) only had a subtle float-up
   animation on hover, no color/background change. CORRECTED 2026-09-30: the original
   selector (".home-sec .slidercnt a.hvr-float:hover") is right, but ".hvr-float" itself is
   "display:inline-block", and the button's own markup has no fixed width, so the anchor's
   hover box was stretching to the width of the whole line of text above it rather than
   hugging just the button label. Give the button an explicit inline-block sizing context
   so the hover background only ever covers the button itself. */
.home-sec .slidercnt a.hvr-float {
	display: inline-block;
	width: auto;
	padding: 10px 28px;
}
.home-sec .slidercnt a.hvr-float:hover {
	background-color: #1BBCF3;
	border-color: #1BBCF3;
	color: #fff;
}

/* Bug_42: close (X) control added to the sticky Enquiry form. NOTE 2026-09-30: this used
   to also set `.enq_form { position: relative; }`, but the theme's own style.css already
   makes `.enq_form` `position: fixed` - and a fixed-position ancestor is *already* a valid
   containing block for an absolutely-positioned descendant (the close button below), just
   like `relative` would be. Overriding it to `relative` was unnecessary AND harmful: it
   pulled the whole sticky Enquiry form out of `position:fixed` (removing it from the
   fixed/off-canvas layer) and back into the normal document flow as a real, visible child
   of `<footer class="site-footer">` - which is a flex container - so the form's own
   ~400px height was being added directly to the footer's rendered height on every page.
   That, not the footer's padding, was the actual cause of the repeated "footer height too
   big" reports: no padding value could ever fix it while the 400px-tall form was sitting
   in-flow inside the footer. Removed the position override below; the close button still
   positions correctly since `fixed` provides the same containing-block behavior `relative`
   would have. See the corrected Bug_55 note further down. */
.enq_form .enq_form_close {
	position: absolute;
	top: 8px;
	right: 20px;
	background: transparent;
	border: none;
	color: #fff;
	font-size: 28px;
	line-height: 1;
	cursor: pointer;
	z-index: 2;
}
.enq_form .enq_form_close:hover {
	color: #1BBCF3;
}

/* Bug_37: the Message textarea in the sticky Enquiry form was narrower than the other
   fields and didn't line up on the right edge. CORRECTED 2026-09-30: the theme's own
   `.enq_form input{margin:10px}` gives every input a 10px margin on ALL sides, but
   `.enq_form textarea{margin-left:10px}` only ever sets the left margin - it has no
   margin-right at all - so the textarea's right edge always sat 10px further right than
   the inputs above it. Give it the same right margin instead of guessing a width.
   CORRECTED AGAIN 2026-10-01 evening (Bug_2, Prointegrate Bugsheet - Staging): the
   theme's own style.css re-applies `.enq_form textarea{margin-left:0}` inside three
   separate narrower-breakpoint media queries, which don't touch margin-right - so at
   those widths the textarea ended up with 0 margin-left / 10px margin-right (flush to
   the left edge, narrower overall box) instead of symmetric margins, still not lining
   up with the inputs above it. Pin margin-left explicitly too, with !important so it
   wins regardless of which of those breakpoints is active. */
/* UPDATED 2026-10-01 (owner direct request, this round, item 1): owner asked for this
   exact rule verbatim (padding/margin/width), superseding the separate margin-left/
   margin-right fix above (Bug_2/Bug_37). box-sizing:border-box is kept so the
   calc(100% - 20px) width still accounts for the 10px margin on each side and the
   textarea's own border, matching the other Enquiry-form fields. */
.enq_form textarea {
	padding: 10px !important;
	margin: 10px !important;
	width: calc(100% - 20px) !important;
	box-sizing: border-box;
}

/* Bug_3: the visible header logo (.site-logo.mob, used up to the desktop breakpoint too)
   sat only ~16px from the first nav item ("Home"). Open that up a bit.
   UPDATED 2026-10-01 (owner direct request, item 1): also give the nav block 50px of
   right padding, so the last nav item ("CONTACT US") doesn't sit flush against the
   edge of the header's content area. */
.right-nav .desk-nav {
	margin-left: 15px;
	padding-right: 50px;
}

/* Bug_12: on mobile, ".industries" (wraps the Aerospace / Software / Manufacturing cards)
   is an inline-block that isn't centered in its column, so it hugs the right edge with a
   gap on the left. Center it as a block instead. */
@media (max-width: 767px) {
	.industries {
		display: block;
		margin-left: auto;
		margin-right: auto;
		text-align: center;
	}
}

/* Bug_16: page-banner breadcrumbs (every interior page) had no hover state on "Home" and no
   distinct styling for the current page - both were plain white/85%-opacity text. */
.pageCaption #breadcrumbs a:hover {
	color: #1BBCF3;
	opacity: 1;
}
.pageCaption .breadcrumb_last {
	color: #1BBCF3;
	opacity: 1;
	font-weight: 600;
}

/* ---------------------------------------------------------------------------------
 * Second round of fixes (desktop bugs rechecked + mobile pass)
 * --------------------------------------------------------------------------------- */

/* Bug_44 / Bug_45 / Bug_29 / Bug_35 / Bug_46 (2026-09-30): pushed every interior banner
   down clear of the transparent, absolutely-positioned header, gave the header a solid
   dark background on interior pages so its nav text stayed readable over the resulting
   white background, and moved the mobile page-title/breadcrumb caption out of its
   normal absolute/centered overlay into a static band below the image.
   REVERTED 2026-10-01 (owner direct request, items 2/3/4/5): the owner asked for the
   header background removed, the banner's margin-top removed on both desktop and
   mobile, and the banner section kept structurally the same as the original site on
   every page (reference: the owner's screenshot of the Blog page, where the page
   title/breadcrumb sit overlaid and centered directly on the banner photo, exactly as
   the theme originally drew it - not pushed below the image). All three rules above are
   removed accordingly, restoring the theme's original header/banner behavior; nothing
   in this section currently overrides them. */

/* Bug_7: `.main-menu ul.menu li` padding was later overridden to right-only
   (padding:0 23px 0 0), producing uneven, asymmetric horizontal gaps between nav items.
   Use consistent, symmetric spacing and vertical centering instead.
   UPDATED 2026-10-01 (owner direct request, item 2 - "increase space between main menu
   by 10px"): each item's own left/right padding is one side of the gap between two
   adjacent items, so raising both sides from 15px to 20px widens every gap by 10px
   total (5px gained on each side) without disturbing the vertical centering above.
   UPDATED AGAIN 2026-10-01 (same afternoon, owner's own explicit CSS): padding raised
   further to 30px a side, verbatim as the owner specified. */
.main-menu ul.menu {
	align-items: center;
}
.main-menu ul.menu li {
	padding: 0 30px !important;
}
.main-menu ul.menu li:last-child {
	padding-right: 0 !important;
}

/* Bug_9 / Bug_47, rebuilt 2026-09-30 for the new "Technologies" mega menu + "About Us"
   dropdown restructure. Two shapes now share the same `.sub-menu` class:
     - a plain 1-level dropdown (About Us: What We Do / Why Prointegrate / Our Presence)
     - a 2-level mega menu (Technologies: 5 category columns, each with its own leaf links)
   The mega-menu variant is detected structurally with :has(), rather than hardcoded by
   menu-item ID, so it keeps working if items are reordered or renamed. Scoped to
   `.main-menu` only (desktop nav) - the `.overlay` mobile menu keeps the theme's default
   `.sub-menu{display:none}` + the existing generic accordion JS in js/main.js, which is
   already depth-agnostic and needs no changes for the extra nesting level. */

/* Base: plain 1-level dropdown (About Us, and the default shape for any .sub-menu).
   `max-width: 92vw` added 2026-09-30 as a safety net for narrower desktop/tablet widths
   (this box is only ever shown at 993px and up - see the mega-menu note below on why -
   but it costs nothing to guarantee it can never run past the edge of the viewport even
   there). */
.main-menu ul.menu li .sub-menu {
	left: 0 !important;
	right: auto !important;
	bottom: auto !important;
	top: 100% !important;
	width: 230px !important;
	max-width: 92vw;
	padding: 10px 0 !important;
	background-color: #10aee2;
	box-sizing: border-box;
}
.main-menu ul.menu li .sub-menu li {
	width: 100% !important;
	float: none !important;
	text-align: left !important;
}
.main-menu ul.menu li .sub-menu li a {
	padding: 8px 20px !important;
	font-size: 14px;
	font-weight: 400;
	color: #fff;
	text-align: left;
	white-space: normal;
	display: block;
}
/* CORRECTED 2026-09-30 (owner follow-up, "hover text should be white" / the dark box in
   the owner's screenshot): found the actual cause. The theme's own style.css has always
   had a generic `ul .sub-menu li a:hover{background-color:#161617}` rule (a near-black
   fill) sitting under every dropdown/sub-menu link in the theme, from before this menu
   was ever a mega menu. Neither the plain About Us dropdown nor the mega-menu leaf links
   overrode `background-color` on hover anywhere in this file, so that old near-black
   theme rule was still winning underneath whatever hover color we did set - that's the
   dark rectangle that showed up under the (otherwise correctly white) hover text. Killing
   it here, on the same broad selector as the base link style above, covers both shapes at
   once (About Us dropdown and the Technologies mega menu). */
.main-menu ul.menu li .sub-menu li a:hover {
	background-color: transparent;
}
/* Explicit hover-reveal, added 2026-09-30: testing the new About Us dropdown showed
   it never actually opened on hover, even though the mega menu below does (because
   the mega menu gets its own explicit `li:hover > .sub-menu:has(...) {display:flex}`
   rule). That means the theme's own show/hide-on-hover for .sub-menu can't be relied
   on as pure CSS for every case - so every .sub-menu now gets an explicit, guaranteed
   hover reveal here. The more specific mega-menu hover rule further below still wins
   over this one (display:flex beats display:block) for Technologies specifically. */
.main-menu ul.menu li:hover > .sub-menu {
	display: block !important;
}

/* Added 2026-09-30: hardening, not the actual fix for the dark hover box (that turned out
   to be a real theme rule - see the `:hover{background-color:transparent}` override just
   above). A nav menu's text still isn't meant to be selected like body copy though: with
   no `user-select` rule at all, an ordinary hover that drifts a pixel or two while moving
   (easy with a trackpad) can leave the browser's native text-selection highlight (see
   `::selection` in the theme's own style.css) sitting on a link's text, so it's turned off
   here too, along with the similar mobile/touch "tap highlight" flash. */
.main-menu ul.menu li .sub-menu,
.main-menu ul.menu li .sub-menu a {
	user-select: none;
	-webkit-tap-highlight-color: transparent;
}

/* Mega-menu variant, REPLACED 2026-10-01 (owner direct request, item 1 - reference
   screenshot of another site's "Services" nav): the previous design (history kept
   below this note) showed all 5 Technologies categories at once in a wide, 3-column
   grid with every category's full leaf list visible simultaneously. The owner asked
   for the desktop Technologies dropdown to instead match the referenced pattern: a
   single plain column of category rows (the same width/shape as the About Us dropdown
   above), each with a small arrow indicating it has its own items, and those items
   revealed in a second flyout panel that slides out to the right of that one category
   row on hover - not all categories' items shown at once.
   Previous design history (1140px fixed-position 3-column grid, and why): centering a
   1140px box on the "Technologies" <li> overflowed past 1366px screens since the link
   sits right-of-center in the nav; anchoring it to the nearest positioned ancestor
   (`nav.main-menu`) undershot the real right edge of the screen; `position:fixed` with
   `right:0` fixed both. A flat 5-column flex layout was too narrow for the longest
   service names, so it became a 3-column CSS grid. None of that positioning complexity
   is needed anymore: a single ~280px column just reuses the plain dropdown's own
   `left:0; top:100%` anchoring (the base rule two sections above), the same way the
   About Us dropdown already works. */

/* Technologies' own first-level panel: same plain dropdown box as the base rule above,
   just slightly wider to comfortably fit the longer category names ("Integration &
   Middleware", etc.) on one line. */
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) {
	width: 280px !important;
}

/* Category rows: a plain stacked list (not a grid) - each row is `position:relative`
   so its own leaf flyout (below) can anchor to it directly rather than to the whole
   Technologies panel. */
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li {
	position: relative;
	width: 100% !important;
	float: none !important;
	text-align: left !important;
	padding: 0 !important;
	margin: 0 !important;
	box-sizing: border-box;
}

/* Category label: a normal row (not the old bold/underlined "section heading" look),
   with a plain-CSS right-pointing chevron (same rotated-border trick as the Bug_43/57
   carousel arrows above, so it never depends on the icomoon font) signaling "more
   inside" - matching the reference screenshot's arrowed rows. */
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li > a {
	display: flex;
	align-items: center;
	justify-content: space-between;
	padding: 10px 20px !important;
	margin: 0;
	font-size: 14px;
	font-weight: 400;
	text-transform: none;
	letter-spacing: normal;
	color: #fff;
	text-align: left;
	white-space: normal;
	border-bottom: none;
	pointer-events: auto;
	cursor: default;
}
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li > a:after {
	content: '';
	flex: 0 0 auto;
	width: 6px;
	height: 6px;
	margin-left: 10px;
	border-top: 2px solid #fff;
	border-right: 2px solid #fff;
	transform: rotate(45deg);
}
/* Hover/active state on the category row itself, so it's clear which one's flyout is
   currently open (the reference screenshot highlights the hovered row). */
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li:hover > a {
	background-color: rgba(255, 255, 255, 0.12);
}

/* Leaf-level flyout (the actual service links under one category): hidden by default
   and revealed only to the right of its OWN category row on hover - this is the real
   behavior change from the old design, where every category's leaf list was always
   visible at once inside the wide grid. */
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li > .sub-menu {
	position: absolute !important;
	display: none;
	top: 0 !important;
	left: 100% !important;
	right: auto !important;
	bottom: auto !important;
	margin-left: 1px;
	width: 260px !important;
	max-width: none !important;
	transform: none !important;
	background: #10aee2 !important;
	padding: 8px 0 !important;
	box-shadow: 2px 2px 10px rgba(0, 0, 0, 0.25);
	box-sizing: border-box;
}
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li:hover > .sub-menu {
	display: block;
}
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li > .sub-menu li {
	width: 100% !important;
	float: none !important;
}
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li > .sub-menu li a {
	padding: 8px 20px !important;
	font-size: 13px;
	/* UPDATED 2026-10-06 (owner direct request, verbatim CSS): font-weight 300 -> 400. */
	font-weight: 400;
	text-align: left;
	color: #fff;
	white-space: normal;
	overflow: visible;
	text-overflow: clip;
	display: block;
}
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li > .sub-menu li a:hover {
	background-color: rgba(255, 255, 255, 0.12);
	text-decoration: none;
}

/* Mobile (.overlay) indent polish - cosmetic indent for nested sub-menu levels. The
   accordion open/close mechanics themselves DO work (js/main.js prepends a `.sub-icon`
   arrow into every `li.menu-item-has-children` under `header nav`, including inside
   `.overlay`, and binds slideToggle to it) - see the real bug and fix for it further
   down, in the Bug_8 mobile block: it wasn't the toggle logic that was missing, it was
   that the arrow became visually detached from its own menu-item text once the row was
   stretched full width. */
@media (max-width: 767px) {
	.overlay ul li .sub-menu li a {
		padding-left: 30px;
	}
	.overlay ul li .sub-menu .sub-menu li a {
		padding-left: 45px;
		font-size: 13px;
	}
}

/* Bug_15 / Bug_17: `.main-container` (the generic page.php template used by About Us,
   Why Choose Us, and other plain pages) reserved 100px of top padding before the page's
   own H2 (which adds its own 32px margin on top of that), leaving an oversized gap under
   the page banner. Bring it in line with the page's existing 50px bottom padding. The
   mobile override (30px, in the theme's own stylesheet) is left untouched. */
@media (min-width: 768px) {
	.main-container {
		padding-top: 50px;
	}
}

/* Bug_26 / Bug_27: the contact-form submit button ("Send" on Our Presence / home Contact,
   "Reach Us" on Industries) was floated right (desktop) or left (narrower breakpoints)
   instead of sitting flush with / centered under the form fields above it. Bug_26 tester
   follow-up: on Our Presence the Send button sat directly under the reCAPTCHA widget with
   no gap at all - add breathing room above the submit button generally. */
.contact-form .submit,
.contact-form li.submit {
	text-align: center;
	margin-top: 20px;
}
.contact-form .btn,
.sectionContact .contact-form .btn {
	float: none !important;
	display: inline-block;
	margin: 0 auto;
}

/* Bug_30: no spacing was defined between adjacent sidebar widgets, so the Search widget
   sat flush against the following "Recent Posts" widget title. */
.sidebar .widget + .widget {
	margin-top: 35px;
}

/* Bug_33: on narrower/tablet breakpoints the theme's own stylesheet zeroes out
   `.contact-sec h2{margin-top:0}`, leaving the "Contact us!" title with no separation
   from the section above it once the section stops being a fixed 100vh block. */
@media (max-width: 991px) {
	.contact-sec h2 {
		margin-top: 25px !important;
	}
}

/* Bug_43 / Bug_57: the marquee/carousel nav arrows sitewide (the client-logo marquee
   here, and the Technologies-page cascade logo slider below) are drawn with the theme's
   own custom "icomoon" icon font, using content:'\f060' / '\f061' for the left/right
   glyphs. CORRECTED 2026-09-30: that mapping is exactly what the theme's own CSS uses
   for ".icon-arrow-left" / ".icon-arrow-right" too, so the codepoints aren't the
   problem - the icomoon font FILES themselves (wp-content/themes/prointegrate/fonts/
   icomoon.*) are only ~1.3-1.5KB each, far too small to contain a full glyph set, and
   render as missing/broken glyphs for every icon that isn't in that tiny subset. Rather
   than depend on that font at all, draw the arrows with plain CSS (a rotated bordered
   box - the standard chevron trick), which can't ever go missing. */
.clientSliderSec .owl-nav .owl-prev,
.clientSliderSec .owl-nav .owl-next {
	display: flex;
	align-items: center;
	justify-content: center;
}
.clientSliderSec .owl-nav .owl-prev:before,
.clientSliderSec .owl-nav .owl-next:before {
	font-family: initial !important;
	content: '' !important;
	display: block;
	width: 8px;
	height: 8px;
	border-top: 2px solid #fff;
	border-right: 2px solid #fff;
}
.clientSliderSec .owl-nav .owl-prev:before {
	transform: rotate(-135deg);
	margin-left: 4px;
}
.clientSliderSec .owl-nav .owl-next:before {
	transform: rotate(45deg);
	margin-right: 4px;
}
.cascade-slider_arrow-left:after,
.cascade-slider_arrow-right:after {
	font-family: initial !important;
	content: '' !important;
	display: inline-block;
	width: 14px;
	height: 14px;
	border-top: 3px solid #1BBCF3;
	border-right: 3px solid #1BBCF3;
}
.cascade-slider_arrow-left:after {
	transform: rotate(-135deg);
}
.cascade-slider_arrow-right:after {
	transform: rotate(45deg);
}

/* Bug_48: phone numbers / email addresses typed as plain text inside page content
   (e.g. "Call us @ US: +1646 205 2279") are auto-linked into tel:/mailto: links by
   js/inline/auto-link-contact.js. See that file for the actual logic; this just
   restores the normal link look for the ones it creates so they read as clickable. */
.post a[href^="tel:"],
.post a[href^="mailto:"] {
	color: #1BBCF3;
	text-decoration: underline;
}

/* Bug_10, part two (2026-09-30): the padding/margin trims further down (inside the
   max-width:767px block) closed up the excess empty space, but testers kept seeing the
   "ABOUT US" title out of alignment with the paragraph underneath it. Root cause: the
   theme's own stacked mobile layout (max-width:992px) centers `.about-sec .left-text`
   (which holds the "WHY PROINTEGRATE" eyebrow + "ABOUT US" h2) - `text-align:center` -
   but never applies the same centering to the sibling `.right-texts` block (the
   paragraph + "Know More" button), which stays at its desktop default (effectively
   left-aligned). So once the two columns stack into one on mobile, the title reads
   centered while the paragraph and button directly below it read left-aligned - two
   different alignments in what is now a single vertical column. Center both, so the
   whole stacked section reads as one consistently aligned block. */
@media (max-width: 992px) {
	.about-sec .right-texts {
		text-align: center;
	}
}

/* Bug_10, part three (2026-10-01, owner direct request): color/size the "ABOUT US"
   heading (an <h1> - about_heading - inside .about-sec .left-text) explicitly on
   mobile, rather than relying on the theme's own responsive h1 sizing. */
@media (max-width: 767px) {
	.about-sec h1 {
		color: #ffffff;
		font-size: 2rem;
	}
}

/* ---------------------------------------------------------------------------------
 * Mobile-only fixes (viewport <= 767px), Bug_6 / Bug_8 / Bug_19 / Bug_24.
 * Re-reviewed 2026-09-30 by tracing each selector against the theme's own style.css
 * (specificity + media-query overlap check), since a real mobile viewport still isn't
 * reachable from the browser-automation tooling in this session. Corrections from that
 * review are on Bug_8 and Bug_19 below; Bug_24 was confirmed already correct.
 * --------------------------------------------------------------------------------- */
@media (max-width: 767px) {
	/* Bug_6: top bar (US/UK/IND + email) and the logo/hamburger row had no vertical
	   breathing room between them once the top bar wraps to its centered, inline-block
	   mobile layout, and the logo wasn't vertically centered with the hamburger icon.
	   `.top_items li` here is (0,2,0) vs. the theme's own `header .top_items li` at
	   (0,1,2), so this wins on specificity. `.header_block`, `.logo-ani` and `.mob-mav`
	   are not styled by the theme at all. Further correction this round: the hamburger
	   icon (`#toggle` / `.button_container`) is `position:fixed` with a hand-tuned
	   pixel `top` offset calibrated to the theme's ORIGINAL top-bar height - once that
	   top bar's padding is trimmed below, the fixed offset no longer lines up with the
	   logo row. Re-anchor it to `.mob-mav` itself (vertically centered) instead of a
	   guessed pixel value, so it always matches the logo regardless of top-bar height. */
	.top_bar {
		padding: 8px 0;
	}
	.top_bar .top_items li {
		margin: 3px 8px;
	}
	.header_block > .container > .row {
		align-items: center;
	}
	.logo-ani,
	.mob-mav {
		display: flex;
		align-items: center;
	}
	.mob-mav {
		position: relative;
	}
	.button_container {
		position: absolute !important;
		/* CORRECTED 2026-10-01 (owner direct request): top:50% -> top:-35px. */
		/* CORRECTED again 2026-10-01 evening (Bug_13, Prointegrate Bugsheet - Staging):
		   with the top_bar/logo spacing as it exists now, -35px put the icon well above
		   the logo row instead of level with it (measured ~45px above the logo's own
		   vertical center in a real mobile viewport). Re-measured against the current
		   `.site-logo` top offset (corrected below, same bug) and solved for the value
		   that puts this icon's vertical center level with the logo's: +29px. */
		top: 29px !important;
		right: 15px;
		transform: translateY(-50%);
	}

	/* Bug_13 (Prointegrate Bugsheet - Staging, this round): the visible mobile logo
	   (`.site-logo` - currently the `.logo-desk` image, shown up to the desktop
	   breakpoint per Bug_3 above) used the theme's own max-width:480px offset of
	   `top:-8px`, which in a real mobile viewport put the logo's top edge 8px ABOVE
	   the top bar's own bottom edge - an 8px overlap, exactly the "logo sits too
	   close to, and slightly overlaps, the top bar" complaint. Push it down clear of
	   the top bar with a small gap, and pair with the `.button_container` correction
	   above so the hamburger icon lines up with the logo's new vertical center. */
	.header_block .site-logo {
		top: 10px !important;
	}

	/* Bug_8: the hamburger overlay menu centers its items in the full-height panel by
	   default, leaving a large empty gap above "HOME" and below "CONTACT US". The
	   markup's <nav> does carry a `.overlay-menu` class, but the theme never styles
	   that class - the actual centering comes from `.overlay nav` (height 70%, top
	   50%, translateY(-50%)) and `.overlay ul` (flex, centered), both of which
	   out-specificity a bare `.overlay-menu` rule. Target those real selectors instead
	   to anchor the items near the top. Tester follow-up this round: the divider line
	   under each item should span the full panel width, and the close (X) icon should
	   line up with the header. The divider is `.overlay ul li a:after`, sized relative
	   to its own <li> - and the theme's own mobile rule still gives that <li> a fixed
	   185px width (a leftover from its desktop 3-column layout), so the divider only
	   ever draws 185px wide. Make the <li> full width instead. The close icon is the
	   same `.button_container` repositioned above, which stays put whether the panel
	   is open or closed. */
	.overlay nav {
		top: 0;
		transform: none;
		height: auto;
	}
	.overlay ul {
		align-items: flex-start;
		justify-content: flex-start;
		flex-direction: column;
		height: auto;
		width: 100%;
		padding-top: 40px;
	}
	.overlay ul li {
		width: 100% !important;
		margin-bottom: 8px;
	}
	.overlay ul li a {
		width: 100%;
		box-sizing: border-box;
	}

	/* Owner follow-up 2026-09-30 ("not able to see any dropdown menu under about us
	   and technology menu"): this IS the "make the <li>/<a> full width" fix directly
	   above - it fixed the divider line, but broke the accordion arrow as a side
	   effect. js/main.js prepends a `.sub-icon` arrow into every
	   `li.menu-item-has-children` (About Us, Technologies, and each Technologies
	   category), positioned `absolute; right:0` *relative to that <li>*, and binds a
	   click handler on it that slideToggle()s the sub-menu open - none of that logic
	   is missing or broken. But once the <li> spans the full screen width and its
	   text is centered (`.overlay ul{text-align:center}`, inherited from the theme),
	   `right:0` pins the arrow to the far edge of the screen while the text sits in
	   the middle of the row - tens to hundreds of pixels away from it. The dropdown
	   was always one tap away, the arrow just didn't visually belong to its own menu
	   item anymore, so nobody found it. Verified live (by temporarily forcing this
	   panel open in the browser and stepping through the layout): the stray arrow at
	   the far edge did open the dropdown even before this fix; this fix only moves
	   the arrow back next to its text and keeps the full-width divider working. Turn
	   each row into a centered flex group (link text + arrow together) instead of
	   positioning the arrow off the raw <li> width, and move the divider line onto
	   the <li> itself (still full width) since the <a> no longer needs to span the
	   full row for the divider to size off it.
	   SUPERSEDED 2026-10-01 (owner direct request, see "(9)" further below): the
	   centered-group layout below is now overridden again lower in this file to put
	   the arrow on the right and the text on the left instead of centering them
	   together - kept here unchanged as the base layer those overrides build on. */
	.overlay ul li {
		display: flex;
		align-items: center;
		justify-content: center;
		flex-wrap: wrap;
		position: relative;
	}
	.overlay ul li > a {
		width: auto !important;
		flex: 0 1 auto;
	}
	.overlay ul li .sub-icon {
		position: static !important;
		right: auto !important;
		margin-left: 8px;
	}
	.overlay ul li > a:after {
		display: none !important;
	}
	.overlay ul li:not(:last-child):after {
		content: '';
		position: absolute;
		left: 0;
		right: 0;
		bottom: 0;
		height: 2px;
		opacity: .15;
		background: #FFF;
	}

	/* Bug_19: the footer copyright line (footer h5) is right-aligned by default, which
	   reads as "cramped near the edge" once the footer stacks to a single column on
	   mobile. The intended target, `.footer-nav h5`, is a real, separate rule in the
	   theme (`.location-sec .footer-nav h5`) that sets text-align:left starting at
	   max-width:992px - narrower than the theme's generic `footer h5` centering at
	   max-width:1200px - so on mobile it was actually being left-aligned. Kept
	   !important since the theme's own rule there is more specific ((0,2,1) vs
	   (0,1,1)). */
	footer h5,
	.footer-nav h5 {
		text-align: center !important;
		margin-top: 15px;
	}

	/* Bug_24: the offshoring-process step icons on What We Do use the same
	   ".whatWeDoPage .sec2Data .icon-blocks" 95x95 circle at every breakpoint, which is
	   oversized relative to a phone screen and leaves large gaps around it. Confirmed
	   correct: matches the theme's own base rule (same specificity, later in the
	   cascade), and no narrower theme breakpoint outranks it. */
	.whatWeDoPage .sec2Data .icon-blocks {
		width: 60px;
		height: 60px;
		line-height: 54px;
		margin: 0 auto 15px auto;
	}
	.whatWeDoPage .sec2Data .featureBlock {
		margin-bottom: 35px;
	}

	/* Bug_10: on the home page's "ABOUT US" fullPage.js slide (`.about-sec`, a fixed
	   100vh section), the heading/paragraph spacing was tuned for desktop's much taller
	   viewport - trim it down for a phone-height screen. */
	.about-sec .abot-cnt {
		padding-top: 0;
	}
	.about-sec h3 {
		margin-bottom: 8px;
	}
	.about-sec h2 {
		margin-bottom: 12px;
	}
	.about-sec .contents p {
		margin-bottom: 15px;
	}
	.about-sec a.more {
		margin-top: 15px;
	}

	/* Bug_14 / Bug_18: the office-address blocks and the "Call us" / "Email Us" blocks
	   share the same underlying spacing rules (`.location-set{margin-bottom:11.2vh}`,
	   `.detail-cnt{margin-bottom:75px}`) at every breakpoint, including mobile. 11.2vh
	   of gap between each of the three address blocks, and a flat 75px between the
	   phone and email blocks, is disproportionately large on a short phone screen and
	   is exactly the "excessive empty space" both bugs describe. Trim both for mobile. */
	.location-sec .location-set,
	.location-set {
		margin-bottom: 30px;
	}
	.detail-cnt {
		margin-bottom: 25px;
	}

	/* Bug_18, part two (2026-09-30): even after trimming .detail-cnt's own
	   margin-bottom above, the "Call us" / "Email Us" icon still read as floating
	   above and to the right of its own label text at narrow mobile widths -
	   exactly the tester's "icons should shift left to line up with the text
	   below them". Root cause: the theme's own `.location-sec .cnt{margin-top:15px}`
	   (only defined inside its max-width:480px breakpoint) pushes the ".cnt" text
	   block down relative to its "span.icon" sibling inside the same `.detail-cnt`
	   flex row, without moving the icon to match - the 44px icon circle stays
	   pinned to the top of the row while its own "Call us"/phone-number text drops
	   15px below it, so the two no longer read as one aligned unit. Remove that
	   extra push and vertically center the icon against its text instead, which
	   keeps them lined up regardless of how many lines of text the block holds
	   (e.g. two phone numbers vs. one). */
	.location-sec .cnt {
		margin-top: 0;
	}
	.detail-cnt {
		align-items: center;
	}
}

/* Bug_11: icons inside a circular badge (the "Call us" / "Email Us" icon circles, and
   the What We Do offshoring-process icons) rely on a fixed line-height to center the
   icon glyph/image vertically, which drifts out of true center whenever the icon's own
   line-height or the circle's exact size don't match up perfectly. Center with flexbox
   instead, which is exact regardless of the icon's own sizing. */
.detail-cnt span.icon,
.whatWeDoPage .sec2Data .icon-blocks,
.whatWeDoPage .wwdSection2 .icon {
	display: flex !important;
	align-items: center;
	justify-content: center;
}

/* Bug_9 (Prointegrate Bugsheet - Staging, this round): same root cause as Bug_11 above,
   different spot - the home page's "Services" row (`.technologies .it-bg .inner-cnt
   .icon`, the 44px navy circles above "Cloud", "DevOps", etc.) has no centering
   mechanism at all on its own `.icon` span (no flexbox, no line-height), so the image
   inside it just sits at its default inline/baseline position - off-center within the
   circle, and inconsistently so depending on the icon image's own natural height.
   Center it the same way as Bug_11. */
.technologies .inner-cnt > .icon {
	display: flex !important;
	align-items: center;
	justify-content: center;
}

/* Bug_18, part three (2026-10-01, owner direct request): switch the "Call us" /
   "Email Us" blocks in the home page's Our Locations section to an explicit 2-column
   grid (a fixed 66px icon column + an auto-width text column) instead of the flex row
   used above, and tighten the gap between blocks to 32px. `display:grid` and
   `align-items:center` are added alongside the owner's two declarations so the
   grid-template-columns value actually takes effect and the icon stays vertically
   centered against its text; the icon's own `margin-right:30px` (from the theme's base
   `.detail-cnt span.icon` rule) is zeroed out here too, since the 66px column already
   reserves the icon's space and the old margin would otherwise double up with it. */
.location-sec .detail-cnt {
	display: grid;
	grid-template-columns: 66px auto;
	align-items: center;
	margin-bottom: 32px;
}
.location-sec .detail-cnt span.icon {
	margin-right: 0;
}

/* Bug_34: the Technologies listing page's service cards (Dell Boomi, MuleSoft, ...) are
   plain page-content HTML - ".ourPresencePage .location-set > .inner-cnt" holding just a
   heading and a "Read More" link, no icon. But ".inner-cnt" is a shared class whose base
   rule (in style.css) always adds "margin-top:55px", sized for a DIFFERENT context (a
   card that has an icon positioned above the box needing that clearance). With no icon
   here, that margin is pure dead space above every card's title. Scoped narrowly to the
   Technologies page's own card grid so the real Our Presence page (a different
   template) keeps its normal spacing. */
.technologiesPage .ourPresencePage .inner-cnt {
	margin-top: 0;
	padding: 25px 20px;
}
.technologiesPage .ourPresencePage .location-set {
	margin-bottom: 25px;
}

/* Bug_45: the tagline image below the site logo (".logo-text") is deliberately
   positioned with a small negative "top" offset at several breakpoints (part of its
   slide-in reveal animation), which on some pages reads as sitting on top of the logo
   rather than below it. Pin it to a small positive offset everywhere instead. */
.header_block .logo-text {
	top: 4px !important;
}

/* Bug_50 / Bug_61: several Technology service pages (Business Process Management,
   Oracle SOA, TIBCO, OpenShift, Red Hat, Apigee, Web Business, ...) write each
   numbered step as "<ol><li><h2>Heading</h2></li></ol>" in the page content, followed
   by a plain paragraph. The <ol>'s own number marker ("1.", "2.") renders at the
   default 16px body text size, while the <h2> beside it uses the theme's generic h2
   style (font-size:2em, ~32px) - so the number reads far smaller than the heading text
   next to it, and the <li>/<h2> nesting stacks list spacing on top of the h2's own
   margin, producing excess space before the following description. Since this is the
   same markup pattern reused across every affected page, fix it once, sitewide,
   scoped to exactly that pattern (an <li> whose only child is an <h2>) so ordinary
   numbered lists elsewhere are unaffected. */
.post ol > li:has(> h2:only-child) {
	font-size: 2em;
	font-weight: 200;
	margin-bottom: 0.3em;
}
.post ol > li:has(> h2:only-child) h2 {
	display: inline;
	margin: 0;
	font-size: 1em;
	line-height: inherit;
}

/* Bug_50, part two (2026-09-30): the fix above matched the number-marker size to the
   heading, but testers kept seeing a large empty gap between each numbered heading and
   the description paragraph that follows it, and asked for "the section titles" to be
   "properly aligned with the paragraph text and the rest of the content" on mobile. Two
   separate leftovers from the plain <ol>/<li>/<h2> markup were causing this: the <ol>
   itself still carries the browser's default list margin/padding below the last <li>,
   stacking on top of the paragraph's own top margin right after it; and the <li> (sized
   up to font-size:2em by the fix above, to match the inlined heading) still uses its
   default line-height, which no longer matches the inlined <h2>'s own line-height at
   that larger size - so the number and heading text don't sit on the same baseline,
   reading as "misaligned" next to the paragraph beneath them. Collapse the list's own
   spacing and give the number + heading one explicit, shared line-height so they align
   with each other and with the paragraph that follows.
   CORRECTED 2026-10-01 (owner direct request, specific Technology pages: Business
   Process Management, Oracle SOA, TIBCO, OpenShift, Red Hat, Apigee): the gap between
   the <ol> and the following <p> was still too large on both mobile and desktop.
   Reduced the <ol>'s own bottom margin further and pulled the paragraph's top margin
   in tighter (8px -> 4px) so the description sits right under its numbered heading at
   every viewport width. */
.post ol:has(> li > h2:only-child) {
	margin: 0 0 0.15em 0;
	padding-left: 1.2em;
}
.post ol > li:has(> h2:only-child) {
	line-height: 1.3;
}
.post ol > li:has(> h2:only-child) h2 {
	vertical-align: baseline;
}
.post ol:has(> li > h2:only-child) + p {
	margin-top: 4px;
}
@media (max-width: 767px) {
	.post ol > li:has(> h2:only-child) {
		font-size: 1.5em;
	}
}

/* Bug_50, part three (2026-10-01, owner direct request): on single/page views
   (.wp-singular), remove the <ol>'s own bottom spacing entirely and the <li>'s
   bottom padding, tightening the gap to the following <p> further still. */
.wp-singular .post ol:has(> li > h2:only-child) {
	padding-bottom: 0;
	margin-bottom: 0;
}
.wp-singular .post ol > li:has(> h2:only-child) {
	padding-bottom: 0;
}

/* Bug_51: the blog post title ("h1.title" in single.php) used the same large heading
   size on mobile as on desktop, pushing the rest of the page down and reading as
   misaligned with the breadcrumb/posted-by line above and below it. */
@media (max-width: 767px) {
	.blog-detail-container h1.title {
		font-size: 24px;
		line-height: 32px;
		margin-top: 20px;
		margin-bottom: 15px;
	}
}

/* Bug_53: on interior (non-home) pages, mobile browsers were rendering the whole page
   zoomed out to "desktop" scale, with real content squeezed into the left part of the
   screen and a blank white area on the right - the classic mobile-viewport-scaling bug
   that happens when ANY element on the page is wider than the device, even one that is
   off-screen. `.enq_form` (the sticky Enquiry form) is `position:fixed; right:0` and is
   pushed off-canvas via `transform:translateX(150%)` when closed - mobile Safari/Chrome
   still count that transformed box's un-transformed width when sizing the page's layout
   viewport, forcing the "zoom out to fit" behaviour. The home page never showed this
   because fullPage.js's own scroll-locking incidentally masks it. `body` already has
   `overflow-x:hidden`; add the same to `html`, which is the standard fix for this
   mobile-viewport-scaling quirk. */
html {
	overflow-x: hidden;
	width: 100%;
}

/* Bug_58 / Bug_59: the sticky Enquiry form's close (X) icon could sit over the Name
   field on some widths, and the form's own box had no defined width so it depended on
   its content to size itself - fragile inside a `position:fixed` element with no
   `left`/`width` set. Give it an explicit, viewport-safe width and re-seat the close
   icon comfortably inside its own reserved top padding. */
.enq_form {
	width: 320px;
	max-width: 92vw;
	box-sizing: border-box;
}
.enq_form .container {
	width: 100%;
	max-width: 100%;
	padding: 0 15px;
}
.enq_form .enq_form_close {
	top: 6px;
	right: 10px;
	z-index: 5;
}

/* Bug_55: the footer (".site-footer", every page except Home) inherited a generic
   "footer{padding:50px 0}" rule intended for a taller desktop layout.
   CORRECTION 2026-09-30 (second pass): the user reported the footer was STILL too tall
   after an earlier padding tweak. Two separate things were going on:
   1) The `.enq_form { position: relative; }` rule added under Bug_42 was pulling the
      ~400px-tall sticky Enquiry form out of `position:fixed` and into normal flow
      *inside* this flex footer, adding its entire height to the footer's rendered
      height on every page, regardless of what padding value was used here. Removed -
      see the Bug_42 note above.
   2) A direct getComputedStyle() comparison against production (www.prointegrate.net)
      at that point had been thrown off by the very bug in (1) - it was actually
      reading a wrapped, inflated layout - and concluded production used a uniform
      "padding:30px", which was wrong. Re-measured cleanly after fixing (1): production's
      real `.site-footer` padding is "50px 0" (top/bottom only, no left/right) - i.e.
      exactly what the theme's own generic `footer{padding:50px 0}` rule already gives
      it. So no override is needed here at all now that (1) is fixed; this rule is kept
      only to make that explicit and pin it against any future change to the generic
      `footer` rule. */
.site-footer {
	padding: 50px 0;
}

/* Bug_56: `.clientSliderSec`'s own top padding was removed entirely per the owner's
   direct request (see the "(4)" note in the third-round section below), which also
   removed the breathing room QA expects above its "Some of our Global Clients" title.
   Restore that spacing on the title itself instead of the section, so the section-level
   padding stays at the owner's requested zero. */
.clientSliderSec h2 {
	margin-top: 24px;
}

/* ---------------------------------------------------------------------------------
 * Third round: direct owner-requested tweaks (2026-09-29 evening)
 * --------------------------------------------------------------------------------- */

/* (1) Interior-page banner clearance was slightly more than needed once the header's
   solid background made the whole header block read as one visual unit - 130px reads
   tighter and still clears the header at 1366px. (Base/desktop value only; the
   tablet/mobile values right above are unchanged.)
   CORRECTED 2026-10-01 (owner direct request): tightened again from 130px to 77px. */
/* handled by editing the base ".section > .banner" rule above to 77px */

/* (3) On the home page, clicking a header nav item should play the same look the header
   gets on a real scroll. Checked what a real scroll actually does: with the header
   position:absolute (not fixed), scrolling the page just carries the WHOLE header up
   with everything else, so the top_bar (phone numbers row) rides out of view and only
   the logo/nav row is left - it reads as the top bar "fading out", since it shrinks out
   of frame smoothly rather than snapping away. Reproduce that as an explicit fade +
   collapse of .top_bar itself (opacity to 0, height collapsed to 0) rather than
   translating the whole header, so the effect is a clean fade instead of a hard slide,
   and the nav row settles into its place as the top bar's space closes up - the same
   end result a real scroll produces, playable on demand via js/inline/home-nav-anim.js
   adding/removing the .pi-nav-clicked class on click. */
body:has(#fullpage) .top_bar {
	transition: opacity 0.3s ease, max-height 0.3s ease, padding-top 0.3s ease, padding-bottom 0.3s ease;
	max-height: 60px;
	overflow: hidden;
}
body:has(#fullpage) header.pi-nav-clicked .top_bar {
	opacity: 0;
	max-height: 0;
	padding-top: 0;
	padding-bottom: 0;
}

/* (4) `.clientSliderSec` (the "Some of our Global Clients" wrapper, included in
   footer.php on every non-home page) had 75px/55px top padding and 200px/140px bottom
   padding from the theme's own stylesheet. Remove the top padding entirely and settle
   the bottom padding at a single 100px everywhere it appears. */
.clientSliderSec {
	padding-top: 0 !important;
	padding-bottom: 100px !important;
}

/* (5) On the Technologies listing page, the cascade logo slider
   (".technologiesPage .cascade-slider_container") was fixed at 350px tall regardless of
   viewport, which is far taller than the logos inside it need. Bring it down to 130px.
   CORRECTED 2026-09-30 (Bug_38, stray oversized MuleSoft logo on mobile): this override
   carried no media query, so it was winning at EVERY viewport width, including the
   theme's own tuned mobile breakpoint (max-width:480px), where style.css already sets a
   correct, purpose-built `height:250px` (paired with its own `.cascade-slider_item{
   width:72%;top:40%}` positioning for that exact height). Forcing 130px there broke that
   pairing - the slide items are positioned assuming a 250px-tall stage, so squeezing the
   stage down to 130px let one oversized logo slide render far outside its intended box.
   Verified against the reference production site (www.prointegrate.net/technologies/)
   that the 1000x350 desktop size and the request behind this override really are
   desktop-only. Rescoped to only apply at tablet width and up, so mobile now gets the
   theme's own already-correct 250px sizing back untouched. */
@media (min-width: 768px) {
	.technologiesPage .cascade-slider_container {
		height: 130px;
	}
}

/* (6) `.clientSliderSec .owl-dots` (the client-logo marquee's dot navigation) should sit
   closer to the carousel than the sitewide default everywhere the slider appears - not
   just on the Technologies page. Was previously scoped to
   .page-template-template-Technologies only; owner asked to apply it on all pages.
   NOTE: this directly conflicts with Bug_22/Bug_60 on the latest QA pass, which ask for
   these same dots to be REMOVED entirely on mobile. Left as the owner explicitly
   requested until that conflict is resolved - see chat reply. */
.clientSliderSec .owl-dots {
	bottom: -46px;
}

/* (7) (2026-10-01, owner direct request): on the narrowest phones, force the phone
   number link inside the "Call us" block (".location-sec .cnt a.number") onto its own
   line, rather than letting it wrap inline with the rest of the ".cnt" text. */
@media only screen and (max-width: 480px) {
	.location-sec .cnt a.number {
		display: block;
	}
}

/* (8) (2026-10-01, owner report): "click on About Us / Technologies, sub-menu does not
   open on mobile". Root cause found by testing the hamburger overlay menu at a real
   375px-wide viewport: the down-arrow toggle for "About Us", "Technologies" (and each
   Technologies category underneath, e.g. "Integration & Middleware") was never missing
   and the click-to-expand JS (js/main.js: prepends a `.sub-icon` arrow into every
   `li.menu-item-has-children` and slideToggle()s its `.sub-menu` on click) was never
   broken - but the arrow glyph itself was INVISIBLE on every phone 480px wide or
   narrower (i.e. effectively all real phones), because the theme's own style.css has,
   inside its own `@media (max-width:480px)` block:
       .icon-keyboard_arrow_down:before{display:none}
       nav .sub-icon.open:before{display:none}
   These unconditionally hide the arrow's generated content (both before and after it's
   tapped open), collapsing the arrow to 0x0 since an empty `::before` renders nothing.
   With no visible arrow to tap, and the plain text link only navigating to the page
   instead of expanding anything, the dropdown looked completely unopenable - exactly as
   reported. Restore the glyph at that same breakpoint, scoped to the mobile overlay
   menu; its position (immediately to the right of the menu text, per Bug_8 above) is
   unchanged. Verified in a real 375px viewport: arrow now renders, and clicking it
   correctly slideToggle()s the "About Us" / "Technologies" / nested-category dropdowns
   open and closed, both before and after the `.open` state. */
@media only screen and (max-width: 480px) {
	.overlay ul li .icon-keyboard_arrow_down:before,
	.overlay ul li .sub-icon.open:before {
		display: inline-block !important;
	}
}

/* (9) (2026-10-01, owner direct request): rework the mobile hamburger accordion layout
   for "About Us" / "Technologies" (and nested categories underneath).
   1) Arrow on the right, label text on the left. Previously both sat centered together
      as one group (Bug_8 above) - correct position relative to each other, but the
      arrow is the first element in the DOM (js/main.js prepends it before the link), so
      centered-together always put the arrow visually first/left of the text. Re-order
      visually with flexbox `order` (arrow pushed to order:2, keeping the DOM/JS
      untouched) and let the link text take the row's full remaining width, left-aligned.
   2) Submenu kept below the main item. The theme's own `.sub-menu` is normally an
      absolutely/narrowly positioned flyout box (built for desktop hover dropdowns) -
      inside `.overlay` that showed up as a small ~180px floating box with a negative
      top offset overlapping its own parent row (see the owner's screenshot), instead of
      a plain accordion panel. Reset it to a normal, static, full-width block; since the
      parent `<li>` is already `display:flex; flex-wrap:wrap` (Bug_8), giving the
      sub-menu `order:3` + `width:100%` makes it wrap onto its own line directly under
      the label+arrow row, exactly like a standard mobile accordion.
   3) Owner's explicit CSS, added verbatim: force the sub-menu to 100% width at the
      narrowest phone breakpoint too (kept as its own rule below, in addition to the
      max-width:767px width:100% already covering it, in case this needs tuning
      independently later).
   4) Submenu UI kept consistent with the rest of the mobile menu: full-width rows,
      left-aligned text, same transparent-on-dark look as the main list (instead of the
      theme's small centered cyan flyout box), so it reads as one continuous accordion
      list rather than a different, disconnected widget popping out mid-menu. */
@media only screen and (max-width: 767px) {
	.overlay ul li {
		justify-content: flex-start;
	}
	.overlay ul li > a {
		flex: 1 1 auto;
		text-align: left;
	}
	.overlay ul li .sub-icon {
		order: 2;
		margin-left: auto;
		margin-right: 4px;
	}
	.overlay ul.sub-menu {
		position: static !important;
		left: auto !important;
		right: auto !important;
		top: auto !important;
		bottom: auto !important;
		transform: none !important;
		width: 100% !important;
		max-width: none !important;
		margin: 10px 0 0 0 !important;
		padding: 0 !important;
		/* CORRECTED 2026-10-01 (owner direct request, item 3): background swapped from the
		   faint white tint to fully transparent, per the owner's own CSS. */
		background: transparent;
		text-align: left;
		order: 3;
	}
	.overlay ul.sub-menu li {
		width: 100% !important;
		text-align: left;
	}
	.overlay ul.sub-menu li > a {
		justify-content: flex-start;
		text-align: left;
	}
}

/* (9), part two - owner's explicit rule, kept as its own declaration for the narrowest
   phones. */
@media only screen and (max-width: 480px) {
	.overlay ul.sub-menu {
		width: 100% !important;
	}
}

/* ---------------------------------------------------------------------------------
 * Fourth round: direct owner-requested tweaks (2026-10-01 afternoon)
 * --------------------------------------------------------------------------------- */

/* (10) (2026-10-01, owner direct request, item 4): the interior-page banner caption
   paragraph ("h1.banner-para") reads too large sitewide - bring it down to 1.5rem.
   CORRECTED 2026-10-01 (same session, found on live verification): the page itself
   carries its own per-page `<style>` block (page builder/content-editor CSS, enqueued
   after this file) with its own `h1.banner-para{font-size:...}` rules (3em base, 2rem
   at a narrower breakpoint) - identical selector, so identical specificity, and later
   in source order always wins a tie. Needs !important to actually override it. */
h1.banner-para {
	font-size: 1.5rem !important;
}

/* (11) (2026-10-01, owner direct request, item 5): on the narrowest phones, fix the
   banner image at a 350px band and crop it (object-fit:cover, centered) rather than
   letting it scale to its natural aspect ratio, so every interior-page banner reads as
   one consistent height on mobile regardless of that image's own dimensions. Owner's
   CSS added verbatim. */
@media only screen and (max-width: 480px) {
	.banner img {
		height: 350px;
		object-fit: cover;
		object-position: center;
		width: 100%;
	}
}

/* ---------------------------------------------------------------------------------
 * Fifth round: direct owner-requested tweaks (2026-10-01 afternoon, continued)
 * --------------------------------------------------------------------------------- */

/* (12) (2026-10-01, owner direct request, item 2): let the mobile hamburger overlay's
   <nav> grow to the full viewport height and scroll internally, rather than the fixed
   70%-height/auto-height box set by Bug_8 above - needed now that a fully expanded
   "Technologies" accordion (5 categories, several open at once) can run taller than a
   short phone screen. Owner's CSS added verbatim; placed after the Bug_8 rule above so
   it wins on source order (same selector, same specificity). */
@media (max-width: 767px) {
	.overlay nav {
		height: 100vh;
		overflow: auto;
	}
}

/* (13) (2026-10-01, owner direct request, item 3): tighten the mobile accordion's
   single-level dropdown leaf links (About Us: What We Do / Why Prointegrate / Our
   Presence) - less left indent and extra bottom padding between stacked rows. Owner's
   CSS added verbatim; placed after the earlier `.overlay ul li .sub-menu li
   a{padding-left:30px}` rule (Mobile indent polish, above) so it wins on source order
   (same selector, same specificity).
   NARROWED 2026-10-01 (same afternoon, owner direct request): the owner has since asked
   for the double-nested Technologies leaf links (handled separately below as item 14)
   to use their own, different left-indent value instead of matching this one, so this
   rule is scoped back to the single-level selector only. */
@media (max-width: 767px) {
	.overlay ul li .sub-menu li a {
		padding-left: 15px;
		padding-bottom: 10px;
	}
}

/* (14) (2026-10-01, owner direct request, item "2" of this round): the Technologies
   leaf links (e.g. "MuleSoft Consulting Services"), nested under a SECOND `.sub-menu`
   level (Technologies > category > leaf), get their own left-indent value, separate
   from the single-level dropdown rule above. Owner's CSS added verbatim; placed after
   both the earlier "Mobile indent polish" rule
   (`.overlay ul li .sub-menu .sub-menu li a{padding-left:45px}`) and item (13) above so
   it wins on source order (same selector, same specificity). Only padding-left was
   specified here, so padding-bottom falls back to whatever the cascade otherwise
   resolves for this selector (nothing else currently sets it, so it is 0 by default). */
@media (max-width: 767px) {
	.overlay ul li .sub-menu .sub-menu li a {
		padding-left: 30px;
	}
}

/* ---------------------------------------------------------------------------------
 * Sixth round: "Prointegrate Bugsheet - Staging" CSV (uploaded 2026-10-01 evening).
 * Bug_1 (no email received, sticky Enquiry form) and Bug_4 (no email received, home
 * Contact Us form) are not CSS/template bugs - see inc/forms.php and inc/smtp.php,
 * which already explain and log this: wp_mail() reports success, but bare PHP mail()
 * on this host has no SPF/DKIM/sending reputation of its own, so receiving mail
 * servers silently drop it. The real fix is turning on Theme Settings -> Email & SMTP
 * with a real mailbox's credentials (Gmail, Microsoft 365, SendGrid, ...), which only
 * the site owner can supply. Bug_5 (reCAPTCHA "Invalid site key" on
 * www.prointegrate.net/contact-us/) is the same kind of issue: the configured
 * reCAPTCHA site key isn't registered for that domain in Google's reCAPTCHA admin
 * console, which again needs the owner's own Google account access, not a code change.
 * --------------------------------------------------------------------------------- */

/* Bug_14: the mobile hamburger overlay's close (X) icon is the same `.button_container`
   used to open it (Bug_6/Bug_13 above) - positioned `absolute` against `.mob-mav`,
   which lives inside `.header_block`. `.header_block` itself is never anything but
   `position:absolute` (the theme's own base style), which is positioned relative to
   the DOCUMENT, not the viewport - so while the overlay menu is open, if the page
   underneath is scrolled (nothing was stopping that; `body` only had
   `overflow-x:hidden` from Bug_53 above, not `overflow-y`), the whole header -
   including this close icon - scrolls away with the document, while `.overlay` itself
   (a separate, independently `position:fixed` element) stays put. Reproduced in a real
   375px viewport: opening the menu and then scrolling 300px moved the close icon
   exactly 300px off-screen. The standard, complete fix is to stop the background from
   scrolling at all while the overlay is open - its own `<nav>` already has its own
   internal scroll (the "(12)" fix above) for long, fully-expanded accordions, so
   nothing legitimate needs the outer page to scroll while the panel is open anyway. */
@media (max-width: 767px) {
	body:has(.overlay.open) {
		overflow: hidden !important;
		height: 100vh;
	}
}

/* Bug_13, continued: "the header, including the hamburger menu, should remain fixed or
   sticky at the top of the page while scrolling, ensuring that the menu is always
   accessible." The theme already half-built this: js/main.js adds a `.fixedheader`
   class to `.header_block` once the page is scrolled 300px, but no CSS anywhere
   (checked both style.css and this file) ever did anything with that class beyond
   recoloring the hamburger bars (`.fixedheader .button_container span{background:
   #1BBCF3}`) - the header itself just keeps scrolling away with the page. Complete the
   feature by actually pinning the header once that class is present. Scoped to mobile
   only, so this doesn't reopen the header-background/banner-spacing changes the owner
   asked reverted on desktop earlier (see the "REVERTED 2026-10-01" note near the top of
   this file) - those were about the banner's own layout, not this scroll behaviour. */
@media (max-width: 767px) {
	.header_block.fixedheader {
		position: fixed;
		top: 0;
		left: 0;
		width: 100%;
		z-index: 1000;
		background: #020F1A;
	}
}

/* Bug_15: the footer menu is centered on every normal interior page (footer.php uses a
   real `<footer>` element, and the theme's own generic `footer ul{display:block;
   text-align:center}` rule - not scoped to `.location-sec` - applies to it), but the
   Home page renders its OWN copy of this same markup inside `<section class=
   "location-sec">` instead of a `<footer>` tag (see footer.php's own comment: "the home
   page renders its own footer section inside #fullpage"). That means none of the
   generic `footer ...` rules reach it - only the theme's `.location-sec .footer-nav
   ul{display:flex}` rule does, which sets no text-align/justify-content at all, so it
   falls back to flexbox's default start-alignment (left), while every other page reads
   as centered. Match the centered look on mobile, where `.location-sec .footer-nav
   ul` is already switched to a column layout by the theme's own responsive rules. */
@media (max-width: 767px) {
	.location-sec .footer-nav ul {
		align-items: center;
	}
	.location-sec .footer-nav ul li a {
		text-align: center;
	}
}

/* Bug_7: the blog post's byline row (`.post-name`, single.php - "By <author>",
   publish date, updated date, read time, category) has no wrap control of its own, so
   on a narrow phone its five `<span>` items break wherever the text itself happens to
   run out of room, sometimes splitting a single item like "Updated:" from its own date
   across two lines. Let items wrap onto their own lines as a group (already workable,
   since `.post-name` is `display:block` and each span is already on its own line via
   theme spacing), but stop an individual item's own text/icon from wrapping internally
   so each line always reads as one complete, tidy unit (e.g. "Posted By Admin On Thu,
   Sep 17, 2026" stays together on one line instead of breaking mid-phrase). */
@media (max-width: 767px) {
	.post-name span {
		white-space: nowrap;
	}
}


/* ===================================================================================
 * 2026-10-01 (owner direct request, follow-up round): seven explicit items from the
 * owner. Items 1 (.enq_form textarea) and 2 (Recent Comments) are handled above /
 * separately - see the write-up sent with this round. Items 3-7 below are the owner's
 * CSS, added verbatim, placed last so they win in the cascade.
 * ----------------------------------------------------------------------------------
 * Items 5 and 6 intentionally REVERT the `.button_container top` (was 29px) and
 * `.header_block .site-logo top` (was 10px) values set earlier this round under
 * "Bug_13 (Prointegrate Bugsheet - Staging, this round)" (see the mobile-only block
 * above, ~line 539-563). That earlier fix was derived from on-device pixel
 * measurements showing an 8px logo/top-bar overlap and a ~45px hamburger/logo
 * vertical mismatch at top:-35px/top:-8px. The owner has since asked for -36px/0px
 * explicitly, which is very close to those original (buggy) values, so the overlap
 * and misalignment measured earlier are likely to reappear. Flagging this here;
 * applying as instructed since it was given as explicit, literal CSS.
 * =================================================================================== */

/* Item 3 (owner, this round): blog listing page (https://prointegrate.staticwebsite.in/blog/),
   mobile only. Larger post-title type. NOTE: `.post-title` is also used by index.php's
   own "Nothing Found" heading when a blog/search page has no posts - this rule will
   apply there too since no narrower selector was given. */
/* Item 4 (owner, this round): blog listing page, mobile only. Lay the byline row
   (author / date) out with flex + a fixed gap instead of the theme's default stacking.
   NOTE: `.post-name` is also used by single.php's post byline, which shares the same
   class - this rule applies there too since no page-scoped selector was given. */
@media (max-width: 767px) {
	.post-title {
		font-size: 1.7em;
		line-height: 30px;
	}
	.post-name {
		display: flex;
		gap: 14px;
	}
}

/* Item 5 (owner, this round): revert/override the hamburger icon's mobile top offset -
   see note above.
   REPLACED 2026-10-03 (owner direct request, verbatim CSS): top changed from -36px to
   36px, and `position: fixed` added so the icon stays pinned to the viewport (rather
   than the `.mob-mav`-relative `position: absolute` set in the Bug_6 block above) as
   the page scrolls on mobile. */
@media (max-width: 767px) {
	.button_container {
		top: 36px !important;
		position: fixed !important;
	}
}

/* Item 6 (owner, this round): revert/override the mobile logo's top offset - see note
   above. */
@media (max-width: 767px) {
	.header_block .site-logo {
		top: 0 !important;
	}
}

/* Item 7 (owner, this round): zero out the sub-menu list-item's own padding (desktop
   `.main-menu` dropdowns/mega-menu only - `.main-menu` is the desk-nav, not the mobile
   `.overlay-menu`). The link padding inside each row (`.main-menu ul.menu li .sub-menu
   li a{padding:8px 20px !important}`, set earlier for Bug_9/Bug_47) is unaffected since
   it targets the anchor, not the li - this only clears any padding on the <li> itself. */
.main-menu ul.sub-menu li {
	padding: 0 0 !important;
}

/* ===================================================================================
 * 2026-10-03 (owner direct request, evening round): two explicit items.
 * =================================================================================== */

/* Item 1 (owner, this round): on mobile, move the header logo into .top_bar and use a
   small dedicated mark (images/mob-logo.png) instead of the full wordmark logo shown
   in .logo-ani - then hide that old .logo-ani logo entirely on mobile, per the owner's
   explicit request ("do not use full logo in mobile", "remove old logo in mobile").
   `.top_bar_mob_logo` is new markup added in header.php, as a sibling of the existing
   `.top_bar .col-md-12` column (which holds the phone/email `.top_items` list) - hidden
   by default (desktop) here, and only shown/laid out at the mobile breakpoint below.
   `.logo-ani` (both `.site-logo.mob` and `.site-logo.logo-desk`) is hidden with
   `!important` so it wins over the Bug_6 `.logo-ani{display:flex}` rule earlier in this
   file; `.right-nav` is widened to fill the row once `.logo-ani`'s column is gone. */
.top_bar_mob_logo {
	display: none;
}
@media (max-width: 767px) {
	.top_bar .row {
		display: flex;
		align-items: center;
		flex-wrap: nowrap;
		gap: 10px;
	}
	/* UPDATED 2026-10-03 (owner direct request, later the same evening, verbatim CSS):
	   nudge the logo 10px right / 12px up from its default inline position. */
	.top_bar_mob_logo {
		display: block;
		flex: 0 0 auto;
		margin-left: 10px;
		margin-top: -12px;
	}
	/* UPDATED 2026-10-03 (owner direct request, verbatim CSS): height raised 24px -> 44px. */
	.top_bar_mob_logo img {
		display: block;
		height: 44px;
		width: auto;
	}
	.top_bar .col-md-12 {
		flex: 1 1 auto;
		min-width: 0;
	}
	.logo-ani {
		display: none !important;
	}
	.right-nav {
		flex: 0 0 100% !important;
		max-width: 100% !important;
		width: 100% !important;
	}
}

/* Item 2 (owner, this round): mobile hamburger overlay menu - increase the list's own
   top padding from 40px (Bug_8 above) to 70px. Owner's CSS added verbatim; placed last
   so it wins on source order (same selector, same specificity). */
@media (max-width: 767px) {
    .overlay ul {padding-top: 70px;}
}

/* ===================================================================================
 * 2026-10-03 (owner direct request, later the same evening): one more explicit item.
 * =================================================================================== */

/* Item (owner, this round): tighten the mobile header's own top padding - the theme's
   base `header{padding-top:20px}` rule (style.css) left more clearance above the
   top_bar/logo row than needed now that the mobile top_bar logo (added earlier this
   evening) sits inline with the phone/email list. Owner's CSS added verbatim. */
@media (max-width: 767px) {
	header {
		padding-top: 14px;
	}
}

/* Owner request 2026-10-05: "add class .current-menu-item to main menu if a sub-menu page
   is shown in the browser". pi_highlight_parent_menu_item() (inc/extra.php) now puts
   .current-menu-item on the top-level primary-menu item that contains the page being
   viewed. The theme's active-link rule (style.css: `nav ul li.current-menu-item a`) is a
   DESCENDANT selector, so in the mobile overlay it would also turn every link inside that
   item's dropdown blue instead of just the top-level label. Keep the dropdown links at
   their normal colour; a sub-item that is itself the current page still keeps the blue
   (it carries .current-menu-item, so it is excluded here), and hover colours are left alone. */
.overlay-menu ul.menu > li.current-menu-item ul.sub-menu li:not(.current-menu-item) > a:not(:hover) {
	color: #fff;
}

/* Owner request 2026-10-05: "add black color in that submenu also to know which submenu
   page is open". In the desktop dropdowns (About Us, and the Technologies flyouts) every
   link is white on the cyan panel, so nothing showed which sub-page is currently open
   (the theme's blue `li.current-menu-item a` is overridden by the white link colour
   above). Show the current page's own sub-menu link in black. `!important` because the
   white link rules for the plain dropdown and the mega-menu flyout are far more specific.
   Desktop only (`.main-menu`): the mobile overlay is dark, where black text would vanish,
   and there the current sub-item already shows in the theme's blue. */
.main-menu ul.menu li .sub-menu li.current-menu-item > a {
	color: #000 !important;
}

/* ===================================================================================
 * 2026-10-06 (owner direct request): two explicit items for the desktop Technologies
 * mega menu (`.main-menu`).
 * =================================================================================== */

/* Item 1 (owner, this round): uppercase the Technologies category rows ("Integration &
   Middleware", "Cloud Platforms", ...). Owner's CSS added verbatim; placed last so it wins
   on source order over the earlier `text-transform: none` on this same selector (same
   specificity). Item 2 (font-weight 300 -> 400 on the leaf links) was edited in place in
   the leaf-flyout rule above. */
.main-menu ul.menu li .sub-menu:has(> li.menu-item-has-children) > li > a {
	text-transform: uppercase;
}

/* ===================================================================================
 * 2026-10-06 (owner direct request, night round): `.logo-ani` (logo) and `.logo-text`
 * (tagline under it) should be vertically centered against `.top_items` (contact bar) and
 * `.right-nav` (main menu) together.
 * Desktop layout (>=993px, where `.top_items` and the desktop nav are shown): the logo + tagline
 * pair is ~73px tall and starts level with the nav row, i.e. it hangs below the middle of the
 * 81px band covered by `.top_items` + `.right-nav`. Both pieces are lifted by the same amount so
 * their combined block's centre lands on that band's centre (measured: 29px). A transform is used
 * so no layout box moves (header height unchanged) and the `top: 4px !important` on `.logo-text`
 * above is left alone.
 * =================================================================================== */
@media (min-width: 993px) {
	.header_block .logo-ani,
	.header_block .logo-text {
		transform: translateY(-29px);
	}
}

/* ===================================================================================
 * 2026-10-06 (owner direct request, later the same night): two explicit items.
 * =================================================================================== */

/* Item 1 (owner, this round): the tagline (`.logo-text`) only gets its own, larger lift
   (-35px), added verbatim and placed after the shared rule above so it wins on source
   order (same specificity: 0,2,0 vs 0,2,0 - and this one is not inside a media query, so
   it applies at every width; `.logo-ani` keeps the -29px from the shared rule). */
.header_block .logo-text {
	transform: translateY(-35px);
}

/* Item 2 (owner, this round): header top padding 30px -> 10px from 1200px up. The 30px
   comes from the theme's own style.css (`@media only screen and (min-width:1200px){
   header{padding-top:30px}}`), which is minified; rather than edit that file, the owner's
   rule is added here verbatim - same selector and specificity, and this stylesheet loads
   after style.css, so it wins on source order. */
@media only screen and (min-width: 1200px) {
	header {
		padding-top: 10px;
	}
}