/*
Theme Name: Davis Plumbing
Theme URI: https://www.davisplumbingservice.com/
Author: Josh Thomas
Description: Davis Plumbing & Drain Service. Built on the Canvas HTML template
  (SemiColonWeb, ThemeForest). Markup is generated from the approved design by
  bin/build_theme.py — regenerate rather than hand-editing header/footer/front-page.
Version: 0.1.7
Requires at least: 6.5
Tested up to: 7.0
License: GNU General Public License v2 or later
Text Domain: davis-plumbing
*/

/* Canvas's own stylesheets are enqueued in functions.php. This file is the
   theme header WordPress requires, plus anything that must beat Canvas. */

/* ---------------------------------------------------------------------------
   WordPress block layout vs Bootstrap
   ---------------------------------------------------------------------------
   core/group emits `is-layout-flow`, and WordPress injects
   `> * + * { margin-block-start: var(--wp--style--block-gap, 24px) }` for
   vertical rhythm. Canvas already owns spacing inside its own sections, so that
   24px is a double-space — it made the promo band 168px against the design's
   150px and both feature-box grids 24px too tall.

   Zero the GAP VARIABLE rather than the margin. Setting `margin-block-start: 0`
   here was the obvious fix and it was wrong: at specificity (0,2,0) it also beat
   Canvas's own `.fbox-content p { margin-top: 16px }` at (0,1,1), so the grids
   went from 24px too tall to 16px too short. Killing the variable leaves
   Canvas's rules to apply normally.
   ------------------------------------------------------------------------ */
#content .wp-block-group,
#content.wp-block-group {
	--wp--style--block-gap: 0px;
}

/* ...and the rule that actually does the damage.

   WordPress does not read that variable here. The global stylesheet emits

       :root :where(.is-layout-flow) > * { margin-block-start: 24px; ... }

   with the value baked in — measured: --wp--style--block-gap computed to 0px
   while .fbox-content still had margin-top: 24px.

   Specificity is the whole game. That selector is (0,1,0) — `:root` is a
   pseudo-class, `:where()` contributes nothing. So:
     * a `:where()` reset at (0,0,0) loses to it (tried; no effect)
     * `.wp-block-group.feature-box > *` at (0,2,0) beats it but ALSO beats
       Canvas's own `.fbox-content p { margin-top: 16px }` at (0,1,1), which
       swung the grids from 24px too tall to 16px too short
   Matching it exactly at (0,1,0) and relying on source order — this sheet is
   enqueued after WordPress's global styles — wins against WordPress and loses
   to Canvas, which is precisely what is wanted. */
:where(#content) .wp-block-group:where(:not(.content-wrap)) > * {
	margin-block-start: 0;
}
/* Top-level sections: Canvas's `.section { margin: var(--cnvs-section-margin) 0 }`
   is (0,1,0) and its sheet loads after WordPress's global styles, so sections
   already win — measured 64px on both. A plain `.container` has no Canvas margin
   rule at all, so WordPress's 24px applied unopposed and pushed everything below
   it down by 24px twice over. */
:where(#content .content-wrap) > .container {
	margin-block-start: 0;
}

/* The other half of that rule — `margin-block-end: 0` — silently killed Canvas's
   negative row margin. Canvas pulls a grid up by its gutter with
       [class*=col-mb-] { margin-bottom: calc(var(--cnvs-col-mb) * -1) }
   which is also (0,1,0); asking the browser which rules actually matched showed
   ONLY WordPress's two, so the -50px never applied and every section below the
   feature grid sat 50px too low. Restated here, after WordPress's, so it wins. */
/* `#content` NOT wrapped in :where() here. :where() zeroes the specificity of
   its contents, which left this at (0,1,0) — a tie with WordPress's rule that it
   did not reliably win. Unwrapped it is (1,1,0) and unambiguous, and there is no
   competing Canvas rule to trample: this restates Canvas's own declaration. */
#content [class*="col-mb-"] {
	margin-block-end: calc(var(--cnvs-col-mb) * -1);
}

/* :where(:not(.content-wrap)) — zero-specificity exclusion, so the selector
   stays (0,1,0). Without it the reset also zeroed the top-level sections'
   own `.section { margin: var(--cnvs-section-margin) 0 }`, which is ALSO
   (0,1,0) and therefore loses on source order: every section below the fold
   crept 14px up, 28px cumulative by the footer. */

/* ---------------------------------------------------------------------------
   Canvas selectors that assume the original tag
   ---------------------------------------------------------------------------
   Canvas styles the promo sub-line as `.promo h3 + span` — display:block,
   font-weight:300, --cnvs-promo-span-font-size, margin-top:6px. core/paragraph
   emits <p>, so none of that applied: the sub-line rendered at 16px with no top
   margin instead of 18px + 6px, and the band came out 146px against 153px.

   This is the general shape of the problem when porting a hand-written HTML
   theme to blocks — any CSS keyed to a specific tag needs a companion selector
   for whatever the block outputs. Values mirror Canvas's own, via its variables.
   ------------------------------------------------------------------------ */
/* `.wp-block-group.promo` and not just `.promo`: the block-layout rule above is
   `.wp-block-group[class*="col-"] > *` at specificity (0,2,0), which outranks a
   plain `.promo h3 + p` at (0,1,2) and was zeroing this margin-top back to 0.
   line-height is set explicitly because <span> did not inherit the body's 1.65
   the way <p> does. */
.wp-block-group.promo h3 + p,
.wp-block-group.promo .h3 + p,
.promo h3 + p,
.promo .h3 + p {
	display: block;
	color: var(--cnvs-promo-light-text-color);
	font-weight: 300;
	font-size: var(--cnvs-promo-span-font-size);
	line-height: 1.5;
	margin-top: 6px;
}
.promo-dark h3 + p,
.promo-dark .h3 + p { color: var(--bs-gray-100); font-weight: 400; }

/* ---------------------------------------------------------------------------
   Long-form inner pages (page-service.php, page-area.php)
   ---------------------------------------------------------------------------
   Canvas gives every heading `margin: 0 0 30px` and no top margin. That is right
   for its own sections, where a heading opens a box that already has padding
   above it, and wrong for an article: the client's service copy runs to 1,076
   words broken by a dozen <h3> sub-heads, and with no leading gap each sub-head
   sits closer to the paragraph it follows than to the one it introduces, so the
   page reads as one undifferentiated column.

   Element selectors under Canvas's own .postcontent — no new class contract, and
   nothing outside the two long-form templates is touched. The gap is derived
   from Canvas's own --cnvs-section-margin so it tracks the theme's spacing scale
   rather than being a magic number.

   Specificity: `.postcontent > h3` is (0,1,1). It beats Canvas's own bare
   `h1, h2, h3 …` at (0,0,1), and it only adds margin-top — a property Canvas
   does not set on headings — so nothing of Canvas's is overridden. WordPress's
   `:root :where(.is-layout-flow) > *` at (0,1,0) does not reach here at all:
   the_content()'s top-level output is not inside a layout container.
   ------------------------------------------------------------------------ */
.postcontent > h2,
.postcontent > h3,
.postcontent > h4,
.postcontent > h5 {
	margin-top: calc(var(--cnvs-section-margin) * 0.75);
}
/* The first block sits directly under the page-title hero, which brings its own
   space; a leading margin there only opens a gap at the top of the column. */
.postcontent > :first-child {
	margin-top: 0;
}