/* zChevraKadisha — sitewide styling.
   Palette rev 2 (2026-08-17): moved off the original logo-sampled dark
   green/tan scheme to a lighter white/light-blue/grey palette, per the
   user's explicit direction ("colors are not comfortable and relaxing...
   I tend towards white, light blue, grey") — plus a capped, centered
   content column so text reads as a comfortable block instead of
   stretching edge-to-edge on wide screens (matching the concentrated
   layout of the org's old municipality page, used as the visual
   reference). Doing this page-by-page, starting with Home — the OLD
   green/tan/brown tokens below are KEPT AS-IS because they're still
   load-bearing for pages not yet restyled (.ck-result-table on Search,
   .ck-grid-table + .zGrave-* status colors on the admin cemetery map). */

:root {
    /* ── Old palette — untouched, still used by Search's result table and
       the admin cemetery-map status colors. Do not repurpose these for
       new chrome; add new tokens instead (below) and restyle those
       specific pages in their own pass. ── */
    --ck-green: #324e3d;
    --ck-green-dark: #22362a;
    --ck-tan: #f0dfaa;
    --ck-tan-light: #faf3e2;
    --ck-brown: #9c4f26;

    /* ── New light palette — white / light blue / grey ── */
    --page-bg: #ffffff;
    --text: #3d4854;
    --color-primary: #3a7ca5;

    --ck-blue: #3a7ca5;
    --ck-blue-dark: #2c5f80;
    --ck-blue-pale: #eaf3f9;
    --ck-grey-light: #e2e7ec;
    --ck-grey-mid: #7c8894;
    --ck-surface: #f6f9fb;

    /* zbase.css's own form-field tokens default to a dark, opaque
       "--surface-field" card (#26263a, near-white text) — same
       deliberately-dark-regardless-of-page-theme design as zTable's own
       default. Re-skinned via the SAME documented token mechanism (these
       exact var names are read with a fallback to that dark default
       throughout zbase.css's input rules) so every text field sitewide —
       not just Search's — reads as a light field matching the rest of
       the page, with zero per-field CSS needed. */
    --zinput-bg: #ffffff;
    --zinput-bg-focus: var(--ck-blue-pale);
    --zinput-color: var(--text);
    --zinput-border: var(--ck-grey-light);
    --zinput-placeholder: var(--ck-grey-mid);
}

body {
    background: var(--page-bg);
    color: var(--text);
    line-height: 1.7;
}

/* ── Content column — capped + centered so text reads as a comfortable
   block instead of stretching full window width. .zVaF-content is the
   framework's own content host and a SIBLING of <zNavBar> (confirmed via
   the live DOM), so this never touches the navbar's own full-bleed
   layout. ── */
.zVaF-content {
    max-width: 760px;
    margin-inline: auto;
    padding-inline: 1.25rem;
}

/* The 760px article-reading cap above was applied sitewide during the
   styling pass and ended up squeezing the admin cemetery-map GRID (a wide
   real <table>, not prose) into a narrow scrolling box that read as "a
   small window" compared to before that pass — same :has() escape-hatch
   technique already used below for .zTable-container. */
.zVaF-content:has(.ck-grid-table) {
    max-width: 100%;
}

/* ── Navbar — re-skinned via zbase.css's own --znav-* token SSOT (its own
   comment: "Apps re-skin via --znav-* vars... no need to re-declare the
   bar") instead of the previous !important overrides on .zNavbar/.zNav-
   link. A soft blue-tinted bar reads as a distinct header without the
   old scheme's heavy dark green. ── */
/* zbase.css's OWN `.zNavbar` rule redeclares --znav-* locally (its own
   comment: "tokens — the single source of truth"), so setting them on the
   ancestor <zNavBar> tag alone is silently shadowed — confirmed via
   getComputedStyle (the outer tag held the right value, the inner
   .zNavbar still showed zbase's own default). Redeclaring on the SAME
   `.zNavbar` selector, loaded after zbase.css, is what actually wins. */
.zNavbar {
    --znav-bg: var(--ck-blue-pale);
    --znav-border: var(--ck-grey-light);
    --znav-brand-color: var(--ck-blue-dark);
    --znav-link-color: var(--ck-grey-mid);
    --znav-link-hover-color: var(--ck-blue-dark);
    --znav-link-hover-bg: var(--ck-blue-pale);
    --znav-link-active-bg: var(--ck-blue-pale);
}

/* 2026-08-18: a 2-line brand label + bigger logo was tried (and its
   knock-on instability chased through 3 further attempts — a width-
   capped natural wrap, a forced-break Unicode character that turned out
   to truncate the text [feedback #24], then an image-above-text column
   that broke the navbar row's own layout) — all of it downstream of the
   same already-known, not-app-fixable bug (feedback #16: the brand
   silently reverts to a plain fallback, no logo, on every SPA
   navigation). Every fix for the WRAPPING wobble either introduced a
   worse problem or left a residual instability, so reverted the whole
   2-line experiment back to this simpler, originally-approved version:
   one line, no wrap, no forced height — nothing to destabilize, since
   there's nothing here that depends on the logo's width or height. Bug
   #16 itself is unchanged (still not fixable from app code either way,
   already accepted as a known low-priority gap). */
.zNavbar-brand {
    display: flex;
    align-items: center;
    gap: 0.6em;
}

/* zbase.css's own .zNavbar carries backdrop-filter:blur(16px) saturate(1.4)
   for a frosted-glass look on the sticky bar — with a fully opaque
   --znav-bg (above) that blur has no visual purpose, and on this sticky +
   fast-scroll combination it left a smeared ghost trail during scroll
   (confirmed via getBoundingClientRect: no duplicate DOM node, a single
   real <zNavBar>/<nav> — a compositing artifact, not a content bug).
   A plain solid bar is what we want anyway; drop the blur outright. */
.zNavbar {
    -webkit-backdrop-filter: none !important;
    backdrop-filter: none !important;
}

.zNavbar-brand-logo {
    height: 68px !important;
    width: auto !important;
    border-radius: 4px;
}

/* A frame around each nav link, per direct request, bumped up a second
   time to be genuinely noticeable — a white "chip" with a solid mid-grey
   border reads clearly against the pale-blue bar, not just a faint line. */
.zNavbar .zNav-link {
    border: 1.5px solid var(--ck-grey-mid);
    border-radius: 8px;
    background: #ffffff;
}

/* First nav item (right-most in RTL — "מדריך מקוצר" per the requested
   order) stands out clearly from the rest, not just slightly bolder —
   a solid blue fill (matching the site's own accent color) makes it read
   as the lead item at a glance, not just on close inspection. */
.zNavbar .zNav-item:first-child .zNav-link {
    font-weight: 700;
    background: var(--ck-blue) !important;
    color: #ffffff !important;
    border-color: var(--ck-blue-dark);
}

.zNavbar .zNav-item:first-child .zNav-link:hover {
    background: var(--ck-blue-dark) !important;
    color: #ffffff !important;
}

/* ── Headings ── */
h1 {
    color: var(--ck-blue-dark);
}

h2 {
    color: var(--ck-blue);
}

/* ── Content readability ── */
.ck-link {
    display: block;
    clear: both;
    margin: 0.4em 0;
    color: var(--ck-blue);
}

/* FAQ's questions are the one place `.ck-link` lands on a real zBtn
   (every other page puts it on a zURL, a plain <a> with no background of
   its own) — zBtn-primary's own default background is the SAME blue as
   `.ck-link`'s text color, so the question text was rendering invisible
   (blue-on-blue). Light/bordered override, same look as .ck-search-input
   and .ck-table, so each question reads as its own clickable row. */
.zBtn.ck-link {
    width: 100%;
    max-width: 100%;
    background: #ffffff !important;
    border: 1px solid var(--ck-blue) !important;
    color: var(--ck-blue) !important;
    text-align: right;
    white-space: normal;
}

table {
    border-collapse: collapse;
}

/* ── A light, airy table for public-facing data (contact info, hours,
   etc.) — zTable's own zbase.css default is a deliberately DARK card
   (matches zTerminal, independent of page theme); opt any zTable into
   this look via `_zClass: ck-table`. Cell text-align switched from
   zbase's literal `left` to `right` (physical, not `direction`-relative)
   to match Hebrew reading direction — RTL content pinned to a physical
   left edge read oddly on the unstyled default. ── */
.ck-table {
    width: auto !important;
    max-width: 100%;
    border-collapse: collapse;
    font-size: 0.95rem;
    box-shadow: none !important;
}

.ck-table thead th,
.ck-table tbody td {
    text-align: right !important;
}

.ck-table thead th {
    background: var(--ck-blue-pale) !important;
    color: var(--ck-blue-dark) !important;
    font-weight: 700;
    border-bottom: 1px solid var(--ck-grey-light) !important;
}

.ck-table tbody td {
    background: #ffffff !important;
    color: var(--text) !important;
    border-bottom: 1px solid var(--ck-grey-light) !important;
}

.ck-table tbody tr:nth-child(even) td {
    background: var(--ck-surface) !important;
}

/* ── Home page: "שעות פעילות" (hours) sits to the LEFT of "אנשי קשר"
   (contact table) on wide screens — better use of the space than stacking
   them, per direct request. Zolo's page events are a plain top-to-bottom
   list (no built-in "columns" option — checked the reference docs first),
   so this is a CSS float: the contact table floats to its natural RTL
   side (right) and the hours heading+list, being plain block content
   right after it in source, wrap into the remaining space beside it —
   no extra wrapper element needed. The float pair is now the LAST thing
   on the page (the "חפש קרוב משפחה" CTA moved above it, see zUI), so
   nothing needs an explicit `clear: both` of its own anymore — instead
   `.zVaF-content` gets a plain clearfix (below) so it always properly
   contains a trailing float, on this page or any future one.
   Turned off below ~600px — a floated table doesn't have room to share a
   row on a phone-width screen, so it drops back to plain stacked order. ── */
.zTable-container:has(.ck-table) {
    float: right;
    margin-left: 2rem;
    margin-bottom: 1.5rem;
}

.zVaF-content::after {
    content: "";
    display: table;
    clear: both;
}

/* zTable's own `title:` (here, "אנשי קשר") renders as an h4 sized/colored
   by zbase.css's own `.zTable-container h4` rule (1.1rem, inherited
   color) — visibly smaller and uncolored next to a real zH2 like "שעות
   פעילות" right beside it. Every other heading on this page IS a real
   zH2, so they already match each other via the shared `h2` rule above;
   this is the one outlier — bring it in line with that same rule instead
   of leaving the table's auto-generated title looking like a different,
   lesser kind of heading. */
.zTable-container:has(.ck-table) h4 {
    font-size: var(--h2-size, 2rem);
    font-weight: 700;
    color: var(--ck-blue);
}

/* zbase.css's own `.zTable-container { margin: 1.5rem 0 }` gives the table
   a 24px top margin the "שעות פעילות" heading doesn't have (real zH1-h6
   all reset to margin-top:0), so "אנשי קשר" started 24px lower than
   "שעות פעילות" beside it — confirmed via getBoundingClientRect (24px
   gap, exactly the container's own margin-top). A first attempt added
   `margin-top: 1.5rem` to the heading, but only closed 8px of the 24px
   gap — the table is FLOATED, so its 24px margin applies in full
   (floats never collapse margins with siblings), while the heading's own
   margin-top COLLAPSES with the previous block's margin-bottom instead
   of adding on top of it, so most of the intended push was silently
   absorbed. `padding-top` doesn't collapse, so the same 24px there lands
   exactly on target (confirmed via getBoundingClientRect after). */
.ck-hours-heading {
    padding-top: 1.5rem;
}

/* The hours LIST (not its title, which already lines up with "אנשי קשר"
   above) is taller than the table's rows — each entry is two lines
   (bold day + hours), the table's rows are one — so top-aligning both
   left the list hanging noticeably past the table's bottom edge.
   Centered the list's vertical midpoint against the table's instead
   (needs 44px total extra height — confirmed via getBoundingClientRect:
   with all 44px as padding-top, the list overhangs the table by an equal
   ~5px above and below, so the CENTERING itself is correct either way,
   the box's own center only cares about total padding added).
   But putting all 44px on top alone left a lopsided 52px gap between the
   heading and the first entry ("ראשון - חמישי") against a 0px gap after
   the last one — visibly unbalanced, flagged directly. Split the same
   44px total as 18px top / 26px bottom (the 8px difference accounts for
   the list's own natural 8px top spacing that padding-top stacks with,
   so this is what actually lands both visible gaps equal — confirmed via
   getBoundingClientRect on the first/last entries, not just assumed from
   the padding numbers) — keeps the exact same table-centering as before,
   while making the whitespace above the first entry match the whitespace
   below the last one. */
.ck-hours-list {
    padding-top: 18px;
    padding-bottom: 26px;
}

/* Home's intro + emergency-notice paragraphs read as one continuous
   block of related text, not separate topics — the framework's default
   paragraph/heading spacing (zbase.css: 16px under a zText, 8px under a
   zH1-h6) read as too much air between them, flagged directly. Removes
   it entirely rather than just reducing it, per the request. */
.ck-tight {
    margin-bottom: 0;
}

/* Matches the old municipality site's own emphasis on eligibility/
   pricing criteria (its intro sentence + bullet list are bold weight
   throughout) — font-weight is inherited, so this on a zUL/zText's own
   element makes its child <li>/text bold with no per-item markdown. */
.ck-bold {
    font-weight: 700;
}

/* zImage has no size control of its own — it renders at the page's full
   content width by default (720px), way too big for a small illustrative
   diagram. Capped to roughly 2-3 of the diagram's own grid boxes wide. */
.ck-diagram-small {
    max-width: 220px;
    height: auto;
}

/* Search result's cemetery-overview map — sized to read clearly (unlike
   the small grave-adjacency diagram above) but still capped well under
   the page's own 760px content width. Map_Display wraps the base map +
   the red marker dot in one positioned box so the marker's SVG (same
   480x540 viewBox, see plugins/chevrakadisha.py _write_marker_svg) lands
   in exact registration over the base map underneath, regardless of
   which Map_X case rendered. */
#Map_Display {
    position: relative;
    display: inline-block;
    width: 100%;
    max-width: 500px;
    aspect-ratio: 480 / 540;
}

.ck-cemetery-map,
.ck-map-marker {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
}

.ck-map-marker {
    pointer-events: none;
    z-index: 2;
}

@media (max-width: 600px) {
    .zTable-container:has(.ck-table) {
        float: none;
        margin-left: 0;
    }
}

/* zTable's dark CARD background/border/shadow live on `.zTable-responsive`
   (the direct wrapper), not `.zTable-container` — confirmed via the real
   DOM (TABLE.zTable > DIV.zTable-responsive > DIV.zTable-container), not
   assumed from the docs. */
.zTable-responsive:has(.ck-table) {
    background: #ffffff !important;
    border: 1px solid var(--ck-grey-light) !important;
    box-shadow: none !important;
    border-radius: 10px;
}

.zTable-container:has(.ck-table) {
    width: auto !important;
}

/* ── Selected-result summary table — compact, light, not full page width ── */
.ck-result-table {
    width: auto !important;
    max-width: 100%;
    border-collapse: collapse;
    font-size: 0.95rem;
    box-shadow: none !important;
}

.ck-result-table th,
.ck-result-table td {
    border: 1px solid var(--ck-green);
    padding: 6px 18px;
    text-align: center !important;
}

.ck-result-table th {
    background: var(--ck-tan) !important;
    color: var(--ck-green) !important;
    font-weight: 700;
}

.ck-result-table td {
    background: #ffffff;
    color: #1a1a1a;
}

.zTable-container:has(.ck-result-table) {
    background: transparent !important;
    box-shadow: none !important;
    width: auto !important;
    display: inline-block;
    padding: 0 !important;
}

/* ── Cemetery map grid — a real zTable (not hand-floated divs — that
   approach broke on column alignment and window resize, see project
   memory). Columns are declared in REVERSE (14..1, שורה last) because
   zTable renders its first-declared column on the RTL "start" (right)
   side — declaring it reversed is what puts grave #1 physically leftmost
   and שורה on the right, matching the org's own reference spreadsheet.
   .ck-grid-table forces direction:ltr on just this table (safe — it's a
   real, self-contained element, not the shared page container other
   pages also render into). Being a real <table>, columns always align
   automatically and the framework's own .zTable-responsive wrapper
   handles narrow windows with a scrollbar instead of a broken reflow. ── */
.ck-grid-table {
    direction: ltr;
}

/* The table (forced LTR) sits flush against the page's true left edge
   with no natural gap, unlike RTL content which gets breathing room from
   the page's own right-side padding — give it back explicitly. */
.zTable-container:has(.ck-grid-table) {
    padding-left: 20px;
}

.ck-grid-table td,
.ck-grid-table th {
    min-width: 80px;
    padding: 8px;
    font-size: 13px;
    line-height: 1.3;
    text-align: center !important;
    vertical-align: middle !important;
    border: 1px solid rgba(0, 0, 0, 0.35) !important;
}

/* zbase.css ships its own `.zTable thead th { text-align: left }`,
   `.zTable tbody td { vertical-align: top, border-bottom only }`, and —
   the one that ate the status colors — `.zTable tbody tr:nth-child(even)
   td { background: ... }` (a zebra stripe at HIGHER specificity than a
   single .zGrave-* class, since it stacks tbody+tr+td tags plus the
   :nth-child pseudo-class). All of these silently win over plain rules
   below no matter the source order or a hard refresh — !important is the
   reliable fix throughout this block, matching the same override pattern
   already used by .ck-result-table against this same theme's defaults. ── */

.zGrave-buried {
    background: var(--ck-green) !important;
    color: var(--ck-tan-light) !important;
    font-weight: 600;
}

.zGrave-reserved {
    background: var(--ck-brown) !important;
    color: #ffffff !important;
    font-weight: 600;
}

.zGrave-conditional {
    background: #8a5fb0 !important;
    color: #ffffff !important;
    font-weight: 600;
}

.zGrave-free {
    background: #ffffff !important;
    color: #999999 !important;
}

/* ── חלקה חריגה (exceptional/irregular row) marker — added 2026-08-20.
   A whole physical row (every cell in it, regardless of status) gets a
   dark diagonal hatch layered on TOP of its normal status color, not
   instead of it. Deliberately `background-image` here, never the
   `background` shorthand — the .zGrave-* rules above already used the
   shorthand (so it fully resets background-image to none too), but a
   plain longhand like background-image is resolved per-property by the
   cascade independent of the OTHER declaration's shorthand origin; as
   long as this rule comes AFTER .zGrave-* in source order (it does),
   background-image is won by THIS rule while background-color stays
   whichever status color the OTHER class already set — composing both
   classes on the same cell instead of one replacing the other. Semi-
   transparent black reads on every existing status color (dark green/
   brown/purple AND plain white) without needing a per-status variant. */
.zGrave-flagged {
    background-image: repeating-linear-gradient(
        45deg,
        rgba(0, 0, 0, 0.28) 0px,
        rgba(0, 0, 0, 0.28) 3px,
        transparent 3px,
        transparent 9px
    ) !important;
}

/* ── Sticky grid header — keeps the grave-number row (and the parcel
   corner label) pinned to the top while scrolling a tall grid, so you
   always know which column AND which parcel you're on without needing a
   separate floating element (a standalone zText watermark was tried and
   abandoned — the framework's stray-login-box race, zolo-feedback-log
   #22, was confirmed to silently DELETE it from the page outright, not
   just visually cover it).
   Real constraint, not a bug: CSS does not allow `overflow-x: auto` +
   `overflow-y: visible` on the same box — the spec forces the "visible"
   axis to compute as `auto` too whenever the other axis isn't visible,
   so trying to force page-level scroll back (even with !important) was
   silently neutralized regardless of cascade/specificity. zbase.css's
   own `.zTable-responsive { overflow-x: auto }` (needed for the
   narrow-window horizontal scrollbar) already makes this wrapper
   position:sticky's real containing block — so instead of fighting
   that, embrace it: give the wrapper a bounded height with its own
   internal scroll, like a real spreadsheet viewport, so the sticky
   header has an actual scroll context to stick within. ── */
.zTable-responsive:has(.ck-grid-table) {
    max-height: 75vh;
    overflow-y: auto;
}

/* The sitewide 760px reading-column cap (.zVaF-content above) squeezes
   the cemetery grid tables into a narrow scrolling box within a scrolling
   box — they're wide spreadsheets, not prose, so exempt them via the same
   :has() escape-hatch pattern already used above. */
.zVaF-content:has(.ck-grid-table) {
    max-width: none;
}

.ck-grid-table thead th {
    position: sticky;
    top: 0;
    z-index: 20;
}

/* ── Modal close button — moved to the left corner (natural for RTL) ── */
.zModal-close {
    right: auto !important;
    left: 12px !important;
}

/* Search's name field defaulted to the form's full container width — a
   single name doesn't need a page-wide bar, per direct request. */
.ck-search-input {
    max-width: 320px;
}