/**
 * core/read-more — the article listing card's "Read More" call to action.
 *
 * Loaded by xperience_starter_enqueue_core_block_styles() in functions.php through
 * wp_enqueue_block_style( 'core/read-more', … ), the same mechanism and for the same reason
 * as assets/css/blocks/core-post-title.css beside it: it is core's theme-side counterpart of
 * block.json's `style` key, one stylesheet attached to one block, enqueued only on a request
 * that actually rendered the block. It is NOT appended to the theme's root style.css, which
 * xperience_starter_enqueue_styles() serves as style.min.css on any request where
 * SCRIPT_DEBUG is off — a rule added there would never be served.
 *
 * WHAT THIS FIXES, AND IT IS A VISIBILITY DEFECT RATHER THAN A STYLING PREFERENCE. The CTA
 * carries textColor `white` from patterns/article-page-listing.php and
 * patterns/article-content-page-listing.php, and it sits inside a card group whose
 * backgroundColor is `white`. With no fill of its own it renders white on white. Measured on
 * both instances before this file existed, at 1440x900 and 390x844:
 *
 *   a.wp-block-read-more   119x44   backgroundColor rgba(0, 0, 0, 0)   color rgb(255, 255, 255)
 *
 * WHY CSS AND NOT A BLOCK ATTRIBUTE, checked in core before reaching for a rung.
 * web/wp-includes/blocks/read-more/block.json declares supports.color as
 * `{ "gradients": true, "text": true }` — there is NO `background` key, so core serialises no
 * background for this block and `backgroundColor` is not an attribute it accepts. The pattern
 * cannot state the fill; the rungs below core block composition are block bindings and a
 * custom block, both of them PHP this theme would own forever for a link.
 *
 * THE COLOUR IS THE `primary` PRESET AND IT WAS VERIFIED AGAINST THE LIVE SOURCE, not taken
 * from the note that proposed it. Probed 2026-09-09 on
 * https://xperience-starter.wfdev.net/sandbox/page-builder-components/article-page-listing/,
 * all four `.card-footer a.btn.btn-primary`: backgroundColor rgb(13, 110, 253). theme.json's
 * palette holds `primary` at #0d6efd, which is that value exactly, so the token is referenced
 * rather than the hex restated.
 *
 * NO SELECTOR SCOPING BEYOND THE BLOCK'S OWN CLASS, and that is a decision rather than an
 * oversight. `.wp-block-post-title` next door had to be narrowed to a `card-cta` custom class
 * because that block also renders every real post title on the site. core/read-more renders
 * one thing only — the post link a query template emits — and both units that place it want
 * this fill. A custom class here would be a second name for "every core/read-more there is".
 *
 * THE WRAPPER IS THE ANCHOR, so this needs no descendant selector.
 * render_block_core_read_more() puts get_block_wrapper_attributes() on the <a> itself and the
 * label plus a `.screen-reader-text` span inside it — unlike core/post-title, which puts the
 * wrapper on a <p> with the <a> inside and forced core-post-title.css to reach in with `> a`.
 *
 * @package WordPress
 * @subpackage Xperience_Starter
 * @since Xperience Starter 1.0
 */

.wp-block-read-more {
	background-color: var( --wp--preset--color--primary );
}

/*
 * THE THREE DECLARATIONS BOOTSTRAP'S `.btn` MAKES THAT `core/read-more` CANNOT.
 * Added 2026-09-10, all three measured on the source's own `.card-footer a.btn.btn-primary`
 * at 1440x900, 1024x768, 768x1024 and 390x844, and NONE of them recorded in either unit's
 * contract -- handed back as a discovery defect rather than written into `structure`
 * (docs/package-discipline.md §11.5).
 *
 * WHY EACH ONE IS HERE AND NOT A BLOCK ATTRIBUTE, checked in core before reaching down a
 * rung, exactly as the background-color above was. The fourth difference measured with them
 * -- `letter-spacing: 1.5px` -- is NOT in this file, because read-more's own block.json
 * declares `typography.__experimentalLetterSpacing: true` and the rung was open: it is a
 * block attribute in patterns/article-page-listing.php.
 *
 *   border: 1px solid <primary>.  read-more's `__experimentalBorder` declares `color`,
 *     `radius` and `width` and NO `style` key. MEASURED on this install 2026-09-10 by
 *     calling wp_apply_border_support() directly: the natural spelling
 *     (`borderColor: "primary"` + `style.border.width: "1px"`) returns
 *     `border-width:1px` and NOTHING ELSE -- wp_has_border_feature_support( $type, 'style' )
 *     is false, so `border-style` is dropped, and CSS's initial `border-style: none` means
 *     the used width is 0. The border does not appear and nothing reports it: the block
 *     renders exactly as it did, one silent no-op wearing a correct-looking attribute.
 *     A SECOND SPELLING DOES WORK AND IS DELIBERATELY NOT USED. Per-side values
 *     (`style.border.top.style` and its three siblings) ARE serialised -- the side loop in
 *     wp-includes/block-supports/border.php checks only wp_should_skip_block_supports_serialization()
 *     and never wp_has_border_feature_support(), so it emits `border-top-style:solid` for a
 *     block whose supports say it has no border style at all. Measured returning all twelve
 *     declarations with the preset colour resolved. It is refused because it is that
 *     inconsistency: the block's own supports say the property is unavailable, so the
 *     editor's border UI has no control for it, and the first editor round-trip that
 *     touches this block's border panel can drop the four `style` values with the border
 *     silently vanishing again. One stable declaration beats twelve that depend on core not
 *     tightening its own check.
 *   text-align: center.  read-more's `supports.typography` has no `textAlign`, and the
 *     block has no `align`/`textAlign` attribute of its own.
 *   display: inline-block.  No block attribute exists for `display` on any core block.
 *     THE CTA'S CONTAINER HAD TO CHANGE FOR THIS ONE TO MEAN ANYTHING -- a flex item is
 *     blockified, so this declaration computes `block` inside a flex row however it is
 *     written. patterns/article-page-listing.php's CTA row is now `layout: default`;
 *     its comment carries the measurement and the hand-back.
 *
 * RAISED BY ONE STEP TO `a.wp-block-read-more`, (0,1,1), and only `display` needs it:
 * core's own wp-includes/blocks/read-more/style.css sets `.wp-block-read-more{display:block}`
 * at (0,1,0). Theme block styles are enqueued after core's on this install (measured in the
 * rendered head: `wp-block-read-more-inline-css` then `xperience-starter-core-read-more-inline-css`),
 * so order alone would carry it -- but order is the thing that changes without warning, and
 * a rule that loses on order is discarded in SILENCE with getComputedStyle showing only the
 * winner. The tag is free and exact: render_block_core_read_more() puts the wrapper
 * attributes on the <a> itself, so this selector cannot miss and cannot widen.
 *
 * THE FILL ABOVE IS LEFT AT (0,1,0) ON PURPOSE. Nothing in core or in global styles declares
 * a background for this block, so raising it would be specificity spent against no opponent.
 *
 * SCOPE, restated because this rule reaches further than the unit that prompted it. Like the
 * fill above it, this is unscoped to any unit: both patterns that place core/read-more --
 * article-page-listing and article-content-page-listing -- render the same source component
 * from the same Bootstrap rule, so a `.card-cta`-style hook here would be a second name for
 * "every core/read-more there is". The sibling unit therefore gets these three now and does
 * NOT get the letter-spacing, which lives in this unit's pattern; closing that is the
 * sibling's own unit loop.
 */
a.wp-block-read-more {
	display: inline-block;
	border: 1px solid var( --wp--preset--color--primary );
	text-align: center;
}