/*
 * Mobile corrections for the SCTC site.
 *
 * Most of what follows is scoped to 781px, the breakpoint the parent theme
 * already uses to switch its header to a stacked layout (`style.css`,
 * "max-width:781px" block). Reusing it keeps the header's own mobile rules and
 * these in step; introducing a second breakpoint would make the two drift
 * apart. Inside that query the desktop rendering — the one set in the site
 * editor — stays untouched.
 *
 * The last rule sits outside it, and says why: the stored value it corrects is
 * wrong across several screen sizes, not just on a phone.
 */

@media screen and (max-width: 781px) {
	/*
	 * Banner button: full width instead of a quarter of it.
	 *
	 * The button is stored with `"width":25` in the `front-page` template, which
	 * core turns into `width: calc(25% - …)`. Once the banner columns stack, a
	 * quarter is about 84px — less than the button's own horizontal padding
	 * (`clamp(32px, 3vw, 42px)` a side), so core's `word-break: break-word` broke
	 * the label one letter per line.
	 *
	 * Overriding the width here rather than dropping the attribute in the
	 * database keeps the desktop size the club set in the editor, and spares a
	 * content migration to replay on preprod and prod. Core already stretches
	 * the inner link to its container on `.has-custom-width`, so nothing else is
	 * needed.
	 *
	 * `.slider-btn` scopes this to the banner: other buttons on the site may
	 * legitimately carry a custom width.
	 */
	.slider-btn .wp-block-button.has-custom-width {
		width: 100%;
	}

	/*
	 * Header logo: 200px is over half the width of a 390px screen.
	 *
	 * `core/site-logo` renders its size as plain `width`/`height` attributes on
	 * the `img` — not inline CSS — so an ordinary rule overrides it. Core's own
	 * `.wp-block-site-logo img { height: auto }` keeps the 652x376 source in
	 * proportion, which is why no height is set here.
	 */
	.logo-block .wp-block-site-logo img {
		width: 120px;
	}

	/*
	 * Side margins on inner pages: about 61px a side were lost on a 390px
	 * screen, a third of the width. Two causes stack, so both are undone.
	 *
	 * First, the theme pads `.wp-site-blocks` with
	 * `--wp--custom--spacing--outer`, which resolves to `max(1.75rem, 5.5vw)` —
	 * a 28px floor no media query ever relaxes. Redefining the variable is safe
	 * because the theme spends it twice, symmetrically: as that padding, and as
	 * the negative margin that pulls `.alignfull` blocks back to the full width
	 * (`style.css` lines 51-60 and 62-78). Both move together, so banners stay
	 * edge to edge.
	 */
	body {
		--wp--custom--spacing--outer: 14px;
	}

	/*
	 * Second, the `page` template renders its post content with
	 * `"contentSize":"80%"` — a percentage, so it never loosens on a narrow
	 * screen. This is the selector WordPress itself generates for a constrained
	 * layout; the parent theme already applies the same shape to single posts
	 * (`style.css` lines 1295-1298), which this extends to page content, on
	 * mobile only. Alignments keep their own behaviour.
	 */
	.main-page .wp-block-post-content.is-layout-constrained > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {
		max-width: 100%;
	}

	/*
	 * Article detail (`single` template) loses even more: two percentage caps
	 * stack there — 85% on the columns wrapping the article, then 90% on the
	 * `post-content` template part inside them — leaving 277px of text on a
	 * 390px screen, a 57px margin a side.
	 *
	 * These are `max-width` values on the *containers*, not on their children,
	 * so the rule above does not reach them and they have to be relaxed
	 * directly. Scoped under `.single` to leave the same wrappers alone
	 * wherever else they are used — the search results reuse `.wp-block-columns`
	 * with a 90% cap that is doing its job.
	 */
	.single .wp-block-columns,
	.single .wp-block-template-part {
		max-width: 100%;
	}
}

/* --- Not width-specific ---------------------------------------------------
 *
 * The rule below is deliberately outside the media query: the value it fixes
 * is wrong at more than one screen size, so bounding it to 781px would leave
 * half the bug in place.
 */

/*
 * Search results: the thumbnail overflowed the page by over 100px on a phone,
 * and still spilled 28-61px out of its own card up to about 950px.
 *
 * The `search` template stores the featured image with fixed pixel dimensions
 * — `{"width":"400px","height":"400px"}` — which core renders as
 * `style="width:400px;height:400px"` on the figure. A pixel width cannot
 * yield, and the card holding it is ~200px wide on a phone. `!important` is
 * what it takes to beat an inline style.
 *
 * Above ~950px the card is wider than 400px, so `100%` is capped by
 * `sctc-featured-fallback`'s own `max-width: 400px` and the desktop rendering
 * is unchanged.
 *
 * Only the width is released. The stored 400px height is kept so the frame
 * stays the fixed-height band the template intends, and
 * `sctc-featured-fallback` keeps cropping the image to fill it — releasing the
 * height too would let each result set its own, which is the ragged grid that
 * plugin exists to prevent.
 */
.search-results .wp-block-post-featured-image {
	width: 100% !important;
}