below
the card). As a sibling it sat on the plain page background, but its
dark-variant color (translucent white) assumed a dark background --
nearly invisible against white, which is what "isn't readable"
actually was. Nesting it in the card means its color is always
correct for whatever background it's actually on, and its spacing is
controlled by normal flow instead of a negative-margin hack (which
was also the mobile overlap-with-a-label complaint -- that margin was
tuned for the old sibling layout, not this one). */
display: block;
margin: 1.75rem 0 0;
font-size: 0.8rem;
color: #777;
}
.dwh-stats-source a {
color: var(--dwh-teal-dark);
}
/* Dark-card variant, chosen after comparison against the default
plain-on-page look above -- add "dwh-stats-strip--dark" alongside
"dwh-stats-strip" on the wrapping div in embed-home-stats.html to use
this instead. --dwh-teal-deepest (now on :root, see top of file)
matches dogwood-hero.css's own --dw-teal-deepest, so this reads as the
same brand darkest-teal, not a new color invented just for this card. */
.dwh-stats-strip--dark {
background: var(--dwh-teal-deepest);
border-radius: 14px;
box-shadow: 0 8px 24px rgba(5, 46, 57, 0.35);
}
.dwh-stats-strip--dark .dwh-stats-title {
color: #fff;
}
.dwh-stats-strip--dark .dwh-stat-number {
/* teal-light, not gold -- gold's already doing CTA duty on the hero and
DONATE buttons; a third use here would dilute it as "the one accent
color". This reuses the hero's own lighter teal stop instead, so the
highlight still reads as a deliberate brand color, not just "brightest
text available". Requested 2026-08-30. */
color: #2a9cc1;
}
.dwh-stats-strip--dark .dwh-stat-label {
color: rgba(255, 255, 255, 0.85);
}
.dwh-stats-strip--dark .dwh-stats-source {
color: rgba(255, 255, 255, 0.7);
}
.dwh-stats-strip--dark .dwh-stats-source a {
color: #fff;
}
/* ---------------------------------------------------------------------
7b. Stats + video as one 40/60 row, requested 2026-08-30. Was: stats
card, then cards row, then video, each full-width and stacked. Now:
cards row, then this row (stats 40% / video 60%), then newsletter/
partners -- the cards row keeps its position right after DONATE, stats
and video are what moved to sit together. The 3 stat numbers stack to a
single column even at desktop here (repeat(3,1fr) was too cramped at
~40% of the content width) -- .dwh-video-frame's own max-width/margin
are reset since the row's grid track sizing replaces them.
------------------------------------------------------------------- */
.dwh-stats-video-row {
display: grid;
grid-template-columns: 2fr 3fr;
gap: 1.5rem;
/* stretch, not start (was start) -- requested 2026-08-30: at full
content width the two cards happened to land close in height, but
compressing the window (stats card's text reflows to more lines
faster than the video shrinks) pulled them apart oddly. Stretch makes
both grid items always fill the row's height, whatever that is at
any given width, instead of each sizing purely to its own content. */
align-items: stretch;
margin: 2.5rem 0;
}
.dwh-stats-video-row .dwh-stats-strip {
margin: 0;
}
.dwh-stats-video-row .dwh-stats-grid {
grid-template-columns: 1fr;
gap: 1.25rem;
}
/* ---------------------------------------------------------------------
7c. Video card, requested 2026-08-30: the bare 16:9 video sitting next
to the taller stats card left an empty gap below it in its column --
read as "something's missing" rather than a deliberately paired row.
Framing it in a card matching the stats card's own dark treatment
(title + rule + content, same as the stats side) gives it real content
parity instead of just padding it out to match height artificially.
------------------------------------------------------------------- */
.dwh-video-card {
background: var(--dwh-teal-deepest);
border-radius: 14px;
box-shadow: 0 8px 24px rgba(5, 46, 57, 0.35);
padding: 2rem;
text-align: center;
}
/* .dwh-stats-title/.dwh-stats-rule are reused here on purpose rather than
duplicated under video-specific names -- same title+rule pattern, same
visual treatment, no reason to fork it. The title defaults to
--dwh-teal-dark (see .dwh-stats-title), fine against the light plain
card but low-contrast on this card's own dark background -- overridden
to white here the same way .dwh-stats-strip--dark does for its title. */
.dwh-video-card .dwh-stats-title {
color: #fff;
}
.dwh-video-caption {
font-size: 0.95rem;
color: rgba(255, 255, 255, 0.85);
margin: 0;
}
/* Both cards made flex columns, SCOPED to being inside the row (not on
.dwh-stats-strip/.dwh-video-card generally, which are also used
standalone elsewhere where flex isn't needed) -- this is what lets
align-items:stretch above actually produce equal-height cards: with
display:grid's default block-level children, "stretch" only stretches
the outer box, it doesn't make the video frame grow to fill that extra
height. flex-direction:column + flex:1 on the frame does. */
.dwh-stats-video-row .dwh-stats-strip,
.dwh-stats-video-row .dwh-video-card {
display: flex;
flex-direction: column;
}
.dwh-stats-video-row .dwh-video-frame {
flex: 1;
/* aspect-ratio dropped (see base .dwh-video-frame rule) so the iframe's
box can actually grow/shrink to match the stats card's height instead
of being locked to 16:9 regardless of available space. YouTube's
player letterboxes its own content inside whatever box it's given, so
the video itself doesn't visibly distort -- only the surrounding
iframe box's proportions change. */
aspect-ratio: unset;
margin: 0 0 1.25rem;
max-width: none;
}
@media (max-width: 700px) {
/* width/max-width/box-sizing added 2026-09-01 -- a beta tester found a
real, reproducible bug: load in portrait (fine) -> rotate to
landscape (fine, this row correctly switches to the desktop 2-column
grid at that width) -> rotate back to portrait -> the row now
overflows horizontally instead of re-stacking to 1 column. This is a
known WebKit quirk category: .dwh-video-frame's width below was left
IMPLICIT (inherited from the flex item's default stretch-to-parent
behavior) rather than stated as an explicit value. In the desktop/
landscape pass, .dwh-video-frame is flex:1 with aspect-ratio:unset
(see that rule) and gets a real pixel width from the grid's 3fr
track; iOS Safari can retain that resolved width as the frame's
"used size" across the next layout pass instead of correctly
re-deriving it from the now-1-column grid, and since aspect-ratio:
16/9 is what applies at this breakpoint, a stale wide width forces a
correspondingly wide computed height too -- the whole box (and this
row along with it, since nothing above was clamping it either)
renders wider than the viewport. Explicit width:100% on both the row
and the frame gives Safari an unambiguous value to resolve on every
layout pass instead of one it might carry over from a different
grid-column-count state. */
.dwh-stats-video-row {
grid-template-columns: 1fr;
width: 100%;
max-width: 100%;
box-sizing: border-box;
}
.dwh-stats-grid {
grid-template-columns: 1fr;
gap: 1.5rem;
}
.dwh-stats-strip {
padding: 2rem 1.5rem;
width: 100%;
max-width: 100%;
box-sizing: border-box;
}
.dwh-video-card {
padding: 1.75rem 1.25rem;
width: 100%;
max-width: 100%;
box-sizing: border-box;
}
/* Fixes a real bug introduced by the equal-height change above:
.dwh-video-frame's flex:1 + aspect-ratio:unset only produces a
height when something external (the desktop row's align-items:
stretch, sized off the stats card) gives the flex container real
space to grow into. Stacked to one column here, there's no such
external height and no aspect-ratio fallback either, so the frame
collapsed to ~0 height -- the video wasn't broken, it was rendering
at zero size. Restoring a fixed aspect-ratio here (stretch-matching
doesn't apply to a stacked, non-side-by-side layout anyway) gives it
a real height again independent of flex-grow. */
.dwh-stats-video-row .dwh-video-frame {
flex: none;
aspect-ratio: 16 / 9;
width: 100%;
max-width: 100%;
box-sizing: border-box;
}
}
@media (max-width: 700px) {
.entry-content .wp-block-buttons:has(> .wp-block-button > a.wp-block-button__link[href="https://dogwoodanimalrescue.org/donate/"])
> .wp-block-button > a.wp-block-button__link {
padding: 0.75rem 2rem !important;
font-size: 0.95rem;
}
.entry-content > .organic-block-widget-area {
grid-template-columns: 1fr;
padding: 1.75rem 0;
gap: 1.25rem;
}
#custom_html-27,
#custom_html-37,
#custom_html-38 {
padding: 1.75rem 1.25rem 1.5rem;
}
#n2-ss-24-align img {
max-height: 60px;
}
#bloomwidget-12 {
padding: 2rem 1.25rem;
}
}
/* =======================================================================
8. (Breakout, added 2026-08-30) Equivalent styling for the About/
Support/Donation cards and the intro video AS STANDALONE PAGE BLOCKS,
for pasting via embed-home-cards.html / embed-home-video.html --
requested because editing widgets in that shared "Organic Widget Area
Block" widget area was too painful, so cards/video/partners are moving
to be plain Custom HTML blocks directly on the page instead.
ADDITIVE ON PURPOSE: the #custom_html-27/-37/-38 and #block-5 rules
above (sections 2 and 5) are left in place, not removed, so the
CURRENTLY LIVE widget-based cards/video keep working and looking
correct right up until the swap is actually made and confirmed. Once
that's done, sections 2's card/icon rules, #block-5's rule, and the
#custom_html-27/-38 mobile-padding rule above all become dead code --
ask Claude to clean those up in one pass rather than deleting them
piecemeal mid-migration.
POSITIONING NOTE: once cards/video/partners (and the stats strip, if
also moved) are plain sequential Custom HTML blocks, none of them need
the grid/order/:has() machinery sections 2 and 7 use to fake a position
inside the shared widget area -- normal block order in the editor IS
the visual order now. Just drag these new blocks into the sequence you
want (cards, then stats, then video, then partners, matching what's
live now, or any other order).
======================================================================= */
.dwh-cards-row {
display: grid;
grid-template-columns: repeat(3, 1fr);
gap: 1.5rem;
margin: 2.5rem 0;
}
.dwh-card {
background: #bcd6e6;
border: 1px solid var(--dwh-teal-tint);
border-radius: 14px;
box-shadow: 0 4px 14px rgba(10, 91, 121, 0.08);
padding: 2rem 1.5rem 1.75rem;
text-align: center;
/* flex column, requested 2026-09-01 so the three su-buttons line up at
the same height across all three cards regardless of how much
paragraph text each card has. .dwh-cards-row's grid already stretches
all three cards to equal height (default align-items:stretch on a
grid row) -- this just needed the button pushed to the bottom of that
already-equal height, which .dwh-card p's flex:1 below does. Markup
changed to match: the button is now its own element after , not
inline content inside the same separated by
-- a flex
item has to be a direct child to be individually positioned, and
inline content inside a paragraph can't be pinned to the bottom on
its own. See embed-home-full.html's cards for the updated markup. */
display: flex;
flex-direction: column;
}
.dwh-card p {
flex: 1 0 auto;
margin: 0 0 1.25rem;
}
.dwh-card .su-button {
/* Without this the button, now a flex item like h2/p, would stretch to
the card's full width (align-items' default is stretch) instead of
staying a natural-width pill. */
align-self: center;
}
/* EB Garamond, requested 2026-08-30 -- trying it across every heading on
the page except "The Dogwood Dish" (Dancing Script, kept as-is). These
three ("About Dogwood"/"SUPPORT US!"/"MAKE A DONATION") had no explicit
font-family before, just inheriting the theme's body font. !important
given every other h2 on this page has needed it to beat the theme's
`.entry-content h2` rule on one property or another so far. */
.dwh-card h2 {
font-family: "EB Garamond", Georgia, serif !important;
/* 600, matching .dwh-stats-title's 2026-09-01 change -- see that rule's
comment. Previously unset here, which meant the browser's own default
bold (700) for
was winning, same "too heavy" issue. */
font-weight: 600 !important;
}
.dwh-card h2::before {
content: "";
display: block;
width: 44px;
height: 44px;
margin: 0 auto 0.75rem;
background-size: contain;
background-repeat: no-repeat;
background-position: center;
}
.dwh-card--about h2::before {
/* house/rescue icon, brand teal -- same icon as #custom_html-27 above */
background-image: url("data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2024%2024'%20fill='rgb(10,91,121)'%3E%3Cpath%20d='M12%203%202%2012h3v8h6v-5h2v5h6v-8h3z'/%3E%3C/svg%3E");
}
.dwh-card--support h2::before {
/* heart icon, red -- changed 2026-08-30 from brand teal to match the
heart emoji (❤️) in the hero's tagline. rgb(224,34,41) approximates
the red heart emoji's actual rendered color (Apple Color Emoji, the
platform this project is built/reviewed on) -- not a brand token,
specifically chosen to visually match that one emoji.
Path replaced 2026-08-30 -- the hand-drawn path used until now (the
one also still sitting in the dead #custom_html-37 rule above, for
reference/comparison) was subtly asymmetric: traced by hand rather
than from a real icon source, it read as crooked/flattened on the
right side on close inspection, not just a viewBox-clipping issue
(the earlier "-1 -1 26 26" widened viewBox masked the symptom rather
than fixing the actual cause). Replaced with Font Awesome's solid
heart glyph (viewBox 0 0 512 512) instead of attempting another
hand-drawn path -- a real, published, properly mirrored icon design
rather than another guess at one. */
background-image: url("data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%20512%20512'%20fill='rgb(224,34,41)'%3E%3Cpath%20d='M462.3%2062.6C407.5%2015.9%20326%2024.3%20275.7%2076.2L256%2096.5%20236.3%2076.2C186%2024.3%20104.5%2015.9%2049.7%2062.6c-62.8%2053.6-66.1%20149.8-9.9%20207.9l193.5%20199.8c12.5%2012.9%2032.8%2012.9%2045.3%200l193.5-199.8c56.3-58.1%2053-154.3-9.8-207.9z'/%3E%3C/svg%3E");
}
.dwh-card--donate h2::before {
/* gift icon, gold -- same icon as #custom_html-38 above, still the one
card that's the direct-donation CTA */
background-image: url("data:image/svg+xml,%3Csvg%20xmlns='http://www.w3.org/2000/svg'%20viewBox='0%200%2024%2024'%20fill='rgb(232,163,61)'%3E%3Crect%20x='3'%20y='9'%20width='18'%20height='11'%20rx='1'/%3E%3Crect%20x='3'%20y='6'%20width='18'%20height='4'%20rx='1'/%3E%3Crect%20x='11'%20y='2'%20width='2'%20height='18'/%3E%3C/svg%3E");
}
.dwh-video-frame {
position: relative;
max-width: 800px;
margin: 2.5rem auto;
aspect-ratio: 16 / 9;
border-radius: 14px;
overflow: hidden;
box-shadow: 0 8px 24px rgba(10, 91, 121, 0.16);
}
.dwh-video-frame iframe {
position: absolute;
inset: 0;
width: 100%;
height: 100%;
border: 0;
}
@media (max-width: 700px) {
.dwh-cards-row {
grid-template-columns: 1fr;
gap: 1.25rem;
margin: 1.75rem 0;
}
.dwh-card {
padding: 1.75rem 1.25rem 1.5rem;
}
}
/* ---------------------------------------------------------------------
9. (Breakout) Standalone DONATE button, own class instead of the
:has()-on-a-Gutenberg-block selector in section 1 -- that selector
depended on the button being the native wp-block-button block section
1 was written against. Once the whole page is hand-authored HTML (see
embed-home-full.html), a plain class is simpler and more robust than
re-deriving a :has() hook for whatever block markup happens to wrap it.
Same gold-pill visual result as section 1's rule.
------------------------------------------------------------------- */
.dwh-donate-cta {
/* display:block + width:50% (was inline-block, sized to just fit
"DONATE") added 2026-08-30 -- the original button this replaced was
a core Gutenberg wp-block-button__width-50 block, 50% of the
available content width regardless of how short the label was. The
breakout version lost that -- it's been sized to its own padding/text
since it stopped being that block. Restored the original proportions
here instead of just the color/shape. */
display: block;
width: 50%;
margin: 0 auto;
box-sizing: border-box;
background-color: var(--dwh-gold);
color: var(--dwh-gold-text) !important;
border: none;
border-radius: var(--dwh-radius-pill);
padding: 0.9rem 2.75rem;
font-family: "Poppins", "Open Sans", Helvetica, Arial, sans-serif;
font-weight: 800;
font-size: 1.05rem;
letter-spacing: 0.02em;
text-decoration: none;
text-align: center;
box-shadow: 0 6px 16px rgba(10, 91, 121, 0.18);
transition: transform 0.15s ease, box-shadow 0.15s ease;
}
/* :visited called out explicitly (and !important added above too),
requested 2026-08-30: after clicking through once, the button read as
light grey on gold -- unreadable. The theme almost certainly carries
its own a:visited rule (a common pattern for distinguishing visited
links in body text) with higher specificity than a plain .dwh-donate-
cta class, which for a *button* rather than a text link is exactly the
wrong behavior. Every interactive state gets the same explicit gold-
text color so none of them can independently regress like this again. */
.dwh-donate-cta:visited,
.dwh-donate-cta:hover,
.dwh-donate-cta:visited:hover,
.dwh-donate-cta:active,
.dwh-donate-cta:focus {
color: var(--dwh-gold-text) !important;
}
.dwh-donate-cta:hover {
transform: translateY(-2px);
box-shadow: 0 10px 20px rgba(10, 91, 121, 0.24);
}
.dwh-donate-wrap {
text-align: center;
margin: 0.5rem 0 2rem;
}
@media (max-width: 700px) {
.dwh-donate-cta {
padding: 0.75rem 2rem;
font-size: 0.95rem;
}
}
/* ---------------------------------------------------------------------
10. (Breakout) Newsletter gradient card, own class instead of
#bloomwidget-12 -- same visual treatment as section 6 (gradient band,
Bloom's own form floating inside, not restyled internally), just keyed
to a class this project controls instead of Bloom's auto-generated
widget ID, since embed-home-full.html places the [bloom_inline]
shortcode directly rather than through the widget system.
------------------------------------------------------------------- */
.dwh-newsletter-wrap {
background: linear-gradient(135deg, var(--dwh-teal-dark), var(--dwh-teal-medium));
border-radius: 14px;
/* top padding trimmed 2026-08-30 (was 2.5rem all around) -- part of
shrinking the visible teal space above the white form box, alongside
.dwh-newsletter-title's more negative margin-bottom below. */
padding: 1.5rem 1.5rem 2.5rem;
margin: 2.5rem 0;
}
/* Bloom's own internal padding, requested 2026-08-30: measured live (not
guessed) at .et_bloom_form_header (15px top / 25px bottom) and
.et_bloom_form_content (40px top AND bottom -- around a form that's
only ~41px tall itself), injected via Bloom's own per-instance