/*
Theme Name: Bistrot Lepic (Child)
Template: twentytwentyone
Description: Custom brand styling for Bistrot Lepic & Wine Bar — Charm script headings (EB Garamond for body text, buttons, and table cells), wine/brass palette. Child theme of Twenty Twenty-One. Same design system as la-piquette-child (sister property), recolored: wine-dark chrome instead of charcoal, brass/gold accent instead of oxblood, since Bistrot Lepic is the founding restaurant and carries its own press history.
Version: 1.0.42
Author: Tunlaw Industries
*/

/* ==========================================================================
   1. BRAND COLOR PALETTE — the only place these values are set. Every rule
      below references these variables by name, never a literal hex, so the
      whole site recolors from this one block. See la-piquette-child/style.css
      for the sister property's palette — same structure, different hues.
   ========================================================================== */

:root {
	--bl-parchment: #f6efe0;      /* base page background ("paper") — slightly
	                                  warmer than La Piquette's champagne */
	--bl-parchment-deep: #e6d9bd; /* alternate section tone; also the color the
	                                  site's own Cover blocks already carry
	                                  (search-replaced from the old #f5e1a4) */
	--bl-wine: #3a1018;           /* primary dark chrome — header/footer/hero;
	                                  also what the site's dark Cover overlays
	                                  now carry (search-replaced from #111a3c) */
	--bl-wine-deep: #260a10;      /* wine hover/active state; utility bar bg */
	--bl-charcoal: #2a211c;       /* body ink */
	--bl-ink-soft: #5c5048;       /* muted/secondary text on light backgrounds */
	--bl-cream-text: #f3e9d2;     /* text/buttons on a dark (wine) background */
	--bl-brass: #a9762c;          /* button fill — also what the site's own
	                                  wp:button blocks now carry (search-replaced
	                                  from the old #95805d) */
	--bl-brass-deep: #8a5f22;     /* brass hover/active state */
	--bl-brass-ink: #7a5220;      /* headings/links on light backgrounds — a
	                                  darker brass than the button fill, chosen
	                                  for AA text contrast against parchment */
	--bl-brass-light: #d8b76a;    /* hover accent for text on a dark (wine)
	                                  background — see §7 */
}

/* ==========================================================================
   2. TYPOGRAPHY — Charm for actual heading elements, per the client's
      request to move off EB Garamond there specifically (EB Garamond
      stays everywhere else that borrows the same serif look — buttons,
      table cells, eyebrow labels, the pull-quote — none of that is a
      real <h1-6>/.wp-block-heading, so none of it is touched here).
      Both fonts load on the front end AND inside the block editor (see
      functions.php) so "Preview" matches live.

      Went Italianno -> MonteCarlo -> Charm, each swap on the client's
      own side-by-side comparison against real page content (the home
      hero title AND critics-reviews' 80-100-character review
      headlines), never a guess. Charm is a rounder, more casual
      handwriting style rather than Italianno/MonteCarlo's formal
      old-world calligraphy — a real aesthetic tradeoff the client
      accepted for it — but it read clearly at a glance on the long
      headlines that had strained (Italianno) or merely held up
      (MonteCarlo), unlike either of those. Legible enough there that
      the H4 -> EB Garamond fallback both earlier fonts needed has been
      REMOVED for Charm — verified directly on /critics-reviews/ itself,
      not assumed from the short-heading test alone; if a future font
      swap here brings that same long-heading strain back, that's the
      fix to reach for again (grep this file's history for "H4
      exception" for the exact rule). */

h1, h2, h3, h4, h5, h6,
.wp-block-heading,
.site-title,
.page-title,
.entry-title,
.wp-block-post-title {
	font-family: "Charm", "EB Garamond", Georgia, cursive;
	font-weight: 400;
	/* EB Garamond (the fallback) is a tightly-fit serif whose own tuned
	   +0.02em letter-spacing (its rule when used for BODY headings
	   elsewhere) would space Charm's connected cursive letterforms
	   apart oddly if Charm ever failed to load, so this stays reset to
	   normal specifically for this heading rule. */
	letter-spacing: normal;
}

.site-title { font-size: 1.9rem; }
.site-description { font-family: inherit; }

/* ==========================================================================
   3. BASE COLOR — body, headings, links.
   ========================================================================== */

/* !important on color: Twenty Twenty-One's own `body { color: var(--global--
   color-primary); ... }` (style.css) ties this rule's specificity exactly
   (both are a bare `body` selector), and per the recurring note elsewhere in
   this file, the host's Newfold/HostGator plugin duplicates the parent
   theme's stylesheet a second time after this one — so on that tie, source
   order handed it to Twenty Twenty-One's black default, sitewide, for any
   text with no other color rule on it. Confirmed via computed style on two
   separate pages, not just one. background-color isn't affected in
   practice (TT1's own default already resolves close enough that no visible
   conflict ever showed), so left as-is rather than guessing at a fix it
   doesn't need. */
body {
	background-color: var(--bl-parchment);
	color: var(--bl-charcoal) !important;
}

.entry-content h1:not(.has-text-color),
.entry-content h2:not(.has-text-color),
.entry-content h3:not(.has-text-color),
.entry-content h4:not(.has-text-color),
.entry-content .wp-block-heading:not(.has-text-color),
.entry-header .entry-title {
	color: var(--bl-brass-ink);
}
.wp-block-cover .wp-block-heading:not(.has-text-color),
.wp-block-cover h1:not(.has-text-color),
.wp-block-cover h2:not(.has-text-color),
.wp-block-cover h3:not(.has-text-color),
.wp-block-cover h4:not(.has-text-color) {
	color: var(--bl-cream-text);
}

a { color: var(--bl-brass-ink); }
a:hover, a:focus { color: var(--bl-wine); }

/* This site's own content sets an explicit per-block link color on almost
   every paragraph/heading with black text (~180 instances checked across
   every page) — the block editor's "Link" color sub-setting, output as a
   generated `.wp-elements-N a:where(...) { color: var(--wp--preset--
   color--black); }` inline rule per block. That leaves every one of those
   links literal black instead of this theme's brass-ink, and — since
   "black text" content on this site is always one of the light parchment
   sections, never a dark one — flat black is also never the right call
   background-wise either. `!important` is required: the generated rule
   has no `!important` itself, but ties this rule on specificity, and the
   generated inline block sits later in the document than this stylesheet,
   so it would otherwise win purely on source order. This also happens to
   fix the one link on /special-hire/ that was explicitly set to WHITE
   (illegible after that section's own background bug was fixed from black
   to parchment-deep — see the memory note) — !important here beats that
   inherited/direct white regardless of the exact mechanism setting it. */
.has-black-color a {
	color: var(--bl-brass-ink) !important;
}
.has-black-color a:hover,
.has-black-color a:focus {
	color: var(--bl-wine) !important;
}
/* Twenty Twenty-One gives EVERY plain link on the site an accessible
   keyboard-focus treatment — `body` carries `has-background-white`
   whenever the Customizer's site-wide Background Color is white,
   regardless of any individual section's own color, and core pairs that
   with a near-opaque black `background` and white `color` on `a:focus`
   (plain `:focus`, deliberately — it wants this to fire on ANY focus,
   mouse click included, not just keyboard), with its own `outline`
   deliberately transparent (the black-background swap IS its
   visible-focus mechanism). The `!important` color rule just above only
   overrides core's text color back to wine, not its background — so a
   focused link here rendered dark wine-on-near-black, effectively
   illegible, with no fallback focus indicator at all once that
   background is neutralized below. Confirmed via computed style
   (`background-color: rgba(0, 0, 0, 0.9)`), not assumed.

   First attempt at this fix used `:focus-visible` instead of `:focus`,
   reasoning by analogy to the buttons/footer-links convention elsewhere
   in this file — wrongly: those are a DIFFERENT, self-contained focus
   ring this theme adds on top of an otherwise-fine resting style, so
   restricting it to keyboard-only focus is a deliberate, correct choice
   there. Here, the thing being OVERRIDDEN (core's own `:focus` rule) is
   not keyboard-only, so a `:focus-visible` override left a mouse click
   still hitting core's unpatched black-box styling untouched — caught
   by the user clicking the link directly, screenshotted. Matching
   core's own `:focus` here, not `:focus-visible`, is the actual fix. */
.has-black-color a:focus {
	background-color: transparent !important;
	outline: 2px solid var(--bl-wine) !important;
	outline-offset: 2px;
}
/* Same story, headings this time: a heading with the block editor's text
   color explicitly set to black (e.g. every review's publication-name H3
   and headline H4 on /critics-reviews/, or "Hire the Wine Bar"'s H3 on
   /special-hire/) carries `.has-black-color`, which is exactly what
   `.entry-content h3:not(.has-text-color)` (below) is written to
   skip — so these render literal black instead of this theme's brass-ink,
   same inconsistency as the link case, just never caught until compared
   side-by-side across pages. */
.has-black-color.wp-block-heading,
.has-black-color h1,
.has-black-color h2,
.has-black-color h3,
.has-black-color h4 {
	color: var(--bl-brass-ink) !important;
}

/* The other half of the same inconsistency, caught comparing hero covers
   side-by-side across pages: roughly half of them have their H1 (or, on
   /special-hire/, a `<mark>` around one link) explicitly set to the block
   editor's "White" preset (`.has-white-color`), literal #ffffff, while
   the other half never set a text color at all and got this theme's
   cream (`--bl-cream-text`, #f3e9d2) from the plain `.wp-block-cover
   h1:not(.has-text-color)` default a few lines up — two visibly
   different whites depending on which page you're on. Checked every
   `.has-white-color` instance sitewide (Home, Hire Bistrot Lepic, The
   Story of Bistrot Lepic, Critic's Reviews, French Cuisine, Wine
   Tasting, Merchandise) before this rule: every one sits on a dark
   cover, never a light one, so normalizing all of them to cream is safe
   sitewide — same reasoning, and same fix shape, as the `.has-black-
   color` rules just above. */
.has-white-color {
	color: var(--bl-cream-text) !important;
}

/* Dark-background safety net: a Group/Cover with a dark custom background
   but no matching text color would otherwise fall back to the site's dark
   default ink — illegible. Every dark custom background on this site is
   wine or wine-deep, so cream text is a safe default here. Most of this
   site's own content already sets an explicit text color per block, but
   this is cheap insurance for anything that doesn't.

   This comment always SAID "Group/Cover", but the rule itself only ever
   matched `.wp-block-group` — Cover never actually had this safety net,
   despite what the comment claimed. That gap is exactly why plain
   unstyled paragraphs kept turning up literal white (`rgb(255,255,255)`)
   inside dark Cover sections sitewide (the homepage's Hours notes, its
   Wine & Cocktails paragraph, its Contact Us block, ...): WP core's own
   `.wp-block-cover { color: #fff }` default was the only thing setting
   their color at all, and nothing here was overriding it — confirmed via
   a sitewide computed-color sweep, not assumed, after being asked why
   any text on the site was rendering white. Every dark Cover here uses a
   raw hex `customOverlayColor` rather than a named preset, so none of
   them carry `.has-background` (that class is Group-only in this
   theme's real content) — matched by absence of `.is-light` instead,
   the class Twenty Twenty-One does add to every LIGHT cover
   (`isDark:false`) here.

   Setting `color` on `.wp-block-cover` itself wasn't actually enough,
   either — confirmed by walking the real computed-color chain from an
   affected paragraph up to `<body>`, not assumed: Twenty Twenty-One has
   its OWN separate rule, `.wp-block-cover:not([class*=background-color])
   .wp-block-cover__inner-container { color: var(--cover--color-
   foreground) }` (literal white), that sets color directly on the
   INNER container — every raw-hex-`customOverlayColor` cover here
   matches that `:not([class*=background-color])` condition (that
   substring only ever appears in a NAMED preset color's class, e.g.
   `has-black-background-color`, never a raw hex), so this second rule
   was overriding right past whatever the outer `.wp-block-cover`
   itself was told to do — the true reason the first attempt at this
   safety net still left two paragraphs white. Matching that same inner
   selector directly closes it for real. */
.wp-block-group.has-background:not(.has-text-color),
.wp-block-cover:not(.is-light):not(.has-text-color) {
	color: var(--bl-cream-text);
}
.wp-block-group.has-background:not(.has-text-color) .wp-block-heading:not(.has-text-color),
.wp-block-cover:not(.is-light):not(.has-text-color) .wp-block-heading:not(.has-text-color),
.wp-block-cover:not(.is-light):not(.has-text-color) .wp-block-cover__inner-container {
	color: var(--bl-cream-text) !important;
}
/* Editor-only third layer of the same bug: inside wp-admin, the SAME
   paragraph also carries Gutenberg's own `.block-editor-rich-text__
   editable`/`.rich-text` classes (the front end never has these at
   all — they only exist on the editable layer), and the editor's own
   bundled CSS sets a color on those classes more specifically than the
   inherited cream from the container rule just above. Confirmed by
   reading the paragraph's OWN computed color and class list directly
   inside the editor iframe (still literal white there after the fix
   above already worked correctly one level up, on `.wp-block-cover__
   inner-container` itself) — not assumed. `.editor-styles-wrapper`
   scopes this to the editor only; the front end doesn't need it and
   doesn't have a matching selector to trigger it either way. */
.editor-styles-wrapper .wp-block-cover:not(.is-light):not(.has-text-color) p:not(.has-text-color) {
	color: var(--bl-cream-text) !important;
}

/* ==========================================================================
   3b. LIGHT-COVER COLOR DEFAULTS — the other half of the safety net above,
       and the direct answer to "how does a client add content to a light
       vs. a dark section without having to think about color."

       Before this: a DARK cover was already safe with NO color picked at
       all (defaults to cream, per 3 above) — but a LIGHT cover was not.
       §3's own heading rule (`.wp-block-cover h1:not(.has-text-color) {
       color: cream }`) applies to EVERY cover regardless of light or
       dark, and nothing overrode it for light ones specifically; a plain
       paragraph with no color picked had nothing overriding WP core's
       own cover default (also cream/white) either. Net effect: a client
       typing a new heading or paragraph into a light band and never
       touching the color picker got invisible cream-on-parchment —
       exactly the kind of mismatch this whole file has spent all day
       chasing, just not yet hit because no real content had tried it.

       The fix is symmetric with §3: light covers now default to the same
       colors the rest of the page's plain content already uses (charcoal
       body text, brass-ink headings) with NO color picked, exactly
       mirroring dark covers defaulting to cream with no color picked.
       Result: for BOTH kinds of section, "don't touch the color picker"
       is now always the right, safe answer — the one genuinely
       zero-thought path. `.is-light` is the same marker §3 uses to tell
       light covers from dark ones (Twenty Twenty-One adds it whenever a
       cover's own `isDark` is false); every real light cover on this
       site already carries it.

       CORRECTION, caught by the client the same day this shipped: on
       /critics-reviews/ (and /story-of-bistrot-lepic/ and /wine-tasting/,
       checked sitewide, not assumed), the hero photo Cover's OWN
       `className` attribute is a hand-authored (pre-child-theme, likely
       Cherry-framework-era) `"mobile-cover-height hide-desktop is-
       light"` — a coincidental name COLLISION, not Twenty Twenty-One's
       auto-generated marker at all: this is a genuinely dark photo hero
       (black dim overlay), and "is-light" there apparently meant
       something else entirely to whoever wrote it originally
       ("hide-desktop" is dead too, confirmed not actually hiding
       anything, same as the unrelated "hide-on-mobile" class found
       elsewhere this session). `.wp-block-cover.is-light` matched it
       anyway, since CSS has no way to know which "is-light" was meant —
       so this rule started giving the hero's `has-white-color` H1
       brass-ink instead of cream, dark-on-dark-photo, hard to read.
       `mobile-cover-height` reliably marks exactly this legacy pattern
       (every real instance found sitewide is a dark photo hero, never a
       genuine light band) so excluding on it closes the collision
       precisely without weakening the `.is-light` check for every real
       light cover that doesn't carry that old class. */
.wp-block-cover.is-light:not(.mobile-cover-height) .wp-block-heading:not(.has-text-color),
.wp-block-cover.is-light:not(.mobile-cover-height) h1:not(.has-text-color),
.wp-block-cover.is-light:not(.mobile-cover-height) h2:not(.has-text-color),
.wp-block-cover.is-light:not(.mobile-cover-height) h3:not(.has-text-color),
.wp-block-cover.is-light:not(.mobile-cover-height) h4:not(.has-text-color) {
	color: var(--bl-brass-ink) !important;
}
.wp-block-cover.is-light:not(.mobile-cover-height):not(.has-text-color),
.wp-block-cover.is-light:not(.mobile-cover-height):not(.has-text-color) .wp-block-cover__inner-container {
	color: var(--bl-charcoal) !important;
}
.editor-styles-wrapper .wp-block-cover.is-light:not(.mobile-cover-height):not(.has-text-color) p:not(.has-text-color) {
	color: var(--bl-charcoal) !important;
}

/* ==========================================================================
   3c. EXPLICIT "BLACK"/"WHITE" COLOR CHOICES, MADE SAFE REGARDLESS OF
       SECTION — the other way a client's choice could still go invisible
       even with 3/3b's good defaults above: actively PICKING black or
       white from the editor's color swatches, rather than leaving color
       untouched. §1's `.has-black-color`/`.has-white-color` rules
       already remap those sitewide (checked, at the time, against every
       instance that then existed — always black-on-light or white-on-
       dark) — but that check can't know what a client picks NEXT. Black
       chosen inside a dark section, or white chosen inside a light one,
       would still slip through those rules exactly as literal black-on-
       dark or white-on-light: both real, both invisible. `.wp-block-
       cover:not(.is-light)`/`.wp-block-cover.is-light` here bump
       specificity enough to override §1's plain `.has-black-color`/
       `.has-white-color` for exactly the cases those hadn't accounted
       for, while leaving the already-correct cases (black-on-light,
       white-on-dark) untouched. Computed by hand, not assumed: brass-ink
       (§1's black-text remap) on wine is only ≈2.4:1 — confirms this
       isn't a hypothetical, that combination was already failing WCAG
       2.2's 4.5:1 outright, just never triggered by any real content. */
.wp-block-cover:not(.is-light) .has-black-color,
.wp-block-cover:not(.is-light) .has-black-color a,
.wp-block-cover:not(.is-light) .has-black-color.wp-block-heading,
.wp-block-cover:not(.is-light) .has-black-color h1,
.wp-block-cover:not(.is-light) .has-black-color h2,
.wp-block-cover:not(.is-light) .has-black-color h3,
.wp-block-cover:not(.is-light) .has-black-color h4 {
	color: var(--bl-cream-text) !important;
}
.wp-block-cover.is-light:not(.mobile-cover-height) .has-white-color {
	color: var(--bl-brass-ink) !important;
}

/* Twenty Twenty-One sizes `.alignwide` with
   `max-width: calc(100vw - var(--responsive--spacing-horizontal))` — `100vw`
   includes the scrollbar's own width, which `100%`/clientWidth does not.
   On any page long enough to actually scroll (e.g. /critics-reviews/, with
   its many press-quote sections, each one an `.alignwide` heading/
   paragraph), that gap let every one of them run a consistent few pixels
   past the right edge of the screen on narrow viewports — confirmed via
   `getBoundingClientRect()` across every review block, not just eyeballed.

   First attempt at a fix here was a flat `max-width: 100% !important`,
   reasoned as "can only ever make alignwide narrower, never wider than
   Twenty Twenty-One's own calc." That reasoning was wrong, and it broke
   real pages: on /story-of-bistrot-lepic/lepic-team/'s media-text blocks
   and Le Buzz's header — anywhere `.alignwide` sits directly in a
   genuinely full-width containing block, not a narrower wrapper like a
   Cover's inner-container — "100% of the container" IS the full page
   width, so replacing Twenty Twenty-One's own `min(..., 1240px)`-style cap
   with a flat 100% let those blocks stretch edge-to-edge instead of
   staying at the intended ~1240px centered width. Confirmed via
   getBoundingClientRect: 1920px wide, left:0, on a 1920px viewport.

   `min()` keeps BOTH constraints instead of one replacing the other: it's
   the smaller of Twenty Twenty-One's own intended wide-size and 100% of
   the real container, so it still fixes the scrollbar-overflow case (where
   the calc's 100vw math is the larger, losing value) without discarding
   the deliberate narrower cap everywhere else (where the calc is already
   the smaller, winning value, unchanged from Twenty Twenty-One's own
   behavior). `!important` for the same specificity-tie-with-the-
   duplicated-parent-stylesheet reason as every other override here. */
.alignwide {
	max-width: min(100%, var(--responsive--alignwide-width)) !important;
}

/* ==========================================================================
   4. BUTTONS — oxblood-family fill, cream text, EB Garamond. This site's own
      Button blocks already carry an inline background-color (search-replaced
      from the old #95805d to --bl-brass — see §1), so this doesn't need to
      set the fill color itself, only the typography/border/hover treatment —
      except where a button has NO inline color at all, where the brass
      default below applies.

      Same specificity note as la-piquette-child/style.css §4: this host's
      bundled Newfold/HostGator plugin ("wp-plugin-hostgator") duplicates the
      parent theme's stylesheet a second time after ours in the served page,
      so an exact specificity tie with Twenty Twenty-One's own button CSS can
      lose depending on load order. `#page` (present on every front-end page)
      makes this selector strictly more specific, and `:is(#page,
      .editor-styles-wrapper)` adds the block editor's own wrapper as a second
      way to match with the same specificity boost.
   ========================================================================== */

/* text-decoration here is NOT redundant with core's
   `:where(.wp-block-button__link) { text-decoration: none; ... }` — a bare
   `.wp-element-button` (no `.wp-block-button__link` class, e.g. the
   footer's "Reserve a Table" link, kept off that class specifically to
   dodge core's `height: 100%` on it) never gets that rule at all, so it
   has to be set here directly rather than assumed from the class pairing.
   (Padding is unaffected: the footer link carries its own inline padding,
   and every `.wp-block-button__link`-classed button still gets core's.) */
/* WCAG 2.2 SC 1.4.3: cream (#f3e9d2) on this fill (#a9762c) at the
   previous 1.05em/regular-weight is only ≈3.28:1 — fails the 4.5:1
   normal-text minimum, computed by hand (sRGB relative luminance), not
   assumed. WCAG's "large text" exception (3:1 minimum, which 3.28
   clears) needs 18pt regular OR 14pt bold — 24px or 18.66px respectively
   at the standard 96dpi 1pt=1.333px conversion — and the previous
   1.05em (~16.8px on this site's 16px base) cleared neither, even bold
   (a still-too-small first attempt at this same fix genuinely missed
   that: weight alone doesn't help under 18.66px). Bumped to 1.2em
   (~19.2px) *and* bold together, comfortably past the 18.66px bold
   threshold, rather than darken the brand's actual brass fill (a
   deliberate, already-approved color used everywhere) or lighten the
   text past cream. The hover/focus fill (--bl-brass-deep) already
   clears 4.5:1 on its own (≈4.65:1) at any size, so only the resting
   state needed this. */
:is(#page, .editor-styles-wrapper) .wp-block-button .wp-block-button__link,
:is(#page, .editor-styles-wrapper) .wp-element-button {
	background-color: var(--bl-brass);
	color: var(--bl-cream-text) !important;
	font-family: "EB Garamond", Georgia, serif !important;
	font-weight: 600;
	letter-spacing: 0.03em;
	font-size: 1.2em;
	border-radius: 2px;
	border: 1px solid var(--bl-cream-text) !important;
	text-decoration: none !important;
}
:is(#page, .editor-styles-wrapper) .wp-block-button:not(.is-style-outline) .wp-block-button__link:hover,
:is(#page, .editor-styles-wrapper) .wp-block-button:not(.is-style-outline) .wp-block-button__link:active,
:is(#page, .editor-styles-wrapper) .wp-element-button:hover {
	background-color: var(--bl-brass-deep) !important;
	color: var(--bl-cream-text) !important;
	border-color: var(--bl-cream-text) !important;
}
:is(#page, .editor-styles-wrapper) .wp-block-button .wp-block-button__link:focus-visible,
:is(#page, .editor-styles-wrapper) .wp-element-button:focus-visible {
	outline: 2px solid var(--bl-brass-light);
	outline-offset: 2px;
}

/* ==========================================================================
   5. LOGO PROMINENCE
   ========================================================================== */

.site-logo .custom-logo,
.custom-logo-link .custom-logo,
img.custom-logo {
	max-height: 68px !important;
	max-width: 220px !important;
	width: auto !important;
	height: auto !important;
}

/* ==========================================================================
   6. HEADER + FOOTER — full-bleed wine chrome, one unified hover language.

      CONTRAST, checked against WCAG 2.2 AA (4.5:1 body text, 3:1 large
      text/UI) for #3a1018 specifically:
        cream (#f3e9d2) on wine    ≈ 13.7:1 — links, body text
        brass-light (#d8b76a) on wine ≈ 8.6:1 — the hover/focus accent
        brass (#a9762c) on wine   ≈  4.2:1 — fine for large text/UI, which is
          why plain brass never carries small body text on this background.
   ========================================================================== */

.site-header,
.site-footer,
.widget-area {
	background-color: var(--bl-wine) !important;
	color: var(--bl-cream-text) !important;
}
.site-header,
.site-footer,
.widget-area {
	max-width: none !important;
	width: 100% !important;
}
.site-header {
	display: flex !important;
	flex-direction: row !important;
	flex-wrap: wrap;
	align-items: center !important;
	justify-content: space-between !important;
	text-align: left;
	padding: 0.65rem 1.5rem !important;
	gap: 0.75rem 1.5rem;
}
/* Same clearfix-pseudo removal as la-piquette-child §11: Twenty Twenty-One's
   own `.site-header::before{content:"";display:table}` is a leftover from
   its default stacked layout — inside our flex row it just adds a third,
   invisible flex item that throws off `space-between`. */
.site-header::before,
.site-header::after {
	content: none !important;
	display: none !important;
}
.site-header > .site-logo {
	width: auto !important;
	padding-bottom: 0 !important;
	border-bottom: none !important;
}
/* Site title + tagline stay in the markup for SEO/screen readers, but the
   logo already carries the brand and the hero repeats the tagline. */
.site-header .site-branding {
	position: absolute;
	width: 1px;
	height: 1px;
	padding: 0;
	margin: -1px;
	overflow: hidden;
	clip: rect(0, 0, 0, 0);
	white-space: nowrap;
	border: 0;
}
#main {
	padding-top: 0 !important;
	padding-bottom: 0 !important;
}
.entry-content > *:last-child {
	margin-bottom: 0 !important;
}

/* --- Primary nav --- */
.primary-navigation {
	width: auto;
	max-width: none;
	border-top: none;
	margin-top: 0;
	padding-top: 0;
}
.primary-navigation .primary-menu-container,
.primary-navigation ul.menu-wrapper {
	display: flex;
	justify-content: center;
	flex-wrap: wrap;
	gap: 0.5rem 1rem;
}
.site-header a,
.site-header .site-title,
.site-header .site-title a,
.site-header .site-description,
.primary-navigation a,
.primary-navigation a:link,
.primary-navigation a:visited,
.site-title a:link,
.site-title a:visited {
	color: var(--bl-cream-text) !important;
}
/* Twenty Twenty-One's own `.primary-navigation a` (block-library-adjacent
   core CSS, inside its own `@media (min-width: 482px)`) sets font-size to
   `var(--primary-nav--font-size)` — which resolves to
   `var(--global--font-size-md)`, 1.25rem — at the exact same selector and
   specificity as this rule. Same recurring cause as everywhere else in
   this file: the host's Newfold/HostGator plugin duplicates the parent
   stylesheet a second time after this one, so that tie went to core's
   1.25rem on source order — the previous version of this rule had no
   `!important`, so asking for 1rem silently kept rendering at 1.25rem
   (20px) the whole time; confirmed via computed style, not assumed. */
:is(#page, .editor-styles-wrapper) .primary-navigation a {
	font-size: 1rem !important;
	letter-spacing: 0.04em;
	text-transform: uppercase;
	text-decoration: none;
}
.primary-navigation a:hover,
.primary-navigation a:focus,
.site-title a:hover,
.site-title a:focus {
	color: var(--bl-brass-light) !important;
	text-decoration: underline;
	text-decoration-color: var(--bl-brass-light);
}
#primary-mobile-menu {
	color: var(--bl-cream-text) !important;
	border-color: var(--bl-cream-text) !important;
}
#primary-mobile-menu svg { fill: currentColor !important; }

/* --- Desktop submenu ("The Place" > Critic's Reviews / Gallery / Our Team):
   Twenty Twenty-One already renders this accessibly (a real <button
   class="sub-menu-toggle"> with aria-expanded, toggled by its own JS) — this
   only needs to be recolored to match the rest of the header, not rebuilt. --- */
.primary-navigation .menu-item-has-children { position: relative; }
/* Twenty Twenty-One's own, more specific selector
   (`.primary-navigation > div > .menu-wrapper .sub-menu-toggle`, 3 classes
   deep vs. this rule's 2) sets `color: currentColor` on this exact button —
   which resolves through inheritance from `.primary-navigation` itself
   (Twenty Twenty-One also sets that element's OWN `color` directly, to its
   own design-token default), not from `.site-header`'s cream. `!important`
   here is required to actually win — matching or exceeding Twenty
   Twenty-One's selector length isn't enough on its own. */
.primary-navigation .sub-menu-toggle {
	color: var(--bl-cream-text) !important;
	background: transparent;
	border: none;
}
.primary-navigation .sub-menu-toggle svg { fill: currentColor !important; }
/* Twenty Twenty-One's own `.primary-navigation .sub-menu` (same selector,
   same specificity) sets `border: 1px solid var(--primary-nav--border-
   color)`, which resolves to literal black — not a subtle design choice,
   an actual bug, confirmed via computed style (`rgb(0, 0, 0)`), same
   duplicated-stylesheet tie as everywhere else in this file: this rule
   had no `!important` before, so the intended soft cream border never
   rendered at all. */
:is(#page, .editor-styles-wrapper) .primary-navigation .sub-menu {
	background-color: var(--bl-wine) !important;
	border: 1px solid rgba(243, 233, 210, 0.25) !important;
	padding: 0.5rem 0;
	min-width: 180px;
}
/* Each <li> in this menu paints its own opaque light background over the
   <ul>'s wine background — every stylesheet loaded on the page was checked
   programmatically (including inside @media blocks) and none declares it;
   the source is unidentified, but overriding it directly here is proven to
   work regardless of where it's coming from. */
.primary-navigation .sub-menu li {
	background-color: var(--bl-wine) !important;
}
@media (min-width: 768px) {
	.primary-navigation .sub-menu {
		position: absolute;
		top: 100%;
		left: 0;
		z-index: 10;
	}
}
.primary-navigation .sub-menu a {
	display: block;
	padding: 0.5rem 1rem;
	white-space: nowrap;
	font-size: 0.78rem;
}

/* On mobile, the desktop dropdown's floating box reads oddly once it's
   sitting inline inside a full-screen list instead of floating over the
   page — a plain rectangle nested in a list doesn't read as "these three
   items belong to The Place" the way a floating dropdown naturally does.
   Swap the box for the much more common nested-list convention instead:
   no border, a brass accent bar on the left, and a slightly darker inset
   background + extra indent, so it reads as "tucked under" its parent
   rather than as a separate floating card. */
/* `#page` here isn't just this file's usual duplicate-stylesheet
   insurance — the general `.sub-menu` fix just above is ALSO `#page`-
   boosted, so without matching that here too, this more-specific-looking
   mobile override actually loses to it on plain specificity (an ID beats
   three classes regardless of source order or matching `!important`). */
body.primary-navigation-open .primary-navigation .sub-menu:is(#page *, .editor-styles-wrapper *) {
	background-color: var(--bl-wine-deep) !important;
	border: none !important;
	border-left: 3px solid var(--bl-brass) !important;
	margin: 0.35rem 0 0.35rem 1.5rem !important;
	padding: 0.25rem 0 !important;
}
body.primary-navigation-open .primary-navigation .sub-menu li:is(#page *, .editor-styles-wrapper *) {
	background-color: var(--bl-wine-deep) !important;
}
body.primary-navigation-open .primary-navigation .sub-menu a:is(#page *, .editor-styles-wrapper *) {
	font-size: 1rem;
	padding: 0.7rem 1.5rem !important;
}

/* --- Mobile menu overlay --- */
body.primary-navigation-open .primary-navigation,
body.primary-navigation-open .primary-navigation .primary-menu-container {
	background-color: var(--bl-wine) !important;
	min-height: 100vh;
	z-index: 999;
}
body.primary-navigation-open .menu-button-container {
	z-index: 1000;
	background-color: var(--bl-wine) !important;
}
body.primary-navigation-open .primary-navigation .menu-wrapper,
body.primary-navigation-open .primary-navigation .primary-menu-container {
	padding: 2rem 1.5rem;
}
body.primary-navigation-open .primary-navigation a {
	color: var(--bl-cream-text) !important;
	font-size: 1.1rem;
	display: block;
	width: 100%;
	padding: 0.9rem 1.5rem;
	-webkit-tap-highlight-color: transparent;
}
body.primary-navigation-open .primary-navigation a:active,
body.primary-navigation-open .primary-navigation a:focus-visible {
	background-color: rgba(243, 233, 210, 0.12);
	outline: none;
}
body.primary-navigation-open .primary-navigation .primary-menu-container {
	flex-direction: column !important;
	align-items: stretch !important;
}
body.primary-navigation-open .primary-navigation .menu-wrapper,
body.primary-navigation-open .primary-navigation ul.menu-wrapper {
	flex-direction: column !important;
	flex-wrap: nowrap !important;
	justify-content: center !important;
	align-items: stretch;
	gap: 0.25rem;
	width: 100% !important;
	height: auto !important;
	max-height: 100%;
	overflow-y: auto;
}
body.primary-navigation-open .primary-navigation li.menu-item {
	text-align: center;
	width: 100% !important;
	flex: 0 0 auto !important;
}
body.primary-navigation-open #primary-mobile-menu,
body.primary-navigation-open .primary-navigation .dropdown-icon {
	color: var(--bl-cream-text) !important;
}

/* --- Utility bar (Simple Banner plugin — same plugin/markup as La Piquette:
   `.simple-banner-text` wraps the whole bar, each item is an `<a
   class="top-button-style">`). `simple_banner_position` was switched from
   "footer" (CSS position:fixed;bottom:0 — the plugin's own name for a
   sticky-bottom bar) to "static" via `wp option update`, so it renders in
   normal document flow at the very top of <body>, same as La Piquette,
   instead of floating over the bottom of the viewport. --- */
.simple-banner-text,
.simple-banner-text * {
	background-color: var(--bl-wine-deep) !important;
	color: var(--bl-cream-text) !important;
}
.simple-banner-text {
	display: flex;
	flex-wrap: wrap;
	justify-content: center;
	align-items: center;
	gap: 4px;
}
.top-button-style {
	display: inline-block;
	padding: 6px 14px;
	font-size: 0.78rem;
	letter-spacing: 0.08em;
	text-transform: uppercase;
	white-space: nowrap;
	text-decoration: underline;
	text-decoration-color: rgba(243, 233, 210, 0.35);
	border-right: 1px solid rgba(243, 233, 210, 0.35);
}
.top-button-style:last-child { border-right: none; }
.top-button-style:hover,
.top-button-style:focus {
	color: var(--bl-brass-light) !important;
	text-decoration-color: var(--bl-brass-light);
}

/* --- Footer widget area + real <footer>: read as one continuous band. --- */
.widget-area {
	margin-top: 0 !important;
	padding: 2.5rem 1.5rem 0;
	border-bottom: none;
	display: block !important;
	width: 100% !important;
	max-width: none !important;
}
.widget-area .widget { width: 100% !important; max-width: none !important; }
.site-footer { padding: 0 1.5rem 1.5rem; }

/* Footer grid authored in the Custom HTML footer widget — Brand / Visit /
   Hours / More, a site-map row, and a fine-print line, same pattern as
   la-piquette-child's .lp-footer-grid. */
.bl-footer-grid,
.bl-footer-grid * { color: var(--bl-cream-text) !important; }
.bl-footer-grid {
	display: grid;
	grid-template-columns: 1.6fr 1fr 1fr 1.2fr;
	gap: 2.5rem;
	max-width: 1100px;
	margin: 0 auto 1.5rem;
	text-align: left;
}
@media screen and (max-width: 780px) {
	.bl-footer-grid { grid-template-columns: 1fr 1fr; }
}
@media screen and (max-width: 640px) {
	.bl-footer-grid { grid-template-columns: 1fr; text-align: center; }
}
.bl-footer-heading {
	font-family: "EB Garamond", Georgia, serif;
	font-size: 1.15rem;
	letter-spacing: 0.04em;
	margin: 0 0 0.6rem;
}
.bl-footer-col p, .bl-footer-col a { display: block; margin: 0.3rem 0; font-size: 0.9rem; opacity: 0.9; }
.bl-footer-col a:hover, .bl-footer-col a:focus { color: var(--bl-brass-light) !important; }
.bl-footer-col a:focus-visible { outline: 2px solid var(--bl-brass-light); outline-offset: 2px; }
.bl-footer-brand .bl-footer-mark { display: block; font-family: "EB Garamond", Georgia, serif; font-size: 1.4rem; }
.bl-footer-brand img.custom-logo { max-height: 62px !important; margin-bottom: 0.75rem; }
.bl-footer-brand p { margin: 0.6rem 0 1.1rem; font-size: 0.9rem; opacity: 0.9; max-width: 26em; }

.bl-footer-sitemap {
	grid-column: 1 / -1;
	border-top: 1px solid rgba(243, 233, 210, 0.25);
	border-bottom: 1px solid rgba(243, 233, 210, 0.25);
	margin-top: 1rem;
	padding-top: 1.2rem;
	padding-bottom: 1.2rem;
	display: flex;
	flex-wrap: wrap;
	justify-content: center;
	gap: 0.5rem 1.75rem;
}
.bl-footer-sitemap a {
	font-size: 0.78rem;
	letter-spacing: 0.1em;
	text-transform: uppercase;
	text-decoration: underline;
	text-decoration-color: rgba(243, 233, 210, 0.35);
}
.bl-footer-sitemap a:hover, .bl-footer-sitemap a:focus {
	color: var(--bl-brass-light) !important;
	text-decoration-color: var(--bl-brass-light);
}
.bl-footer-sitemap a:focus-visible { outline: 2px solid var(--bl-brass-light); outline-offset: 2px; }

.bl-footer-fine {
	grid-column: 1 / -1;
	margin-top: 0.5rem;
	text-align: center;
	font-size: 0.8rem;
	opacity: 0.6;
}

/* ==========================================================================
   7. MENU/MERCHANDISE TABLE — ported directly from la-piquette-child's
      .lp-menu-table (the client specifically liked this pattern on La
      Piquette's own Merchandise page): a plain WP Table block, name
      bold-left / link right, divided by thin rules — no card, no grid, no
      price column (this site's own content never had per-item descriptions
      or prices to put in one).

      Sits on the light --bl-parchment-deep band (changed from the original
      dark wine band at the client's request), so every color below is
      chosen and checked against THAT background specifically — this isn't
      the same reusable dark-band component anymore. WCAG 2.2 AA contrast
      against #e6d9bd, computed, not eyeballed:
        charcoal (#2a211c) on parchment-deep  ≈ 11.3:1 — table cell text
        brass-ink (#7a5220) on parchment-deep ≈  4.9:1 — item names, links
          (passes AA's 4.5:1 for normal text with room to spare; item names
          are large text too — 1.5rem/24px — so they'd clear the lower 3:1
          large-text minimum even without the extra margin)
      If this component is ever reused on a dark band again, these colors
      need to flip back — this rule doesn't try to serve both cases at once.
   ========================================================================== */

.bl-menu-table {
	max-width: 900px;
	margin: 2rem auto 0;
}
.bl-menu-table table {
	width: 100%;
	border-collapse: collapse;
}
/* Twenty Twenty-One puts a full 1px border on every table cell site-wide
   (`table td, table th {border:1px solid}`) — same specificity as a plain
   `.bl-menu-table td`, and per §4's note on the host's caching plugin
   duplicating that stylesheet a second time after ours, a tie isn't safe
   to rely on. `#page` decisively wins regardless of load order. */
:is(#page, .editor-styles-wrapper) .bl-menu-table td {
	padding: 1.6rem 0.75rem;
	border: none !important;
	border-top: 1px solid rgba(58, 16, 24, 0.15) !important;
	vertical-align: baseline;
	color: var(--bl-charcoal);
}
:is(#page, .editor-styles-wrapper) .bl-menu-table tr:last-child td {
	border-bottom: 1px solid rgba(58, 16, 24, 0.15) !important;
}
.bl-menu-table td:first-child {
	padding-left: 0;
	white-space: nowrap;
	width: 1%;
}
.bl-menu-table td:last-child {
	padding-right: 0;
	text-align: right;
	white-space: nowrap;
	width: 1%;
}
.bl-menu-table .bl-menu-name {
	font-family: "EB Garamond", Georgia, serif;
	font-size: 1.5rem;
	color: var(--bl-brass-ink);
}
.bl-menu-table a {
	color: var(--bl-brass-ink) !important;
	text-decoration: underline;
	text-decoration-color: rgba(122, 82, 32, 0.4);
}
.bl-menu-table a:hover,
.bl-menu-table a:focus {
	color: var(--bl-wine) !important;
	text-decoration-color: var(--bl-wine);
}
/* Same fix, same cause, as the `.has-black-color a:focus` rule above:
   Twenty Twenty-One's own site-wide `body.has-background-white` focus
   mechanism forces a near-opaque black `background` on EVERY focused
   plain link via plain `:focus` — deliberately not `:focus-visible`,
   so it fires on a mouse click too, not just keyboard — with its own
   `outline` deliberately transparent (that background swap IS the
   built-in indicator). This table's wine focus color, with no
   background override, rendered as dark wine-on-near-black — reported
   illegible (screenshotted from a mouse click specifically), confirmed
   via computed style (`background-color: rgba(0, 0, 0, 0.9)`). A first
   attempt at this fix used `:focus-visible`, which does not match a
   mouse-clicked link in Chromium — leaving core's unpatched black-box
   `:focus` styling in effect for exactly the interaction that was
   reported, still broken. Matching `:focus` here, not `:focus-visible`,
   actually fixes it regardless of input modality. Cancel the background
   and supply a real focus outline instead — this band is light
   (parchment-deep), so wine again, not brass-light (too low-contrast to
   be visible here). */
.bl-menu-table a:focus {
	background-color: transparent !important;
	outline: 2px solid var(--bl-wine) !important;
	outline-offset: 2px;
}
@media screen and (max-width: 600px) {
	:is(#page, .editor-styles-wrapper) .bl-menu-table td { display: block; width: 100% !important; padding: 0.2rem 0; border: none !important; }
	:is(#page, .editor-styles-wrapper) .bl-menu-table tr { display: block; padding: 1.2rem 0; border-top: 1px solid rgba(58, 16, 24, 0.15); }
	:is(#page, .editor-styles-wrapper) .bl-menu-table tr:last-child { border-bottom: 1px solid rgba(58, 16, 24, 0.15); }
	:is(#page, .editor-styles-wrapper) .bl-menu-table tr:last-child td { border-bottom: none !important; }
	:is(#page, .editor-styles-wrapper) .bl-menu-table td:last-child { text-align: left; margin-top: 0.4rem; }
}

/* ==========================================================================
   8. HOMEPAGE SECTIONS — for the approved homepage design canvas (2026-09).
      Every other homepage section (hero, the two split media+copy bands,
      the pull quote, the sister-restaurant callout) reuses plain wp:cover
      + wp:media-text/wp:quote blocks and this site's own existing
      textColor:"black"-on-a-light-cover / unset-on-a-dark-one convention
      (see §3's note on why: WP core's own `.wp-block-cover { color:#fff }`
      default needs an explicit override on light bands, and doesn't on
      dark ones) — same as every cover already in this page's real content.
      The handful of components below have no ready native-block equivalent
      and get their own classes; all colors set here are direct + defensive
      `!important` (never relying on a textColor attribute/`.has-black-
      color` to land the right color), so nothing here depends on which
      core color preset a block happens to carry.
   ========================================================================== */

/* --- small-caps label above a hero/split heading --- */
.bl-eyebrow {
	display: inline-block;
	font-size: 0.8rem;
	letter-spacing: 0.22em;
	text-transform: uppercase;
	color: var(--bl-brass-ink) !important;
	margin-bottom: 0.75rem;
}
.wp-block-cover .bl-eyebrow {
	color: var(--bl-brass-light) !important;
}

/* --- accolades / press-quote row ("From Le Buzz — What Critics Are
   Saying"), light parchment-deep band. WCAG 2.2 AA against #e6d9bd,
   computed: charcoal quote text ≈ 11.3:1, brass-ink source label ≈ 4.9:1
   (both already used/checked the same way for §7's merch table). --- */
/* Not uppercase like `.bl-eyebrow`'s short 1-3-word labels elsewhere
   (e.g. "The Place — Est. 1995") — this one's a full sentence with a
   real link in it ("From Critic's Reviews — What They're Saying"), and
   forcing a hyperlinked proper noun to render all-caps mid-sentence
   read as shouting rather than a design flourish. Kept the wide
   letter-spacing tuned down to something sane for mixed-case running
   text instead of the all-caps-tuned 0.2em. */
.bl-accolades-eyebrow {
	display: block;
	text-align: center;
	font-size: 0.75rem;
	letter-spacing: 0.04em;
	color: var(--bl-brass-ink) !important;
	margin-bottom: 1.75rem;
}
.bl-accolades-row {
	display: flex;
	flex-wrap: wrap;
	justify-content: center;
	max-width: 1100px;
	margin: 0 auto;
}
.bl-accolade {
	flex: 1 1 220px;
	max-width: 260px;
	text-align: center;
	padding: 0 1.5rem;
	border-left: 1px solid rgba(122, 82, 32, 0.3);
}
.bl-accolade:first-child { border-left: none; }
.bl-accolade-quote {
	display: block;
	font-family: "EB Garamond", Georgia, serif;
	font-style: italic;
	font-size: 1.05rem;
	line-height: 1.35;
	color: var(--bl-charcoal) !important;
}
.bl-accolade-source {
	display: block;
	margin-top: 0.6rem;
	font-size: 0.72rem;
	letter-spacing: 0.1em;
	text-transform: uppercase;
	color: var(--bl-brass-ink) !important;
}
@media screen and (max-width: 700px) {
	.bl-accolade { border-left: none; border-top: 1px solid rgba(122, 82, 32, 0.3); padding: 1.5rem 1rem 0; margin-top: 1.5rem; }
	.bl-accolade:first-child { border-top: none; margin-top: 0; padding-top: 0; }
}

/* --- News & Offers cards. Sits on the same light cover the section
   already used before this pass; card face is the slightly lighter plain
   parchment so it reads as a raised card against the parchment-deep band
   behind it. WCAG 2.2 AA against parchment: ink-soft body text ≈ 5.6:1
   (computed), heading wine ≈ 8:1+. --- */
.bl-offer-row {
	display: grid;
	grid-template-columns: repeat(3, minmax(0, 1fr));
	gap: 1.5rem;
	max-width: 1000px;
	margin: 2.5rem auto 0;
}
@media screen and (max-width: 800px) {
	.bl-offer-row { grid-template-columns: 1fr; }
}
.bl-offer-card {
	background-color: var(--bl-parchment) !important;
	border: 1px solid rgba(58, 16, 24, 0.15);
	border-radius: 2px;
	padding: 2rem 1.5rem;
	text-align: center;
}
.bl-offer-card .wp-block-heading {
	color: var(--bl-wine) !important;
	font-size: 1.2rem;
	margin: 0 0 0.5rem;
}
.bl-offer-card p {
	color: var(--bl-ink-soft) !important;
	font-size: 0.92rem;
	margin: 0 0 1.25rem;
	line-height: 1.5;
}

/* --- Hours table, dark wine band: the same recipe §7's .bl-menu-table
   used before that table's OWN band went light (cream text/links, thin
   cream-tinted dividers) — reused here for the band that recipe was
   originally written for. --- */
.bl-hours-table {
	width: 100%;
	border-collapse: collapse;
}
:is(#page, .editor-styles-wrapper) .bl-hours-table td {
	padding: 0.9rem 0;
	border: none !important;
	border-bottom: 1px solid rgba(243, 233, 210, 0.2) !important;
	vertical-align: baseline;
	color: var(--bl-cream-text);
}
:is(#page, .editor-styles-wrapper) .bl-hours-table tr:last-child td {
	border-bottom: none !important;
}
.bl-hours-table td:first-child {
	font-family: "EB Garamond", Georgia, serif;
	font-size: 1.1rem;
}
.bl-hours-table td:last-child {
	text-align: right;
	font-variant-numeric: tabular-nums;
}
.bl-hours-notes p { margin: 0 0 0.9rem; color: var(--bl-cream-text) !important; }
.bl-hours-notes a { color: var(--bl-brass-light) !important; text-decoration: underline; }
.bl-hours-notes a:hover, .bl-hours-notes a:focus { color: var(--bl-cream-text) !important; }
@media screen and (max-width: 600px) {
	:is(#page, .editor-styles-wrapper) .bl-hours-table td { display: block; width: 100% !important; padding: 0.2rem 0; border: none !important; }
	:is(#page, .editor-styles-wrapper) .bl-hours-table tr { display: block; padding: 1rem 0; border-top: 1px solid rgba(243, 233, 210, 0.2); }
	:is(#page, .editor-styles-wrapper) .bl-hours-table tr:first-child { border-top: none; }
	:is(#page, .editor-styles-wrapper) .bl-hours-table td:last-child { text-align: left; margin-top: 0.3rem; }
}

/* --- Outline-style CTA buttons ("Discover The Place" / "See Wine &
   Cocktails" / each offer card's "View Menu") — the same wp:button block
   as every filled brass button elsewhere, told apart only by one of these
   two classNames, which the block editor puts on the OUTER `.wp-block-
   button` wrapper div, not the inner `.wp-element-button` link itself —
   hence the descendant (space) combinator below, not a compound selector;
   a compound `.bl-btn-outline-dark.wp-element-button` never matches
   anything, since no single element carries both classes, and the button
   silently fell through to §4's filled-brass default the first time this
   was written that way. Both need !important: §4's filled-button rule
   targets the exact same `.wp-element-button`, at the same specificity,
   and would otherwise win the tie by sitting later in this same file.
   WCAG 2.2 AA checked: cream on transparent-over-wine ≈ 13.7:1 (dark
   variant, same figure as §6's header text); brass-ink on parchment
   ≈ 4.9:1 (light variant, same figure as §7's merch-table links) — the
   light variant's hover (parchment text on a brass-ink fill) is that
   identical pair reversed, so the same ≈4.9:1. */
:is(#page, .editor-styles-wrapper) .bl-btn-outline-dark .wp-element-button {
	background-color: transparent !important;
	color: var(--bl-cream-text) !important;
	border: 1px solid var(--bl-cream-text) !important;
}
:is(#page, .editor-styles-wrapper) .bl-btn-outline-dark .wp-element-button:hover {
	background-color: rgba(243, 233, 210, 0.12) !important;
	color: var(--bl-brass-light) !important;
	border-color: var(--bl-brass-light) !important;
}
:is(#page, .editor-styles-wrapper) .bl-btn-outline-light .wp-element-button {
	background-color: transparent !important;
	color: var(--bl-brass-ink) !important;
	border: 1px solid var(--bl-brass-ink) !important;
}
:is(#page, .editor-styles-wrapper) .bl-btn-outline-light .wp-element-button:hover {
	background-color: var(--bl-brass-ink) !important;
	color: var(--bl-parchment) !important;
	border-color: var(--bl-brass-ink) !important;
}

/* --- pull-quote band (Bruno Fortin's own words), dark wine-deep band.
   Overrides core's wp:quote left-border-and-indent styling in favor of a
   plain centered, italic treatment; cream/brass-light already checked at
   ≈13.7:1/≈8.6:1+ against wine everywhere else in this file, and wine-deep
   is darker still, so both are safely higher here.

   The block editor showed this correctly (EB Garamond, italic, the larger
   clamp() size) while the real front end fell back to Twenty Twenty-One's
   own plain sans-serif body copy at its default size — same root cause as
   every other tie noted throughout this file: Twenty Twenty-One's own
   `.wp-block-quote p`/`cite` rules (block-library/style.css) match at the
   same specificity as the plain `.bl-quote-band-quote p`/`cite` written
   here, and the host's Newfold/HostGator plugin duplicating the parent
   stylesheet a second time after this one hands that tie to Twenty
   Twenty-One on source order — it just never showed up until a rule here
   had a font (not just a color) riding on winning that tie. Only `color`
   had `!important` before; `:is(#page, .editor-styles-wrapper)` plus
   `!important` on the rest fixes it the same way §4/§7 already do. */
.bl-quote-band-quote {
	max-width: 30em;
	margin: 0 auto;
	border: none !important;
	padding: 0 !important;
	text-align: center;
}
/* Twenty Twenty-One draws its own large decorative curly quote mark via
   `.wp-block-quote::before` — doubling up with the literal &ldquo;/&rdquo;
   already typed into this quote's own text (visible as a small stray mark
   sitting just before the real opening quote, in the wrong font/size).
   Suppressing it here rather than removing the literal entities, since
   those are the ones actually styled to match this band's serif/italic
   treatment. */
.bl-quote-band-quote::before,
.bl-quote-band-quote::after {
	content: none !important;
}
:is(#page, .editor-styles-wrapper) .bl-quote-band-quote p {
	font-family: "EB Garamond", Georgia, serif !important;
	font-style: italic !important;
	font-weight: 400 !important;
	font-size: clamp(1.5rem, 3.2vw, 2.1rem) !important;
	line-height: 1.35 !important;
	color: var(--bl-cream-text) !important;
	margin: 0;
}
:is(#page, .editor-styles-wrapper) .bl-quote-band-quote cite {
	display: block;
	margin-top: 1.25rem;
	font-family: "EB Garamond", Georgia, serif !important;
	font-style: normal !important;
	font-size: 0.95rem !important;
	letter-spacing: 0.06em;
	text-transform: uppercase;
	color: var(--bl-brass-light) !important;
}

/* ==========================================================================
   9. LE BUZZ PAGINATION SPACING — Twenty Twenty-One's own "Page 1 / Page 2 /
   Older posts" nav (`.navigation.pagination`, rendered by home.php's posts
   loop on Le Buzz) carries zero bottom margin/padding of its own, and it's
   the last element inside <main> before the footer begins — so it sits
   flush against the dark footer band with no breathing room at all.
   Matches this theme's own spacing scale (`--wp--preset--spacing--60`,
   the same value used for Cover-block section padding elsewhere) rather
   than a one-off pixel value. */
.navigation.pagination {
	padding-bottom: var(--wp--preset--spacing--60);
}

/* ==========================================================================
   10. LAYOUT SHIFT WHEN THE POPUP MAKER OVERLAY OPENS — the Popup Maker
   plugin's own CSS sets `html.pum-open.pum-open-overlay { overflow: hidden }`
   the moment its auto-open popup fires (see plugins/popup-maker/dist/assets/
   site-readable.css), which removes the scrollbar and lets the whole page
   reflow ~15-17px wider — a visible jump of the header/nav/everything else
   right as the popup appears. Popup Maker DOES have its own compensating
   `padding-right` rule for this, but it only applies when a popup's
   "Scrollable Content" setting is ON (`html.pum-open...pum-open-scrollable`)
   — this site's popup(s) use the default OFF setting, so that compensation
   never kicks in. Rather than toggle that per-popup setting (changes the
   popup's own scroll behavior) or hardcode a matching padding-right guess
   (Popup Maker's own 15px doesn't necessarily match every browser's actual
   scrollbar width), `scrollbar-gutter: stable` permanently reserves the
   scrollbar's space whether or not a scrollbar is currently needed — so
   `overflow: hidden` removing the scrollbar never changes the page's
   available width in the first place. One-line, CSS-only, no dependency on
   Popup Maker's settings. (Not supported in Safari < 18.2 as of this
   writing — those browsers just keep the pre-existing shift, no worse than
   before.) */
html {
	scrollbar-gutter: stable;
}