/*
 * Site corrections that have no setting in the theme.
 */

/*
 * Team slider progress bar.
 *
 * The bar inherits the colour scheme's link colour:
 *   .slider_outer .swiper-pagination-progressbar .swiper-pagination-progressbar-fill
 *   { background-color: var(--theme-color-text_link) }
 * The section uses the Dark scheme, where that colour is #E03821 (red).
 * Changing the scheme would repaint every link and accent in every dark
 * section, so the override is scoped to the team slider only.
 *
 * Swiper injects .swiper-pagination-progressbar at runtime, so the selector
 * anchors on the wrapper the theme renders server-side.
 */
.sc_team .sc_team_slider .swiper-pagination-progressbar .swiper-pagination-progressbar-fill {
	background-color: #412E7B;
}

/*
 * Team slider arrows: club purple on hover.
 *
 * Swiper injects these at runtime, so they are not in the page source. They sit
 * outside the slider on both sides — measured left:-102px and right:-102px
 * against a 1260px wrapper, transform:none — and the theme keeps them at
 * opacity:0 until the slider is hovered.
 *
 * Only the hover state changes. The resting dark circle is the design.
 *
 * Both properties are set because the theme tints the arrow on hover through
 * the colour scheme's link colour, which is #E03821 in the Dark scheme used by
 * this section — the same red already corrected on the progress bar below.
 * Covering background and glyph means the result is purple either way.
 *
 * ⚠️ `!important` here is precautionary, not proven necessary. The hover state
 * could not be measured remotely: getComputedStyle on this element returned
 * inconsistent values across attempts, including for an inline !important
 * declaration, so neither a pass nor a fail could be trusted. What is solid:
 * the selector matches the element, pointer-events is auto, and no loaded
 * stylesheet names slider_prev, slider_next or slider_controls_wrap alongside
 * a background rule.
 *
 * If a browser check shows the hover colour working, the !important flags can
 * come off. They are here so the fix does not silently do nothing.
 */
.sc_team .slider_controls_wrap > a.slider_prev:hover,
.sc_team .slider_controls_wrap > a.slider_next:hover {
	background-color: #412E7B !important;
	border-color: #412E7B !important;
	color: #FFFFFF !important;
}

/*
 * Empty state and season note for the KZS blocks.
 *
 * SportsPress ships no .sp-message styling that suits a full-width section, so
 * these get just enough to read as deliberate rather than broken.
 */
.kkb-empty {
	padding: 2em 1em;
	text-align: center;
}

/*
 * The empty state reads black, not purple.
 *
 * The theme tints every SportsPress message with the colour scheme's link
 * colour, which is the club purple in the Light scheme used by these sections:
 *   skins/default/plugins/sportspress/sportspress.css:126
 *   .sp-message { color: var(--theme-color-text_link); border-color: … }
 * The old `opacity: 0.7` on .kkb-empty then washed it out to the lilac the
 * client flagged. Both are replaced here: a literal colour instead of a tint,
 * and full strength instead of a fade.
 *
 * That theme rule is one class, so four classes win on specificity rather than
 * on load order. All four are on the element Markup::notice() prints, which
 * also keeps the rule working outside Elementor.
 *
 * #101010 is the same literal black already used for the next-match venue line.
 * The populated results table is unaffected — it runs on
 * --theme-color-text_dark and is black already.
 */
.sportspress .sp-template.sp-message.kkb-empty {
	color: #101010;
	border-color: #101010;
}

.kkb-season-note {
	opacity: 0.75;
	font-size: 0.9em;
}

/*
 * Breathing room above the countdown clock.
 *
 * SportsPress leaves 18px between the match name and the digits, which is not
 * enough at the size the theme renders them. Scoped to our widget so any other
 * SportsPress countdown keeps its own spacing.
 *
 * Measured on the youth page: the gap goes from 17px to 42px.
 *
 * ⚠️ The clock is off by default (CountdownWidget's show_countdown control), so
 * this rule only takes effect where somebody switches it back on. Keep it.
 */
.elementor-widget-kkb_kzs_countdown p.sp-countdown {
	margin-top: 2.5rem;
}

/*
 * Next-match venue line: centred, and darker than the theme's grey.
 *
 * The theme left-aligns every h5 in this block and tints this one:
 *   skins/default/plugins/sportspress/sportspress.css:319
 *   .sp-template-countdown .sp-countdown-wrapper h5.event-venue:not(.event-date)
 *   { color: var(--theme-color-alter_text) }   -> #797C7F
 *   skins/default/plugins/sportspress/sportspress.css:324
 *   .sp-template-countdown h5 { text-align: left }
 *
 * That first selector carries four classes, so the override needs five to win
 * on specificity rather than on load order. CountdownWidget adds
 * kkb-event-venue for exactly that, which also keeps the rule working for the
 * [kkb_next_match] shortcode, where no .elementor-widget-* wrapper exists.
 *
 * #101010 on the row's white background (--theme-color-alter_bg_color) gives
 * about 18.9:1 contrast. Requested as a literal hex, so it does not follow a
 * future palette change.
 */
.sportspress .sp-template-countdown .sp-countdown-wrapper h5.event-venue.kkb-event-venue {
	text-align: center;
	color: #101010;
}

/*
 * Fixtures need the team names; played matches do not.
 *
 * The theme hides the event title outright:
 *   skins/default/plugins/sportspress/sportspress.css:609
 *   .sp-template-event-blocks .sp-event-title { display: none }
 * That works for a played match, where the score identifies it. A fixture has
 * no score, so the row was two logos and a date and nothing else — which is
 * what the youth page showed.
 *
 * ResultsWidget marks those rows `kkb-no-score`, so only they get the heading
 * back. The senior results page is untouched.
 */
.sp-template-event-blocks tr.kkb-no-score .sp-event-title {
	display: block;
	margin: 0.5em 0 0;
	font-size: 1em;
}

/*
 * News grid: one card taller than the rest.
 *
 * The theme registers tornados-thumb-square as 890x664 with crop=true, but that
 * crop was never generated for these uploads, so WordPress falls back to the
 * full-size original and the browser scales it. Three of the images happen to
 * have been hand-cropped to 1170x650 before upload, so they match each other.
 * The fourth is a raw 2560x1707 photo, which lands at 890x593 instead of
 * 890x494 and makes its card taller.
 *
 * There is no theme setting for this, which is why turning options off in the
 * Customizer changed nothing. Forcing the ratio here fixes the cards that exist
 * and every future upload, whatever shape it arrives in.
 *
 * 1170/650 keeps the three correct cards exactly as they look now, rather than
 * imposing the theme's unused 890x664.
 *
 * Only /novice/ and the category archives use post_layout_classic, so nothing
 * else on the site is affected.
 *
 * This does not stop the 2560px original being downloaded. Regenerating the
 * missing thumbnails is the fix for that, and it is a separate job.
 *
 * ⚠️ Do not add `width: 100%` here. `.post_featured` is display:inline-block,
 * so it shrink-wraps its content; a percentage width on the image would then
 * resolve against a box that depends on the image, and collapse to zero.
 * Measured on staging: the cards go from 269/224/224/224 px tall to a flat 224.
 */
.post_layout_classic .post_featured.with_thumb > img {
	height: auto;
	aspect-ratio: 1170 / 650;
	object-fit: cover;
}