/* Fixes for core WordPress blocks (Columns/Buttons) used across multiple
   pages/patterns, not specific to any one component. */

/* Column shrinks below a usable width in some layouts without this floor. */
/* .wp-block-column.is-layout-flow.wp-block-column-is-layout-flow {
	min-width: 320px;
} */

/* Custom-width buttons inside that column don't need their own left/right
   padding on top of the width already being explicitly set. */
.wp-block-buttons > .wp-block-button.has-custom-width .wp-block-button__link {
	padding-left: 0;
	padding-right: 0;
}

.blog {
	color: var(--wp--preset--color--accent-6) !important;
}

/* UI Issues v2, #4.2: Speaker card's "Faculty Profile >" link was plain
   text + a separate chevron icon, no visual button treatment - client
   wants it styled as an actual bordered button (position was already
   effectively bottom-right, being the last item in the card's text stack,
   right-aligned via its own flex group - only the button LOOK was
   missing).
   Turned out this markup is baked directly into EVERY programme post's
   own content individually (copy-pasted from an original pattern, not a
   live wp:block reference to it - confirmed by finding the same "Faculty
   Profile" text and href sitting in each programme's own post_content,
   not in the "Speaker (Card)"/"Speaker (Single)" reusable blocks or any
   template in the rendering chain), so adding a stable className via a
   migration would mean editing every programme post's content
   individually - too invasive for a pure style change. Targets the
   block's auto-generated layout hash class instead
   (wp-container-core-group-is-layout-9276dcd6) - safe here because it's
   derived from the block's layout JSON attributes
   ({"type":"flex","flexWrap":"nowrap","justifyContent":"right"}), which
   is identical (and this hash therefore identical) across every
   programme's copy of this exact group, confirmed directly: on a page
   with 3 speakers, the class appears exactly 4 times (1 for the printed
   CSS rule + 3 real usages, matching 1:1) - not reused by anything else
   on that page. Will need re-verifying if this exact block is ever
   restructured (the hash changes if its layout attrs do). */
.wp-container-core-group-is-layout-9276dcd6 {
	border: 1px solid currentColor;
	padding: 8px 16px;
	gap: 4px;
	width: fit-content;
	/* This group was previously full-width with its own content
	   justify-content:right pushing the text+icon to the right edge -
	   shrinking it to width:fit-content (needed so the border wraps just
	   the button, not the whole row) removes that full-width mechanism,
	   so the now intrinsically-sized box would otherwise sit at its
	   parent's LEFT edge instead - confirmed the hard way via a before/
	   after screenshot. margin-left:auto restores the right alignment.
	   margin-right:0 is also needed (found the hard way, client-reported
	   the button drifting back to centered) - this group is ALSO a direct
	   child of the "is-layout-constrained" wrapper, which prints its own
	   `margin-right:auto` for every child via WP core's own generated
	   layout-support CSS; left unset here, that rule's margin-right:auto
	   combines with this rule's margin-left:auto to center the button
	   (auto margins on BOTH sides split the leftover space evenly)
	   instead of pushing it all the way right. !important to beat that
	   same-specificity core rule regardless of print order, same reasoning
	   as margin-top above. */
	margin-left: auto;
	margin-right: 0 !important;
	/* UI Issues v2, #4.1/#4.2 follow-up (client screenshot, 2026-09-06):
	   when a speaker's description text is long enough to make the text
	   column taller than a short one-liner, the button should still sit
	   at the card's bottom edge, not immediately trail the text - "same
	   handling as Programme Cards", whose category pill sits bottom-
	   anchored the same way. margin-top:auto pushes it there, provided
	   its own flex-column parent (below) actually has room to push
	   within - i.e. genuinely fills the row's height.
	   !important needed - confirmed the hard way this otherwise loses to
	   WP's own blockGap implementation on the parent group
	   (`.wp-container-core-group-is-layout-XXXX > * + * { margin-block-
	   start: ... }`), which resolves to the exact same physical margin-top
	   in this LTR layout and is printed with equal selector specificity
	   (one class each) - whichever one loads later in the page wins on a
	   tie, and that's WP's, not this stylesheet's. */
	margin-top: auto !important;
}
/* Same fix as #4.1/#4.2 above, for the padding-wrapper group one level up:
   it needs to be a column flex container (not the default block flow) so
   margin-top:auto on the button group actually has downward room to push
   into, and it needs height:100% since - like the Programme List cards in
   #2.2 - it's a plain block sitting inside a stretched flex column
   (.wp-block-column, default align-items:stretch already makes THAT full
   height) that otherwise stays sized to its own content regardless of how
   tall its stretched ancestor is. :has() targets the speaker card's own
   wrapper specifically via the button class/hash it contains, not every
   group site-wide. */
.wp-block-group:has(> .wp-container-core-group-is-layout-9276dcd6),
.wp-block-group:has(> .cuhk-faculty-profile-button) {
	display: flex;
	flex-direction: column;
	height: 100%;
}
/* Found the hard way (client screenshot showing speaker NAMES sitting
   centered instead of left-aligned, live, with real photos in place -
   ruled out a data/image problem): turning the wrapper above into a flex
   container activated a WP core rule that was already there and
   harmless until now - `.is-layout-constrained > :where(...) {
   margin-left:auto; margin-right:auto }`, part of how "constrained"
   layout normally centers+caps width in ordinary block flow. In block
   flow this rule is a no-op for a heading (block-level, so it already
   fills the available width - auto margins on a fully-wide box have no
   space to distribute). Once that same element becomes a FLEX ITEM
   (flex-direction:column), CSS flexbox gives `margin:auto` on a cross-
   axis a different, deliberate meaning: it shrinks the item to its
   content size and centers it, overriding the default stretch - exactly
   why a short "Prof. X Y" heading visibly shrank and centered while the
   longer, line-wrapping description text barely looked different (its
   content width already nearly matched the column anyway). Resetting
   the margin back to 0 on this wrapper's own children restores normal
   full-width, left-aligned block behavior for them - excluding the
   button group itself, which needs to keep its own margin-left:auto
   (right-alignment) untouched. */
.wp-block-group:has(> .wp-container-core-group-is-layout-9276dcd6) > *:not(.wp-container-core-group-is-layout-9276dcd6),
.wp-block-group:has(> .cuhk-faculty-profile-button) > *:not(.cuhk-faculty-profile-button) {
	margin-left: 0 !important;
	margin-right: 0 !important;
}
/* Same root cause as #2.2 (Programme List cards): the speaker photo's
   wp:image block sets `{"aspectRatio":"1","width":"100%","height":"100%"}`,
   which WordPress core renders as a self-conflicting inline style -
   `aspect-ratio:1;width:100%;height:100%;width:auto;object-fit:cover` -
   confirmed directly on this exact markup. The trailing width:auto wins,
   forcing a square image sized from its own width rather than actually
   filling its (non-square) column - and same as #2.2, the wrapping
   <figure>/<a> have no height of their own for the img's height:100% to
   resolve against, so it falls back to the aspect-ratio square instead.
   Cascading height:100% through those wrappers, plus !important on the
   img itself to override the conflicting inline style, fixes both. Scoped
   to the speaker card's own columns block via :has(), not every image
   site-wide - plenty of other wp:image instances need their real aspect
   ratio kept intact.

   Deliberately NOT setting height:100% on the image column itself
   (.wp-block-column:first-child) - confirmed the hard way this actively
   BREAKS the column's own native cross-axis stretch instead of helping:
   the column's parent (.wp-block-columns, display:flex) never has an
   explicit height of its own (sized to its tallest child), so a
   height:100% authored on the column computes to `auto` under CSS's
   indefinite-containing-block rule - but an *authored* percentage that
   resolves to auto is NOT the same, for align-items:stretch purposes, as
   the property being unset entirely; stretch only kicks in for a flex
   item that is "auto-sized" (no specified cross-size at all). Leaving
   this column's height alone lets it stretch correctly on its own, which
   is what then gives figure/a below a genuinely definite height to
   resolve their own height:100% against. */
.wp-block-columns:has(.wp-container-core-group-is-layout-9276dcd6) .wp-block-column:first-child figure,
.wp-block-columns:has(.wp-container-core-group-is-layout-9276dcd6) .wp-block-column:first-child figure > a,
.wp-block-columns:has(.cuhk-faculty-profile-button) .wp-block-column:first-child figure,
.wp-block-columns:has(.cuhk-faculty-profile-button) .wp-block-column:first-child figure > a {
	height: 100%;
}
.wp-block-columns:has(.wp-container-core-group-is-layout-9276dcd6) .wp-block-column:first-child img,
.wp-block-columns:has(.cuhk-faculty-profile-button) .wp-block-column:first-child img {
	width: 100% !important;
	height: 100% !important;
}