/* ==========================================================================
Homepage - hero carousel, panels, icons (Point A/A-RATIO, E, J)
==========================================================================
Migrated out of the Customizer's "Additional CSS" field, which lives only in
the database: not in git, not deployed by pushing code, and installed only by
running a per-feature script on each target. That is why five unrelated
features silently reverted on www.mmspecs.com - the PHP that depends on this
CSS shipped, and the CSS did not. See CLAUDE.md, "Site CSS lives in git".
Edit these files, commit, push. There is no install step.
========================================================================== */
/* Point E - the two panel images (private-listening 790x375, focus-efficiency
790x404) have different natural heights (baked into the source graphics,
confirmed not a splitting error). Fix found by testing directly in Chrome
DevTools: padding-bottom:15px on the shorter image, margin-top:25px on the
taller one, visually balances them without touching width/height/cropping.
Scoped to desktop only - applying this unscoped also affected mobile
stacking, adding an oversized gap between the two stacked images there. */
@media (min-width: 768px) {
.elementor-element-f9030d0 img {
padding-bottom: 15px !important;
}
.elementor-element-ef0ffff img {
margin-top: 25px !important;
}
}
/* Point J "Free Shipping"/"Secure payments" icons weren't centered above
their titles - the icon ![]()
renders at its natural 100px width
inside a wider figure box with display:block and no auto margins, so
it sits flush-left instead of centering under the text. */
.elementor-element-9149837 .elementor-image-box-img img {
margin-left: auto;
margin-right: auto;
}
/* Point A - hero slider prev/next arrows are nearly invisible on
mobile against a dark/busy part of a given slide's image (default
gallery-widget layout absolute-positions them over the image itself,
confirmed unreadable on the Maverick slide).
First attempt moved the arrows in the DOM (JS, via wp_footer) into a
row next to the dots - reverted, it caused a real bug: Slick rebuilds
its own .slick-dots element on every resize event (a normal part of
its responsive behavior), which wiped the "already moved" marker the
JS relied on, so it kept re-running and stacking up duplicate wrapper
rows - confirmed reproducible by resizing across the mobile
breakpoint a few times (each resize added another wrapper, visibly
inflating the dot count - 5 real slides showing 6, 7, 8+ dots).
Fixed with pure CSS instead, no DOM changes at all: Slick already
positions .slick-dots at a fixed spot below the image
(position:absolute; bottom:-45px, relative to .uael-img-carousel-wrap
which is itself position:relative) - matching the arrows to that
same position/offset puts them at the same visual row as the dots
without ever touching the DOM, so there's nothing for Slick's own
resize-driven rebuild to conflict with. */
@media (max-width: 767px) {
.elementor-element-mm5s1de .slick-prev,
.elementor-element-mm5s1de .slick-next {
top: auto;
bottom: -56px;
transform: translateY(-50%);
width: 32px;
height: 32px;
border-radius: 50%;
background: #fff;
border: 1px solid rgba(0, 0, 0, 0.15);
box-shadow: 0 2px 6px rgba(0, 0, 0, 0.12);
z-index: 2;
}
.elementor-element-mm5s1de .slick-prev {
left: 30%;
}
.elementor-element-mm5s1de .slick-next {
right: 30%;
}
.elementor-element-mm5s1de .slick-prev::before,
.elementor-element-mm5s1de .slick-next::before {
font-size: 18px;
opacity: 1;
color: #222;
}
}
/* Point A - desktop/tablet hero slider arrows invisible after the
slider became full width. Root cause (confirmed by reading UAEL's
own source CSS): the widget's "outside" arrow layout positions
.slick-prev/.slick-next at left:-25px / right:-25px by default -
this only worked while the slider was boxed with margin on either
side (the -25px landed within that margin, still on-page). Now that
the container is edge-to-edge (content_width:full, see above),
-25px pushes the arrows past the actual browser viewport edge,
making them inaccessible/invisible. Repositioned onto the visible
image (left:20px/right:20px) with the same white-circle styling as
the mobile arrows, for the same reason mobile needed it: the
default bare chevron icon (no background, low opacity) isn't
reliably visible against every slide's photo. left/right need
!important - confirmed via computed-style inspection that UAEL's
own "-25px" rule was still winning despite this rule having more
classes in its selector, so something in UAEL's own CSS must have
equal-or-higher specificity than expected (same category of issue
as the opacity fix above - a plugin's own generated CSS beating a
theme customization's normal specificity). */
@media (min-width: 768px) {
.elementor-element-mm5s1de .slick-prev,
.elementor-element-mm5s1de .slick-next {
width: 44px;
height: 44px;
border-radius: 50%;
background: #fff;
border: 1px solid rgba(0, 0, 0, 0.15);
box-shadow: 0 2px 6px rgba(0, 0, 0, 0.12);
z-index: 2;
}
.elementor-element-mm5s1de .slick-prev {
left: 20px !important;
}
.elementor-element-mm5s1de .slick-next {
right: 20px !important;
left: auto !important;
}
.elementor-element-mm5s1de .slick-prev::before,
.elementor-element-mm5s1de .slick-next::before {
font-size: 22px;
opacity: 1;
color: #222;
}
}
/* Point A-RATIO - homepage hero carousel: frame the slider to the ARTWORK
instead of to a fixed pixel height.
Root cause this replaces. The previous block (point A.4) pinned the image
to height:800px with object-fit:cover, while every desktop source is
2.167:1 (2600x1200 and 1846x852). A fixed height against a fixed source
ratio cannot both hold, so the browser crops - and the crop CHANGES AXIS
with viewport width:
1366px 1733x800 rendered -> 367px (21%) lost HORIZONTALLY
1440px 1733x800 -> 293px (16%) lost horizontally
1920px 1920x886 -> 86px (9%) lost vertically
2560px 2560x1181 -> 381px (32%) lost vertically
That is the "shrinking crop window" the earlier comments describe, and why
object-position was hand-tuned across four rounds - each round solves one
viewport width and breaks at another. It is not fixable by tuning anchors;
the frame has to match the artwork.
Tablet had NO rule at all before this block. The old CSS only ever used
max-width:767px and min-width:768px, so a 768px tablet inherited the
desktop 800px height and showed roughly the middle 44% of every image.
The frame shape is NOT hardcoded here. mm-dynamic-product-card.php
measures each slide's real attachment - and its real tablet/mobile variant
attachment, where one is set - and writes the true ratios onto the ![]()
as --mm-ar-desktop / --mm-ar-tablet / --mm-ar-mobile. Baking a spec ratio
into this stylesheet would repeat the original mistake one level up: a
slide with no tablet artwork yet would be squeezed into a 16:9 frame it
was never cut for (confirmed - it clipped the M off "MAVERICK"). Reading
the measured value means no slide is ever cropped, whatever is uploaded,
and the heights converge on their own as the per-breakpoint assets land.
The literals below are only fallbacks, used if this CSS is ever installed
somewhere the mu-plugin is not: 13/6 is the desktop artwork ratio. */
.elementor-element-mm5s1de .uael-grid-img-thumbnail img {
width: 100%;
height: auto !important;
aspect-ratio: var(--mm-ar-desktop, 13 / 6);
max-height: 860px;
object-fit: cover;
}
/* Tablet and mobile fall back to the desktop ratio - NOT to a fixed
breakpoint shape - so a slide without art-directed artwork simply renders
its desktop photo uncropped rather than being cropped into a frame it does
not fit.
The asset-spec ratios (16:9 tablet, 4:5 mobile) appear here ONLY as a
max-height ceiling, never as a forced aspect-ratio. That distinction is
the point: a ceiling leaves conforming artwork completely untouched, and
only reins in an outlier that would otherwise dominate the page. Concrete
case this exists for - slide 4 still holds a 1200x1200 square placeholder
(see the asset request in the README), which without a ceiling renders
984px tall at a 1024px tablet while its neighbours are 454px, making the
carousel lurch on every rotation. */
@media (min-width: 768px) and (max-width: 1024px) {
.elementor-element-mm5s1de .uael-grid-img-thumbnail img {
aspect-ratio: var(--mm-ar-tablet, var(--mm-ar-desktop, 13 / 6));
max-height: calc(100vw * 9 / 16); /* 16:9 - the tablet asset spec */
}
}
@media (max-width: 767px) {
.elementor-element-mm5s1de .uael-grid-img-thumbnail img {
aspect-ratio: var(--mm-ar-mobile, var(--mm-ar-desktop, 13 / 6));
max-height: calc(100vw * 5 / 4); /* 4:5 - the mobile asset spec */
}
}
/* The cap keeps the hero from becoming absurdly tall on a large monitor: a
true-to-ratio full-bleed 2.167 hero is 1181px tall at 2560px wide. At
860px there is zero crop up to a 1863px viewport - every real laptop and
most monitors - and a gentle centred cover crop beyond it, versus 32%
today.
height:auto is !important only to beat the earlier point A.4 block, which
is deliberately left in place - CLAUDE.md: Additional CSS here is
append-only, after a marker-bounded replace once silently wiped 7
unrelated blocks on dev.
Retire the four hand-tuned per-slide crop anchors (items 1, 2, 3 and 5).
With the frame matching the artwork there is nothing to anchor below the
cap, and above it a centred crop is correct for all five slides. The
attribute selector is not decorative: it matches the old rules'
specificity exactly - (0,3,1) for
`.elementor-element-mm5s1de .uael-img-gallery-item-N .uael-grid-img-thumbnail img`
- so later-in-source wins. A plainer two-class selector would LOSE. */
.elementor-element-mm5s1de [class*="uael-img-gallery-item-"] .uael-grid-img-thumbnail img {
object-position: center center;
}