/**
 * core/accordion — the two source primitives this theme maps onto the same core blocks.
 *
 * Loaded by xperience_starter_enqueue_core_block_styles() in functions.php through
 * wp_enqueue_block_style( 'core/accordion', … ), the same mechanism and for the same reasons
 * as core-media-text.css beside it. One registration covers all four blocks in the family:
 * core/accordion is the outer block and is always rendered when a heading, an item or a panel
 * is, so the on-demand enqueue fires exactly when any rule below is needed.
 *
 * TWO SOURCE UNITS SHARE THESE CORE BLOCKS AND DISAGREE ON ALMOST EVERY VALUE, which is why
 * nothing here is unscoped. The source's page-builder ACCORDION WIDGET
 * (`.page-component.accordion`, units/accordion.yml) and its ACCORDION SECTION
 * (`_AccordionSection.cshtml`, units/accordion-section.yml) call the same Razor helper and
 * then get styled by two different rule sets: the widget by a `.page-component.accordion`
 * override block, the Section by plain Bootstrap. Measured on the live source 2026-09-09 at
 * 1440x900 with tooling/extract/probe.js, `button.accordion-button`:
 *
 *                              widget                        Section
 *   font                       16px / 800 / lh 16px          16px / 400 / lh 19.2px
 *   padding                    16px all round                16px 20px
 *   background, closed         rgb(222, 226, 230)            rgb(255, 255, 255)
 *   background, open           rgb(222, 226, 230)            rgb(28, 58, 169)
 *   colour, closed             rgb(0, 0, 0) + white title    rgb(51, 51, 51)
 *   colour, open               rgb(0, 0, 0) + white title    rgb(255, 255, 255)
 *   glyphs                     one 20x20 chevron, far right  16x16 chevron after the title
 *                                                            + a 20x20 caret, far right
 *
 * So each block is scoped by the className its own pattern writes on the core/accordion root:
 * `wf-accordion-widget` (patterns/accordion.php) and `wf-accordion-section`
 * (patterns/accordion-section.php). Nothing here can reach a core/accordion instance the
 * source never measured.
 *
 * WHY CSS AT ALL, AND WHY THE UNITS STAY AT rung core-block-composition. Padding is NOT here:
 * core/accordion-heading's save() writes `spacingProps.style` straight onto the toggle
 * <button> (wp-includes/js/dist/block-library.js, `accordion-heading/save.mjs`), so the
 * source's 16px/20px insets are block attributes in the two patterns and not rules in this
 * file. What is left is the set of declarations core's own stylesheets make and the source
 * does not, none of which any block attribute addresses:
 *
 * 1. `padding: var(--wp--preset--spacing--20, 1em) 0` — core, accordion-heading/style.css:15.
 *    The fallback never fires on a themed site: this theme defines spacing--20 as 0.25rem
 *    ("Tiny", theme.json), so the bar computed 4px of vertical padding and NO horizontal
 *    padding at all. MEASURED before this file, at 1440x900: the widget's bar was 27px tall
 *    against a source at 52px, and its title sat at x=72 against the source's x=89. The
 *    patterns' padding attributes now supply the source's own values on the BAR, and they land
 *    on the same element, so nothing here restates them. The PANEL's inset is a rule below
 *    rather than an attribute, for a reason stated where it is written.
 *
 * 2. `font-size / font-weight / line-height: inherit` — core, accordion-heading/style.css:4-6.
 *    The toggle inherits its type from the heading tag it sits in, and a block's rendered TAG
 *    is a style surface: theme.json's bare `h1`-`h6` element styles compile to unscoped tag
 *    selectors (reference/sources/block-attributes.md §A block's rendered TAG is a style
 *    surface). So the ONLY way to reach the bar's type through a block attribute is to restyle
 *    the heading itself — and the source's heading tag is NOT restyled: measured, the widget's
 *    <h1> computes 40px/800/48 and the Section's <h3> computes 28px/800/33.6, both of which
 *    this theme's theme.json already matches. Setting the type here rather than as an
 *    attribute is what lets the tag keep the value the source measured while the button gets
 *    its own. It is also the correction to a real defect: the build shipped the bar at
 *    16px/400 by putting `fontSize`/`fontWeight` on the heading, which moved BOTH.
 *
 * 3. The Section's bar recolours when it closes and core paints a heading unconditionally.
 *    core/accordion-item toggles `is-open` on the item through `data-wp-class--is-open`
 *    (wp-includes/blocks/accordion-item.php:35), which is the hook the two-state rules below
 *    use. The widget's bar does NOT recolour — measured, all three of its bars compute
 *    rgb(222, 226, 230) whether open or closed, because the `.text-bg-light-gray` utility the
 *    widget applies wins over `_accordion.scss`'s `.accordion-button:not(.collapsed)` rule —
 *    so its colours are set once, with no state selector anywhere.
 *
 * 4. The glyphs. accordion-heading's save() emits a literal "+" in a `__toggle-icon` span and
 *    accordion-item/style.css rotates it 45deg when open. The source draws chevrons instead.
 *
 * COLOURS ARE REFERENCED, NOT RESTATED. Every colour below is a theme.json preset custom
 * property whose value is the exact measured triple: `light-gray` #dee2e6 = rgb(222, 226, 230),
 * `white` #ffffff, `black` #000000, `body-text` #333333 = rgb(51, 51, 51), `bright-blue`
 * #1c3aa9 = rgb(28, 58, 169).
 */

/*
 * CORE UNDERLINES THE TITLE ON HOVER AND NEITHER SOURCE DOES. accordion-heading/style.css:26
 * declares `.wp-block-accordion-heading__toggle:hover .wp-block-accordion-heading__toggle-title
 * { text-decoration: underline }`. MEASURED on the live source with `--do=hover:` on both
 * units' bars: `textDecorationLine` stays `none`. The source's only hover declaration on this
 * element is Bootstrap's `.accordion-button:hover { z-index: 2 }`.
 */
.wf-accordion-widget .wp-block-accordion-heading__toggle:hover .wp-block-accordion-heading__toggle-title,
.wf-accordion-section .wp-block-accordion-heading__toggle:hover .wp-block-accordion-heading__toggle-title {
	text-decoration: none;
}

/* ---------------------------------------------------------------------------------------
 * The page-builder ACCORDION WIDGET — patterns/accordion.php
 * ------------------------------------------------------------------------------------ */

/*
 * `line-height: 1` and `font-weight: 800` are the source's own
 * `.page-component.accordion .accordion-button` declarations, read from the site's
 * frontend/dist/styles/main.css. `font-size: 1rem` is there too and is written as the
 * `medium` preset, which is 1rem exactly.
 */
.wf-accordion-widget .wp-block-accordion-heading__toggle {
	background-color: var(--wp--preset--color--light-gray);
	color: var(--wp--preset--color--black);
	font-size: var(--wp--preset--font-size--medium);
	font-weight: 800;
	line-height: 1;
}

/*
 * The source paints the button's own `color` black and the nested title span white
 * (`_accordion.scss`'s `.accordion-item-title { color: $white }`, unconditional, plus
 * `.accordion-button svg { color: #fff }`). Both are measured on the live source and both are
 * reproduced, rather than collapsing them into one white on the button: the black is what the
 * button element itself computes and a comparison reads element by element.
 */
.wf-accordion-widget .wp-block-accordion-heading__toggle-title,
.wf-accordion-widget .wp-block-accordion-heading__toggle-icon {
	color: var(--wp--preset--color--white);
}

/*
 * The source's bar is 52px tall and the arithmetic is 16 + 16 padding + a 20px content box,
 * where the 20 is the glyph and not the text: its `.accordion-button svg` is `1.25rem` square
 * while the title's line box is 16px. Core's `__toggle-icon` is `1.2em` (19.2px here), which
 * would make the bar 51. The 1.25rem below is the source's own value.
 *
 * `flex: 0 0 auto` on the title plus `margin-left: auto` on the icon is core's `flex: 1`
 * replaced by the source's `justify-content: space-between`: measured, the source's title span
 * is 123px wide (its text) where core's stretched to 1277.
 */
.wf-accordion-widget .wp-block-accordion-heading__toggle-title {
	flex: 0 0 auto;
}

/*
 * THE WIDGET'S GLYPH IS A CHEVRON AND CORE'S IS A "+", so the span core gives us is repainted
 * rather than replaced. Handed to this build as measured on both sides at all four viewports:
 * the source draws an SVG chevron 20x20, this build drew a text "+" at 20x20 closed and 28x28
 * open -- 28.28 is 20*sqrt(2), the bounding box of a 20px square turned 45deg by core's own
 * accordion-item/style.css:1-3.
 *
 * WHY A MASK AND NOT MARKUP. accordion-heading is a STATIC block: its save() (`accordion-
 * heading/save.mjs` in wp-includes/js/dist/block-library.js, read on this install) writes the
 * literal "+" into the stored HTML, and WordPress validates a static block by re-running
 * save() in JavaScript and diffing it against what is stored. An <svg> written into the
 * pattern would therefore be an invalid block in both editors while rendering correctly on the
 * front -- exactly the class of failure ./scripts/check-block-editor-valid.sh exists to catch.
 * So the element stays core's and the drawing is ours, which is the same route the Section
 * below already takes for both of its glyphs.
 *
 * THE PATH IS THIS THEME'S OWN `navigation-next`, copied rather than linked: assets/images/
 * icons.svg carries it as a <symbol viewBox="0 0 20 20"> with `d="m7.5 15 5-5-5-5"` at
 * stroke-width 1.667, and a <symbol> cannot be reached from CSS through a fragment identifier.
 * It is the same data URI the Section's ::after uses, for the same reason.
 *
 * NOTHING HIDES THE "+" HERE, AND THAT IS NOT AN OVERSIGHT -- IT IS WHY THIS UNIT CAN KEEP A
 * VALUE THE SECTION BELOW HAD TO GIVE UP. `mask` sets the alpha of everything the element
 * paints, its text included, so the span renders as (white background + white "+") clipped to
 * the chevron: white where the chevron is and nothing anywhere else, which is a chevron. The
 * Section's caret needs `color: transparent` only because its background-color is #333 while
 * its inherited text colour is not, so an unhidden "+" would show through its own mask; here
 * the two are the same white and the glyph cancels itself out.
 *
 * WHAT THAT BUYS, AND IT IS THE REASON TO PREFER IT: the icon keeps `color:
 * var(--wp--preset--color--white)` in the rule above, which is the source's own
 * `.accordion-button svg { color: #fff }`, MEASURED on the live source and matching today.
 * `color: transparent` would have repainted it rgba(0, 0, 0, 0) and turned a property that
 * matches into one that does not -- a new difference introduced while closing another, which
 * is the shape of regression CLAUDE.md's third check-test names ("a correct build stays
 * green"). `font-size: 0` was rejected for the same class of reason, stated where the Section
 * states it: it would leave the span computing 0px where the source's <svg> computes 16px.
 *
 * 90deg / -90deg, NOT 45deg, AND THE ANGLE IS LOAD-BEARING TWICE. It is what the source does
 * -- a `navigation-next` chevron points right, so 90 points it down when closed and -90 points
 * it up when open -- and it is also what keeps the measured box 20x20 in both states, since a
 * quarter turn maps a square onto itself and an eighth turn does not. The open-state selector
 * carries three classes plus the `is-open` hook core toggles on the ITEM
 * (`data-wp-class--is-open`, wp-includes/blocks/accordion-item.php), so it outweighs core's
 * own single-class rotate rule whichever way the two stylesheets are ordered.
 */
.wf-accordion-widget .wp-block-accordion-heading__toggle-icon {
	width: 1.25rem;
	height: 1.25rem;
	margin-left: auto;
	background-color: var(--wp--preset--color--white);
	-webkit-mask: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20' fill='none'%3E%3Cpath d='m7.5 15 5-5-5-5' stroke='%23000' stroke-width='1.667' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E") no-repeat center / 100% 100%;
	mask: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20' fill='none'%3E%3Cpath d='m7.5 15 5-5-5-5' stroke='%23000' stroke-width='1.667' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E") no-repeat center / 100% 100%;
	transform: rotate(90deg);
}

.wf-accordion-widget .wp-block-accordion-item.is-open > .wp-block-accordion-heading .wp-block-accordion-heading__toggle-icon {
	transform: rotate(-90deg);
}

/*
 * THE PANEL'S INSET IS A RULE AND NOT AN ATTRIBUTE, AND THE `[hidden]` LINE IS THE REASON.
 * core/accordion-panel serializes `spacing.padding` normally, so it CAN be a block attribute --
 * but core hides a closed panel with `hidden="until-found"` rather than `display: none`
 * (wp-includes/blocks/accordion-item.php's `data-wp-bind--hidden`), and `content-visibility:
 * hidden` still lays out the element's own padding box. MEASURED: with the inset as an inline
 * style, a closed Section root came to 86px -- 1 + 52 + 32 + 1 -- against the source's 54, the
 * 32 being padding around nothing. The source's `.accordion-collapse` is plainly `display:
 * none` when closed and contributes zero. An inline style cannot be zeroed by a selector
 * without `!important`, so the inset is a rule here and the closed case is its companion.
 *
 * The values are each source's own `.accordion-body`: 16px all round on the widget,
 * `--bs-accordion-body-padding-y/x` = 1rem/1.25rem on the Section.
 */
.wf-accordion-widget .wp-block-accordion-panel {
	padding: 16px;
}

.wf-accordion-section .wp-block-accordion-panel {
	padding: 16px 20px;
}

.wf-accordion-widget .wp-block-accordion-panel[hidden],
.wf-accordion-section .wp-block-accordion-panel[hidden] {
	padding: 0;
}

/*
 * THE WIDGET ZEROES ITS BODY PARAGRAPHS AND THE SECTION DOES NOT. This is one of the
 * source's own three exceptions to its site-wide `p { margin-bottom: 1rem; margin-top: 0 }`,
 * and it is reproduced as a rule rather than inferred from a height.
 *
 * READ OFF THE LIVE SOURCE 2026-09-09, the declarations that match `.accordion-body p` on
 * each of the two units, in cascade order (CSS.getMatchedStylesForNode over the rendered
 * page, both origins the same day):
 *
 *   widget   `#accordion1-item1 .accordion-body p`
 *              p                                            margin-bottom: 1rem; margin-top: 0
 *              .page-component.accordion .accordion-body p  margin-bottom: 0
 *   Section  `main#main > div:nth-of-type(4) .accordion-body p`
 *              p                                            margin-bottom: 1rem; margin-top: 0
 *              (no exception)
 *
 * So the widget's body copy sits flush and the Section's carries 16px under it. MEASURED
 * consequences on the source, same day: the widget's open panel is 56 / 80 / 80 / 128 tall
 * across the four captured viewports (16px of `.accordion-body` padding, the copy, 16px), and
 * the Section's is 72 / 72 / 112 / 112 -- the extra 16 per line-broken column being exactly
 * this margin.
 *
 * WHY IT IS WRITTEN NOW, WHILE IT CHANGES NOTHING. Today this theme states no paragraph
 * margin at all, so WP's own layout reset -- `:root :where(.is-layout-flow) > :last-child
 * { margin-block-end: 0 }`, specificity 0,2,0 -- already leaves these paragraphs at 0 and the
 * built panel measures 56 / 80 / 80 / 128, matching the source exactly. MEASURED with the
 * rule present and absent: identical, four viewports.
 *
 * It is the SITE-WIDE rule landing that needs this. Injected into the built page, a paragraph
 * rule heavy enough to beat that 0,2,0 reset takes the widget's open panel to 72 / 96 / 96 /
 * 144 and its unit root from 308 / 332 / 332 / 380 to 324 / 348 / 348 / 396 -- +16 at every
 * viewport, on a panel that matches today. The selector below is 0,2,1 and clears the reset
 * on the same terms.
 *
 * SCOPED TO THE WIDGET, NOT TO core/accordion. The Section shares these core blocks and must
 * keep its 16px; `.wf-accordion-section` is deliberately absent from the selector.
 *
 * THE THIRD CLASS IN THE SELECTOR IS LOAD-BEARING AND IS NOT DECORATION. `.wp-block-accordion-
 * item` is not needed to select anything -- the two-class form matches the same three
 * paragraphs -- it is there for weight. A site-wide paragraph rule has to reach 0,2,1 or more
 * before it clears WP's own 0,2,0 layout reset and does anything at all, and MEASURED, a
 * two-class exception at 0,2,1 TIES with such a rule and then loses on document order: with
 * `:root p:not([hidden]){margin-bottom:16px}` injected after the page's own styles, the
 * two-class form left the open panel at 72 / 96 / 96 / 144, i.e. did not hold. Three classes
 * plus the tag is 0,3,1 and wins outright, whichever way the site rule is ordered. The
 * standing constraint that follows, and it belongs to whoever lands that rule rather than
 * here: a site-wide paragraph rule above 0,3,1 would silently take this exception with it.
 */
.wf-accordion-widget .wp-block-accordion-item .wp-block-accordion-panel p {
	margin-bottom: 0;
}

/* ---------------------------------------------------------------------------------------
 * The ACCORDION SECTION — patterns/accordion-section.php
 * ------------------------------------------------------------------------------------ */

/*
 * Bootstrap's `.accordion-button` for this Section: `font-size: 1rem` (the `medium` preset),
 * inherited weight 400, and a 1.2 line-height giving the measured 19.2px line box.
 *
 * The two-state colours are Bootstrap's own accordion variables, read from the source's
 * compiled main.css and confirmed against the measured triples:
 *   closed  --bs-accordion-btn-bg   = --bs-body-bg    = #fff
 *           --bs-accordion-btn-color = --bs-body-color = #333
 *   open    --bs-accordion-active-bg    = #1c3aa9   (the theme's `bright-blue`)
 *           --bs-accordion-active-color = #fff
 * `BarColor` is `derived: uninstantiated` on both captured instances, so nothing overrides
 * those variables here the way the widget's utility class does on the other unit.
 */
.wf-accordion-section .wp-block-accordion-heading__toggle {
	background-color: var(--wp--preset--color--white);
	color: var(--wp--preset--color--body-text);
	font-size: var(--wp--preset--font-size--medium);
	font-weight: 400;
	line-height: 1.2;

	/*
	 * THE BAR'S TOP CORNERS ARE ROUNDED AND THE BOTTOM PAIR IS SQUARE -- `5px 5px 0 0`.
	 * Bootstrap draws one radius on `.accordion-item` and a 1px-smaller one on the button
	 * inside it: `--bs-accordion-border-radius` is 0.375rem = 6px and
	 * `--bs-accordion-inner-border-radius` is `calc(0.375rem - 1px)` = 5px, the 1px being the
	 * item's own border. The item's 6px is a block ATTRIBUTE on core/accordion-item
	 * (patterns/accordion-section.php); the bar's cannot be, and that is why this is a rule.
	 * core/accordion-heading redirects only `spacing` to the toggle <button> --
	 * `__experimentalSkipSerialization` with `__experimentalSelector`
	 * ".wp-block-accordion-heading__toggle", block.json -- while its `__experimentalBorder`
	 * support has no such redirect, so a `style.border.radius` attribute would serialise onto
	 * the <h3> wrapper (`useBlockProps.save()`, `accordion-heading/save.mjs` in
	 * wp-includes/js/dist/block-library.js, which passes ONLY `spacingProps.style` to the
	 * button). The <h3> is not the element the source's radius is on.
	 *
	 * THE VALUE IS THE ONE HANDED TO THIS BUILD AS MEASURED ON BOTH SIDES AT ALL FOUR
	 * VIEWPORTS AND PIXEL-SAMPLED AT THE TOP-LEFT CORNER (reference `5px 5px 0px 0px`, build
	 * `0px`), NOT A VALUE READ OUT OF BOOTSTRAP. The variables above are the corroborating
	 * mechanism, and they are labelled as such: this unit's contract carries no `chrome` key
	 * and records no border-radius anywhere, which is handed back as a discovery defect.
	 * ONE CAVEAT IS RECORDED RATHER THAN GUESSED AWAY: Bootstrap's
	 * `.accordion-item:last-of-type > .accordion-header .accordion-button.collapsed` rule
	 * would put the inner radius on the BOTTOM corners too when the bar is closed, and the
	 * source's closed bar does carry `collapsed` (this unit's `closed` state). No closed-state
	 * radius was measured on either side, so none is written here -- the same `5px 5px 0 0`
	 * stands in both states, which is what was measured.
	 */
	border-radius: 5px 5px 0 0;
}

.wf-accordion-section .wp-block-accordion-item.is-open > .wp-block-accordion-heading .wp-block-accordion-heading__toggle {
	background-color: var(--wp--preset--color--bright-blue);
	color: var(--wp--preset--color--white);

	/*
	 * THE OPEN BAR'S HAIRLINE, AND IT IS AN INSET SHADOW RATHER THAN A BORDER. Handed to this
	 * build as measured on both sides: reference `rgb(222, 226, 230) 0px -1px 0px 0px inset`,
	 * build `none`, and PIXEL-SAMPLED at x=600 -- the reference goes blue at row 52, exactly
	 * (222, 226, 230) at row 53, white at row 54, where the build went blue(53) -> white(54).
	 * It is Bootstrap's `.accordion-button:not(.collapsed)` declaration, `inset 0 calc(-1 *
	 * var(--bs-accordion-border-width)) 0 var(--bs-accordion-border-color)`, which is the
	 * `light-gray` preset this theme already resolves #dee2e6 to -- so the colour is
	 * referenced, not restated, the same discipline as every other colour in this file.
	 *
	 * OPEN STATE ONLY, which is why it sits in this rule and not in the base one above: the
	 * source's closed bar was hand-measured `shadow: none` at all four viewports. The hook is
	 * core's own `is-open` class on the ITEM (`data-wp-class--is-open`,
	 * wp-includes/blocks/accordion-item.php), the same hook the two-state colours use.
	 *
	 * IT IS NOT A `border-bottom`. A 1px border would add a pixel to the bar's box; the source's
	 * open bar measures 1294x52 with the hairline inside it, and an inset shadow paints over
	 * the padding box without laying anything out. It is not a `shadow` block attribute
	 * either: core/accordion-heading declares `supports.shadow`, but shadow serialises to the
	 * <h3> wrapper for the same reason the radius above does, and no attribute can carry a
	 * state.
	 */
	box-shadow: inset 0 -1px 0 0 var(--wp--preset--color--light-gray);
}

/*
 * THE SECTION DRAWS TWO GLYPHS AND CORE DRAWS ONE, so the second is a generated box rather
 * than a block. Source markup, read from the live page:
 *
 *   <button …><span class="accordion-item-title">1 Column</span>
 *             <svg class="svg-icon"><use xlink:href="…icons.svg#navigation-next"></use></svg>
 *   </button>
 *
 * plus Bootstrap's own `.accordion-button::after` caret, which `margin-left: auto` pushes to
 * the far right. Measured at 1440x900: the title span is 141x19 at x=93, the inline svg is
 * 16x16 immediately after it at x=234, and the caret is 1.25rem square at the right edge.
 *
 * Both paths below are copied rather than linked, and each names its origin. The far-right
 * caret is Bootstrap's `--bs-accordion-btn-icon`; the one beside the title is the
 * `navigation-next` symbol from this theme's own assets/images/icons.svg — a <symbol> cannot
 * be referenced by CSS through a fragment identifier, which is why the path is inline.
 *
 * `background-color: currentColor` behind a mask is what makes one copy serve both states:
 * the source's inline svg strokes `currentColor` and Bootstrap swaps a #333 icon for a #fff
 * one, and both reduce to "the colour the button already computes".
 *
 * `order` puts the generated box between the title and the icon; core's markup has no slot
 * there. The far-right caret does NOT use `currentColor`, and the reason is that core's markup
 * puts a literal "+" inside the very span that has to become the caret: hiding that glyph costs
 * either `color: transparent`, which would take `currentColor` with it, or `font-size: 0`,
 * which would leave the span computing 0px where the source's <svg> computes 16px. So the
 * caret is painted from the two presets Bootstrap's own `--bs-accordion-btn-icon` and
 * `--bs-accordion-btn-active-icon` carry -- #333 closed, #fff open -- and `color: transparent`
 * hides the "+". The chevron beside the title has no such constraint and follows the text.
 */
.wf-accordion-section .wp-block-accordion-heading__toggle-title {
	flex: 0 0 auto;
}

.wf-accordion-section .wp-block-accordion-heading__toggle::after {
	content: "";
	order: 1;
	flex: 0 0 auto;
	width: 16px;
	height: 16px;
	background-color: currentColor;
	-webkit-mask: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20' fill='none'%3E%3Cpath d='m7.5 15 5-5-5-5' stroke='%23000' stroke-width='1.667' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E") no-repeat center / 100% 100%;
	mask: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20' fill='none'%3E%3Cpath d='m7.5 15 5-5-5-5' stroke='%23000' stroke-width='1.667' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E") no-repeat center / 100% 100%;
}

.wf-accordion-section .wp-block-accordion-heading__toggle-icon {
	order: 2;
	width: 1.25rem;
	height: 1.25rem;
	margin-left: auto;
	color: transparent;
	background-color: var(--wp--preset--color--body-text);
	-webkit-mask: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Cpath fill-rule='evenodd' d='M1.646 4.646a.5.5 0 0 1 .708 0L8 10.293l5.646-5.647a.5.5 0 0 1 .708.708l-6 6a.5.5 0 0 1-.708 0l-6-6a.5.5 0 0 1 0-.708z'/%3E%3C/svg%3E") no-repeat center / 100% 100%;
	mask: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 16 16'%3E%3Cpath fill-rule='evenodd' d='M1.646 4.646a.5.5 0 0 1 .708 0L8 10.293l5.646-5.647a.5.5 0 0 1 .708.708l-6 6a.5.5 0 0 1-.708 0l-6-6a.5.5 0 0 1 0-.708z'/%3E%3C/svg%3E") no-repeat center / 100% 100%;
}

/*
 * Core rotates its "+" 45deg to make an "x" (accordion-item/style.css:1-3). Bootstrap's caret
 * turns over instead — `--bs-accordion-btn-icon-transform: rotate(-180deg)` — and that is what
 * the source's open bar draws.
 */
.wf-accordion-section .wp-block-accordion-item.is-open > .wp-block-accordion-heading .wp-block-accordion-heading__toggle-icon {
	background-color: var(--wp--preset--color--white);
	transform: rotate(-180deg);
}