. In a WordPress block theme an unknown
is treated as
ordinary constrained content — it took a 1265px column down to 645px and
halved every card inside it. `.tap-devwrap` removes that box from layout
so the wrapper can only ever do its one job.
display:none still wins in case 2: it applies to the box `contents` erases. */
.tap-devwrap{display:contents}
@media (max-width:1023.98px){ .tap-only-desktop{display:none !important} }
@media (min-width:1024px){ .tap-only-mobile{display:none !important} }
/* v7.6.0 REGRESSION FIX. The emoji sweep replaced the live indicator's red
circle emoji with an empty carrying only an
animation — and no rule ever gave that class a size, colour or shape, so the
"Live Seva Preparation" strip lost its indicator entirely. An emoji brings
its own glyph; a span brings nothing. Every emoji-to-element swap has to add
the box the glyph used to be.
Sized and coloured to match .tap-live-dot, the equivalent indicator
elsewhere in the product, rather than inventing a third look. */
.tap-pulse-dot{display:inline-block;flex:0 0 auto;width:8px;height:8px;border-radius:50%;
background:currentColor;box-shadow:0 0 0 3px color-mix(in srgb,currentColor 22%,transparent)}
@media (prefers-reduced-motion:reduce){ .tap-pulse-dot{animation:none !important} }
.tap-lay{display:grid;gap:14px}
.tap-lay-list{grid-template-columns:1fr}
.tap-lay-grid{grid-template-columns:1fr}
/* Carousel is a horizontal snap rail, matching the featured strip the homepage
already uses — not a JS slider. No dependency, works without script, and the
scrollbar is the affordance. */
.tap-lay-carousel{grid-auto-flow:column;grid-auto-columns:minmax(250px,78vw);
overflow-x:auto;scroll-snap-type:x mandatory;padding-bottom:14px}
.tap-lay-carousel>*{scroll-snap-align:start}
@media (min-width:768px){
.tap-lay-grid.tap-lay-c2,.tap-lay-grid.tap-lay-c3,.tap-lay-grid.tap-lay-c4{grid-template-columns:repeat(2,minmax(0,1fr))}
.tap-lay-carousel{grid-auto-columns:minmax(250px,300px)}
}
@media (min-width:1024px){
.tap-lay-grid.tap-lay-c3{grid-template-columns:repeat(3,minmax(0,1fr))}
.tap-lay-grid.tap-lay-c4{grid-template-columns:repeat(4,minmax(0,1fr))}
.tap-lay-carousel{grid-auto-flow:column;overflow-x:auto}
}
/* .tap-fcard ships `width:230px` — correct for the featured rail it was drawn
for, wrong in a grid cell, where it left a 230px card sitting in a 283px
track with a ragged gutter down the right of every row. Found by measuring
the rendered page, not by reading the CSS: the rule lives in tap-frontend.css
and nothing about the new markup hints at it. The track (or the row) owns the
width in every layout here. */
.tap-lay>.tap-fcard{width:100%;height:100%}
/* The shortcode can land inside a theme page with its own container, so it
never assumes full-bleed. */
.tap-svc-shortcode{padding:8px 0 4px}
.tap-svc-shortcode .tap-fcard{height:100%}
@media (prefers-reduced-motion:reduce){ .tap-lay-carousel{scroll-behavior:auto} }
/* ══ Responsive & compatibility pass (v7.6.1) ═════════════════════════════
Findings from an automated sweep at 375/480/768/1024/1280/1440 across the
home, catalogue and shortcode surfaces. Hit areas only — no visual redesign:
where a control is deliberately small, the TARGET grows and the paint does
not. */
/* ── Hero scrim: covered 198px of a 360px hero ────────────────────────────
`.tap-hero-compact` gained `display:grid; align-items:end` in v7.5.x for the
bottom-aligned body. That turned the pre-existing `:after` scrim into a grid
ITEM, and `align-items:end` beat its `bottom:0`, so the darkening gradient
stopped partway down and left a hard horizontal band across the hero — the
one visible in the reported screenshot. `place-self:stretch` puts it back
over the whole box. `align-self:stretch` alone is NOT enough (measured: still
198px); the height:auto is what releases the inset-derived size. */
.tap-home-root .tap-hero-compact:after{place-self:stretch;height:auto;width:auto}
/* ── Touch targets (WCAG 2.5.8 / 2.5.5) ──────────────────────────────────
Measured under 44px at one or more breakpoints. Chips take a real min-height,
matching `.tap-info-chip` which the detail page already holds at 44 — this is
alignment with the existing system, not a new decision. */
.tap-app .tap-festival-chip,
.tap-root .tap-festival-chip,
.tap-home-root .tap-festival-chip{min-height:44px;display:inline-flex;align-items:center;gap:6px}
.tap-app .tap-search-sug,
.tap-root .tap-search-sug,
.tap-home-root .tap-search-sug{min-height:44px;display:inline-flex;align-items:center}
/* Text actions ("See all ›", "View all"). The LABEL keeps its size; the row it
sits in grows to a thumb-sized target. */
.tap-root .tap-sec-action,
.tap-home-root .tap-sec-action,
.tap-root .tap-view-all,
.tap-home-root .tap-view-all,
.tap-root .tap-section-viewall{min-height:44px;display:inline-flex;align-items:center}
/* Icon buttons keep their drawn size and gain an invisible hit area, so the
card art is untouched while the thumb target reaches 44px. */
.tap-root .tap-fcard-heart,
.tap-home-root .tap-fcard-heart{position:absolute;isolation:isolate}
.tap-root .tap-fcard-heart:before,
.tap-home-root .tap-fcard-heart:before{content:"";position:absolute;top:50%;left:50%;
width:44px;height:44px;transform:translate(-50%,-50%);border-radius:50%}
.tap-root .tap-search-submit,
.tap-home-root .tap-search-submit{min-height:44px;min-width:44px}
/* 43px is not 44px. The card CTA sat one pixel under at three breakpoints. */
.tap-root .tap-fcard-cta,
.tap-home-root .tap-fcard-cta{min-height:44px}
/* ── iOS zoom floor ───────────────────────────────────────────────────────
Safari zooms the page when a focused field is under 16px, which on a booking
form reads as the layout breaking. The app already holds this inside modals;
this closes the remaining fields (hero search, filter inputs). */
.tap-root input,.tap-root select,.tap-root textarea,
.tap-home-root input,.tap-home-root select,.tap-home-root textarea{font-size:max(16px,1rem)}
/* ══ The plugin must never force horizontal scroll on a host theme ═════════
THE BUG: on a 375px viewport the page scrolled to 596px. Proven ours, not
the theme's — a plain page with no shortcode measured 375px clean, and
hiding the TAP root alone dropped 596 -> 375. Reproduced on both Twenty
Twenty-Five and Twenty Twenty-Three.
THE MECHANISM: `.tap-root` already carried `max-width:100%; overflow-x:clip`
(tap-adaptive). `clip` is not `hidden`. It suppresses PAINTING of the
overflow but does NOT make the element a scroll container, so the content's
min-content width still propagates outward — and a block theme sizing its
content wrapper to fit that intrinsic width grew to 596px, taking the whole
document with it. Every TAP element then measured "fine" relative to its
already-inflated parent, which is why per-element overflow checks found
nothing for several passes.
THE FIX: `contain:inline-size` states that the element's inline size does not
depend on its contents — already true, since max-width:100% governs it. The
intrinsic width can no longer leak to an ancestor. Measured against four
alternatives; it is the only one that worked:
contain:inline-size 596 -> 375 <-- this
min-width:0 596 -> 596
overflow-x:hidden 596 -> 596
width:100% 596 -> 596
Inline-size containment does NOT imply layout or paint containment, so
position:sticky headers and absolutely positioned children are unaffected.
Horizontal rails keep their own overflow-x:auto and still scroll. */
.tap-root,
.tap-home-root,
.tap-booking-root,
.tap-dashboard-root,
.tap-consult-root,
.tap-astrologer-panel-root{contain:inline-size}
/* Review stars are now per-review, so an unrated review shows none and a
4-star review shows four. The old markup printed five glyphs on every card
regardless of what anyone actually gave. */
.tap-root .tap-testi2-stars{display:inline-flex;gap:2px;line-height:1}
.tap-root .tap-star{color:var(--tap-a2z-line,#e0d6ec)}
.tap-root .tap-star.is-on{color:var(--tap-gold,#f99000)}
.tap-root .tap-testi2-src{margin-top:6px;font-size:.75rem;color:var(--tap-muted,#6b5b78)}
/* ══════════════════════════════════════════════════════════════════════════
MOBILE-FIRST FLUID LAYER (v7.6.1)
SCOPE, STATED HONESTLY. The component CSS in this product is 636 fixed-px
font-sizes and 453 fixed-px paddings across five stylesheets. Converting all
of them to fluid units would change how every screen looks at every
intermediate width — that is a redesign, and the brief for this work says
preserve the existing UI. So this layer does the part that is both safe and
genuinely missing:
- every clamp() MINIMUM is the value measured on a 375px phone today, so
mobile is pixel-identical and nothing regresses on the highest-priority
breakpoint;
- the maximum is the value the design already reaches at >=1280px, so the
desktop end is unchanged too;
- what changes is the MIDDLE — sizes now interpolate smoothly instead of
jumping at a media-query edge, and the two values that never scaled at
all (container gutter, section rhythm) now do.
Every ramp uses the accessible `rem + vw` form rather than raw vw. A pure-vw
font-size ignores the user's browser text-size setting entirely, which fails
WCAG 1.4.4; including a rem term keeps zoom working.
Measured endpoints this layer reproduces (375px -> 1280px):
hero h1 24 -> 34 (was a media-query step)
hero sub 14 -> 17 (was 14 flat at every width)
section title 22 -> 32 (was a step)
container pad 16 -> 32 (was 16 flat, phone gutters on a 1440 display)
section rhythm 48 -> 72 (was 48 flat)
══════════════════════════════════════════════════════════════════════════ */
.tap-root,.tap-home-root,.tap-booking-root,.tap-dashboard-root,.tap-consult-root{
/* One place to retune the scale. Consumed below; safe to override per-site. */
--tap-fluid-gutter : clamp(1rem, 0.59rem + 1.77vw, 2rem);
--tap-fluid-section: clamp(3rem, 2.38rem + 2.65vw, 4.5rem);
--tap-fluid-h1 : clamp(1.5rem, 1.24rem + 1.10vw, 2.125rem);
--tap-fluid-h2 : clamp(1.375rem, 1.12rem + 1.10vw, 2rem);
--tap-fluid-lead : clamp(0.875rem, 0.80rem + 0.33vw, 1.0625rem);
--tap-fluid-gap : clamp(0.75rem, 0.6rem + 0.66vw, 1.25rem);
}
/* Container: the gutter was 16px from a 320px phone to a 1440px monitor. */
.tap-root .tap-container,
.tap-home-root .tap-container{
padding-left:var(--tap-fluid-gutter);
padding-right:var(--tap-fluid-gutter);
width:100%;
box-sizing:border-box;
}
/* Vertical rhythm: 48px between sections reads as cramped past ~1024px. */
.tap-home-root .tap-home-section{
padding-top:var(--tap-fluid-section);
padding-bottom:var(--tap-fluid-section);
}
/* Type. Endpoints match today's design; only the interpolation is new. */
.tap-home-root .tap-hero-compact-title{font-size:var(--tap-fluid-h1);line-height:1.15}
.tap-home-root .tap-hero-compact-sub{font-size:var(--tap-fluid-lead);line-height:1.5}
.tap-root .tap-sec-title,
.tap-home-root .tap-sec-title{font-size:var(--tap-fluid-h2);line-height:1.2}
/* ── Responsive images ────────────────────────────────────────────────────
Only three `img{max-width:100%}` rules existed across the whole frontend, so
any image an operator uploads at its natural size could push a layout wider
than its column. This makes it universal inside the app roots and keeps the
aspect ratio. */
.tap-root img,.tap-root video,.tap-root svg:not(.tap-i),
.tap-home-root img,.tap-home-root video,
.tap-booking-root img,.tap-dashboard-root img,.tap-consult-root img{
max-width:100%;
height:auto;
}
/* An ![]()
with width/height attributes keeps its ratio while scaling. */
.tap-root img[width][height],.tap-home-root img[width][height]{height:auto}
/* ── Responsive tables ────────────────────────────────────────────────────
A table has an intrinsic minimum width and will happily push a phone layout
sideways. It scrolls inside its own box instead — the standard treatment,
and the only one that does not hide data. */
.tap-root table,.tap-dashboard-root table{width:100%;border-collapse:collapse}
.tap-root .tap-table-wrap,.tap-dashboard-root .tap-table-wrap{
overflow-x:auto;-webkit-overflow-scrolling:touch;max-width:100%;
}
/* ── Modals and sheets on a phone ─────────────────────────────────────────
dvh rather than vh so the mobile browser's collapsing address bar does not
leave the action button under the fold, plus the home-indicator inset. */
@supports (height:100dvh){
.tap-app .tap-modal,.tap-app .tap-bsheet{max-height:min(92dvh,calc(100dvh - 1rem))}
}
.tap-app .tap-bsheet,.tap-app .tap-sticky{padding-bottom:max(0px,env(safe-area-inset-bottom))}
/* ── Forms ────────────────────────────────────────────────────────────────
Fields fill their column and never exceed it, on every screen. */
.tap-root .tap-input,.tap-root input[type=text],.tap-root input[type=tel],
.tap-root input[type=email],.tap-root input[type=number],.tap-root select,
.tap-root textarea{width:100%;max-width:100%;box-sizing:border-box}
/* ── Long content must wrap, not stretch ──────────────────────────────────
A single unbroken string (a long temple name, a pasted URL) sets a grid
track's min-content width and can widen the whole row. */
.tap-root .tap-fcard-name,.tap-root .tap-testi2-quote,.tap-root .tap-sec-title,
.tap-home-root .tap-fcard-name,.tap-home-root .tap-testi2-quote{overflow-wrap:anywhere}
/* ══════════════════════════════════════════════════════════════════════════
FULL-WIDTH MOBILE — the wasted side gutters (v7.6.2)
REPORTED: dead space down both sides of every page on a phone.
ROOT CAUSE, measured on a 375px viewport (hero card was 255px — 32% of the
screen lost to stacked horizontal padding, 60px per side):
wp-site-blocks 375 pad 0 theme
entry-content 375 pad 30px THEME content padding
.tap-root 315 pad 14px OURS (tap-premium, <=767px)
.tap-container 287 pad 16px OURS (tap-frontend)
.tap-hero-compact 255 pad 20px card's own inner padding
So it is TWO faults, not one:
1. we apply a horizontal gutter at TWO nested levels — the root AND the
container — which double-pads every page that uses both;
2. we never opt out of the host theme's content padding, so the theme's
gutter is added on top of our two.
FIX
- the CONTAINER is the single owner of the horizontal gutter;
- the ROOT carries none, unless it has no container inside it (the SPA
roots render their own markup), in which case it takes the gutter itself
so nothing is left flush against the screen edge;
- the root negates the host theme's padding using the WordPress-standard
`--wp--style--root--padding-*` custom properties. Deliberately NOT the
`margin-inline: calc(50% - 50vw)` viewport trick: 100vw includes the
scrollbar, so on desktop that technique reintroduces the horizontal
scroll this codebase just spent a sprint removing. The custom properties
are scrollbar-safe and fall back to 0px on a theme that does not define
them, which is exactly today's behaviour — so a non-block theme is
unaffected rather than broken.
══════════════════════════════════════════════════════════════════════════ */
.tap-root,
.tap-home-root,
.tap-booking-root,
.tap-dashboard-root,
.tap-consult-root,
.tap-astrologer-panel-root{
padding-left:0;
padding-right:0;
/* margins handled by the corrected block below */
}
/* The one gutter. Fluid: 16px on a phone (unchanged) up to 32px on a desktop,
where 16px looked like a phone layout stretched wide. */
.tap-root .tap-container,
.tap-home-root .tap-container,
.tap-booking-root .tap-container,
.tap-dashboard-root .tap-container{
padding-left:var(--tap-fluid-gutter);
padding-right:var(--tap-fluid-gutter);
max-width:var(--tap-content-max, 1120px);
margin-left:auto;
margin-right:auto;
width:100%;
box-sizing:border-box;
}
/* A root that renders no .tap-container (the JS surfaces build their own
markup) still needs the gutter, or its content sits on the screen edge.
:has() is progressive: a browser without it keeps today's behaviour. */
@supports selector(:has(*)){
.tap-root:not(:has(.tap-container)),
.tap-booking-root:not(:has(.tap-container)),
.tap-dashboard-root:not(:has(.tap-container)),
.tap-consult-root:not(:has(.tap-container)),
.tap-astrologer-panel-root:not(:has(.tap-container)){
padding-left:var(--tap-fluid-gutter);
padding-right:var(--tap-fluid-gutter);
}
}
/* Without :has(), keep a gutter on the SPA roots specifically — they are the
ones that never contain a .tap-container. */
@supports not selector(:has(*)){
.tap-booking-root,.tap-dashboard-root,.tap-consult-root{
padding-left:var(--tap-fluid-gutter);
padding-right:var(--tap-fluid-gutter);
}
}
/* ── Full-bleed, corrected (v7.6.2b) ──────────────────────────────────────
The first attempt above zeroed our own double padding (60px -> 46px per
side) but the negative margins computed to 0 and the theme's gutter stayed.
Three separate reasons, each found by measuring rather than reasoning:
1. `calc(-1 * var(--x))` was dropped as invalid; `calc(0px - var(--x))`
is the portable form.
2. `max-width:100%` (tap-adaptive/phase2) caps the element at its
containing block, so a negative margin cannot widen it. Needs
`max-width:none`.
3. `contain:inline-size` — added earlier to stop content leaking width to
the theme — ALSO freezes the element against negative margins. It needs
an explicit `width` to have a definite size to contain.
With all three addressed the root spans the viewport, but bleeding into the
parent's padding made the PARENT scroll by exactly that padding (31px). The
theme's content wrapper therefore clips horizontally — `clip`, not `hidden`,
so it never becomes a scroll container and sticky/fixed children still work.
`:has()` scopes it to a wrapper that actually contains one of our roots, so
a theme's other pages are untouched.
Result at 375px: content 255px -> 343px, 68% -> 91% of the screen, 0 overflow. */
.tap-root,
.tap-home-root,
.tap-booking-root,
.tap-dashboard-root,
.tap-consult-root,
.tap-astrologer-panel-root{
box-sizing:border-box;
max-width:none;
width:calc(100% + var(--wp--style--root--padding-left, 0px) + var(--wp--style--root--padding-right, 0px));
/* !important is deliberate and load-bearing. Without it these lose to an
earlier layer of our OWN stylesheets and compute to 0 — measured: the
identical declaration applies with it and is dropped without it. */
margin-left:calc(0px - var(--wp--style--root--padding-left, 0px)) !important;
margin-right:calc(0px - var(--wp--style--root--padding-right, 0px)) !important;
}
@supports selector(:has(*)){
:where(.entry-content,.wp-block-post-content,.site-main,main,article,.content-area):has(> .tap-root),
:where(.entry-content,.wp-block-post-content,.site-main,main,article,.content-area):has(> .tap-home-root),
:where(.entry-content,.wp-block-post-content,.site-main,main,article,.content-area):has(> .tap-booking-root),
:where(.entry-content,.wp-block-post-content,.site-main,main,article,.content-area):has(> .tap-dashboard-root),
:where(.entry-content,.wp-block-post-content,.site-main,main,article,.content-area):has(> .tap-consult-root){
overflow-x:clip;
}
}
/* Desktop keeps its measured reading width — the CONTAINER caps and centres it
now that the root is full-bleed. Same result as the old root max-width, but
the full-bleed root lets a section paint edge to edge behind it. */
.tap-root .tap-container,
.tap-home-root .tap-container,
.tap-booking-root .tap-container,
.tap-dashboard-root .tap-container,
.tap-consult-root .tap-container{
max-width:var(--tap-content-max, 1120px);
margin-left:auto;
margin-right:auto;
}
/* ══════════════════════════════════════════════════════════════════════════
FLUID TYPE BASE (v7.6.3) — the one knob for 638 font-sizes
Every fixed-px font-size in the frontend stylesheets is now expressed as a
RATIO of this base: `font-size:14px` became
`font-size:calc(0.875 * var(--tap-fs))`. The whole type system therefore
scales together and keeps its hierarchy exactly — a 24px heading stays
exactly 1.714x a 14px body at every viewport.
THE BASE IS ON OUR ROOTS, NOT ON `html`.
Setting `html{font-size:clamp(...)}` is the usual recipe and it is the wrong
choice for a plugin: it rescales the HOST THEME's typography too, on a site
that is not ours. Scoping the base to the app roots means nothing outside
DIVSA changes.
THE RANGE: 16px at 375px -> 18px at 1440px (+12.5%).
Deliberately modest. Before this, body copy, buttons, chips and labels were
the SAME pixel size on a 375px phone and a 1440px monitor — measured, not
assumed — so the app read as a phone layout stretched wide. 12.5% is enough
to fix that without re-proportioning the design.
The 375px end is unchanged, so the mobile layout that was just verified
stays pixel-identical.
The `rem` term keeps browser text-size settings working (a pure-vw ramp
ignores them and fails WCAG 1.4.4). --tap-fs-max lets an operator or a
future site retune the top of the range without touching any component.
══════════════════════════════════════════════════════════════════════════ */
.tap-root,
.tap-home-root,
.tap-booking-root,
.tap-dashboard-root,
.tap-consult-root,
.tap-astrologer-panel-root,
.tap-app .tap-modal,
.tap-app .tap-bsheet,
.tap-app .tap-toast,
.tap-bottom-nav,
.tap-bn,
.tap-topnav,
.tap-site-footer{
--tap-fs: clamp(1rem, 0.957rem + 0.188vw, var(--tap-fs-max, 1.125rem));
}
/* Fixed-height boxes that contain text must be able to grow with it, or the
type conversion turns them into clipping boxes. Height becomes a floor. */
.tap-root .tap-btn,
.tap-root .tap-btn-sm,
.tap-root .tap-chip,
.tap-root .tap-tab,
.tap-home-root .tap-btn{min-height:44px;height:auto}
/* v7.6.3 REGRESSION FIX from the fluid-type conversion.
`.tap-chad-step` (the chadhava quantity stepper) is a fixed 36px box with
overflow:hidden. Once its digits scaled with --tap-fs the content grew past
36px and was clipped. Height becomes a floor rather than a ceiling — the
same treatment already applied to buttons and chips. Caught by the clipping
scan, not by eye. */
.tap-root .tap-chad-step,
.tap-a2z-chadhava .tap-chad-step{height:auto;min-height:40px;overflow:visible}
.tap-root .tap-chad-step button,
.tap-a2z-chadhava .tap-chad-step button{height:auto;min-height:40px;line-height:1}
.tap-root .tap-chad-qty{line-height:1.1}
/* ===== END assets/css/tap-a2z.css ===== */
/* ===== BEGIN assets/css/tap-shell.css ===== */
/**
* Canonical application shell width contract.
*
* This is a source module consumed by assets/css/tap-app.css. It is not
* enqueued separately. Width ownership belongs to .tap-app-shell; component
* roots are JS mount points and may no longer decide the page canvas.
*/
.tap-app-shell {
--tap-shell-gutter: clamp(12px, 2vw, 24px);
box-sizing: border-box;
display: block;
inline-size: 100%;
max-inline-size: 100%;
min-inline-size: 0;
margin-inline: 0;
}
/* One invariant override replaces the historic 720/1160/1280 root rules. */
.tap-app .tap-app-shell > .tap-root,
.tap-app .tap-app-shell > .tap-home-root,
.tap-app .tap-app-shell > .tap-booking-root,
.tap-app .tap-app-shell > .tap-dashboard-root,
.tap-app .tap-app-shell > .tap-consult-root,
.tap-app .tap-app-shell > .tap-astrologer-panel-root {
box-sizing: border-box;
inline-size: 100% !important;
max-inline-size: none !important;
margin-inline: 0 !important;
min-inline-size: 0;
}
/* Embedded mode: Elementor, Gutenberg or the active theme owns the container. */
.tap-app-shell--host {
inline-size: 100%;
max-inline-size: 100%;
margin-inline: 0;
}
/* Contained mode: an explicit centred measure, never a left-aligned half page. */
.tap-app-shell--contained {
inline-size: min(
var(--tap-content-max, 1160px),
calc(100% - (2 * var(--tap-shell-gutter)))
);
max-inline-size: calc(100% - (2 * var(--tap-shell-gutter)));
margin-inline: auto;
}
/* Full mode inside the plugin canvas uses all available canvas width. */
.tap-app-shell--full {
inline-size: 100%;
max-inline-size: none;
margin-inline: 0;
}
/* Explicit full-bleed breakout for a TAP-owned site embedded in a narrow theme
wrapper. This is deterministic mode selection, not viewport guessing. */
body:not(.tap-canvas) .tap-app-shell--full {
inline-size: 100vw;
max-inline-size: 100vw;
margin-inline: calc(50% - 50vw);
}
@supports (width: 100dvw) {
body:not(.tap-canvas) .tap-app-shell--full {
inline-size: 100dvw;
max-inline-size: 100dvw;
margin-inline: calc(50% - 50dvw);
}
}
body.tap-width-full {
overflow-x: clip;
}
@media (max-width: 359px) {
.tap-app-shell { --tap-shell-gutter: 8px; }
}
/* ── Reading measure (v7.7.3) ───────────────────────────────────────────────
.tap-app-shell owns the CANVAS width. Nothing owned the READING width, and
that gap is the "left-heavy / blank right side" report.
Measured on /book/?puja=3933 at a 1521px viewport BEFORE this rule:
.tap-progress-bar 1437px
.tap-vh (hero) 1437px
.tap-section x4 840px <- pinned LEFT, ~600px dead to the right
.tap-notice-warn 1437px
.tap-sticky 1489px
Five blocks, four widths, one of them left-aligned.
Cause: the v5.0.1 desktop layer caps `.tap-booking-root > .tap-section` at
840px WITH `margin-inline:auto`, but tap-premium.css then declared
`.tap-root .tap-section{margin:26px 0}`. Equal specificity (0,2,0) and later
in the concat order, so the shorthand re-zeroed the inline margins and the
cap survived without its centring. Handing width ownership to .tap-app-shell
in v7.7.2 neutralised the ROOT rules but never retired that SECTION cap, so
the canvas went edge-to-edge while the sections stayed 840px hard left.
The shorthand is fixed at source; this establishes the single measure.
Applies to every top-level block, so progress bar, hero, sections, notices
and the pay bar share ONE column in all three shell modes.
Inert below the measure: max-inline-size exceeds the viewport and there is
no free space for auto margins to distribute, so phone layout is unchanged. */
.tap-app-shell > .tap-root > *:not(.tap-sticky),
.tap-app-shell > .tap-home-root > *:not(.tap-sticky),
.tap-app-shell > .tap-booking-root > *:not(.tap-sticky),
.tap-app-shell > .tap-dashboard-root > *:not(.tap-sticky),
.tap-app-shell > .tap-consult-root > *:not(.tap-sticky) {
max-inline-size: var(--tap-content-max, 1160px);
/* !important is load-bearing, for the same reason the v7.6.2b full-bleed
block needs it: `.tap-root *{margin:0}` wins over this selector in
practice even though this one is more specific. MEASURED on the live page,
not reasoned about — without !important getComputedStyle().marginLeft is
`0px` and the block stays hard left; with it the same block reports
`138.4px` and centres. max-inline-size applied correctly either way, which
is what made the failure look like a centring bug rather than a cascade
one. Do not "clean this up" without re-measuring. */
margin-inline: auto !important;
}
/* ── Catalogue surfaces take the canvas (v7.7.4) ───────────────────────────
A LISTING is a grid, not prose. Capping the home/services catalogue at the
reading measure left ~170px dead on each side of a 1501px canvas, which is
the "home page listing is not full width" report. Detail surfaces are prose
plus a form and keep the measure; catalogue surfaces take the whole canvas.
This distinction is exactly what the three shell modes were meant to
express, but `TAP_Layout::shell_mode()` resolves ONE mode for the entire
site (option `container_mode`, default auto -> host/full), so every surface
on a given site gets the same answer. `TAP_App_Shell::wrap()` already emits
a per-surface class and nothing consumed it — this does.
MEASURED on the live home page: .tap-container 1160px -> 1501px, zero
horizontal scroll. !important for the same cascade reason documented above. */
.tap-app-shell--surface-home > .tap-root > *:not(.tap-sticky),
.tap-app-shell--surface-services > .tap-root > *:not(.tap-sticky) {
max-inline-size: none !important;
}
.tap-app-shell--surface-home .tap-container,
.tap-app-shell--surface-services .tap-container {
/* The a2z layer caps this with the PHYSICAL `max-width`; overriding only the
logical property would leave the physical one in force. Set both. */
max-width: none !important;
max-inline-size: none !important;
}
/* ── Stacked mobile gutters (v7.7.5) ──────────────────────────────────────
MEASURED on live at a real 375px viewport (device emulation, not a resized
window — window resizing never changed the viewport and produced false
"all clear" readings before):
375 .elementor-widget-wrap padding 10/10 <- the HOST's gutter
355 .tap-app-shell padding 0
355 .tap-root padding 0
355 .tap-container padding 15.25 <- OURS, a SECOND gutter
325 .tap-fcard padding 14 <- card inner (legitimate)
295 content = 79% of the screen
`.tap-root .tap-container{padding:var(--tap-fluid-gutter)}` assumes it is
the only gutter. Embedded in Elementor/a theme it is the second one, so the
phone lost 30px of card width to padding nobody asked for — this is the same
stacked-gutter defect as v7.6.2, in a different element.
The shell already owns the outer gutter, so inside a shell the container
only needs enough inset to keep cards off a hard edge when the host supplies
none. 6px measured: card L25->L16, art 295->314px.
Deliberately NOT zero: on a host with no padding of its own, zero would put
card borders flush against the screen edge. */
@media (max-width: 767px) {
.tap-app-shell .tap-container {
padding-inline: 6px;
}
}
/* ── Card image fills the card (v7.7.6) ───────────────────────────────────
The card carried its inset on the CARD, so the image sat inside that inset
with a visible border of card background on all sides. Measured at 375px:
card 325px wide, image only 295px.
The inset moves to the text body. The image then spans the full card and,
because .tap-fcard already has overflow:hidden and a radius, it clips to the
rounded corners instead of needing its own.
No calc() negative margin is used: `calc(-1 * var(--x))` is dropped as
invalid (v7.6.2 measured this), and pulling the image out with a negative
margin would also fight the card's overflow. Removing the padding is the
change that actually holds. */
.tap-root .tap-fcard,
.tap-home-root .tap-fcard {
/* !important, MEASURED: `.tap-root .tap-fcard{padding:var(--tap-card-pad,14px)}`
ties on specificity (0,2,0) and wins. Without !important this rule applied
and changed nothing — art stayed L15 W295. With it: L1 W323 in a 325px
card. Third place in this codebase where that is true; do not remove it
without re-measuring. */
padding-inline: 0 !important;
}
.tap-root .tap-fcard > .tap-fcard-art,
.tap-home-root .tap-fcard > .tap-fcard-art {
width: 100%;
display: block;
}
.tap-root .tap-fcard > .tap-fcard-body,
.tap-home-root .tap-fcard > .tap-fcard-body {
/* The inset the card just gave up — text still needs it, the image does not. */
padding-inline: var(--tap-card-pad-s, 14px) !important;
}
/* ── Bottom sheet becomes a dialog on laptops (v7.7.6) ────────────────────
MEASURED at 1440x900 with the package sheet open:
.tap-sheet-ov L0 W1440 (backdrop — correct, it should cover)
.tap-bsheet L32 W1376 <- the PANEL, 96% of the screen
.tap-bsheet-hd / -body / CTA all stretched to 1340px
A bottom sheet is a phone idiom: it is full-width because a phone IS the
sheet's width. On a laptop the same rule produced a 1376px-wide panel
holding one title, one note and one button — the "sheet is covering the
whole page" report.
`.tap-cst-sheet` already solved this for the consult flow with
`max-width:560px`; this brings the booking sheet to the same contract:
centred dialog above 768px, untouched bottom sheet below it.
After: panel L440 W560, vertically centred, backdrop still full-screen. */
@media (min-width: 768px) {
.tap-sheet-ov {
align-items: center;
padding: 24px;
}
.tap-bsheet {
max-width: 560px;
margin-inline: auto;
/* Bottom sheets round only their top corners because the bottom edge is
off-screen. A centred dialog has four visible corners. */
border-radius: 22px;
}
}
/* The pay bar is position:fixed — docked, not in flow — so it keeps its own
width and aligns its CONTENT to the same measure instead. */
.tap-root .tap-sticky > .tap-sticky-inner {
max-inline-size: var(--tap-content-max, 1160px);
margin-inline: auto;
}
/* ── Floating-launcher collision (v7.7.3) ──────────────────────────────────
The pay bar docks at z-index 500; the WhatsApp launcher (Join.chat) sits at
z-index 9000 and is bottom-right. Measured: the two rects intersect at every
width, so a chat button covered the primary checkout CTA. Dock the bar above
the launcher and lift the launcher clear of the bar's height. */
.tap-root .tap-sticky {
z-index: 9100;
}
@supports selector(:has(*)) {
body:has(.tap-root .tap-sticky) .joinchat {
bottom: calc(var(--tap-sticky-h, 72px) + 16px);
}
}
/* ===== END assets/css/tap-shell.css ===== */