/* ==========================================================================
   AcuMedic — core block mapping

   site.css is the design and is not modified. This file maps the markup core
   blocks emit onto that design, and exists only where a section has been made
   block-native so its content can be bound to a data source.

   Scope today: the hero, the trust bar, the reviews, the concern grid, the
   patient journey, the why cards, the practitioners grid, the visit panel and
   its map, the service category page, the header navigation, the footer
   navigation, the footer's social links and clinic details, and the two card
   elements on the explainer page.
   Every other section still renders the markup in design-assets/home.html
   verbatim and needs nothing here.

   Rule for this file: it may only restate what site.css already says about the
   equivalent hand-written element. It must not introduce new design decisions.

   One note on the `max-width: none` declarations below, and on the comments
   that explain them. site.css §3 used to cap every <p> at --measure, so a core
   paragraph standing in for one of the design's inline elements - a hero meta
   line, the reviews score, a card's "Explore" - arrived with a measure the
   element it replaced never had, and each of those had to be given the width
   back. The design's revision moved the measure off the <p> and onto container
   classes (.measure, .prose, .wrap--narrow), so a bare paragraph is now
   uncapped to begin with and those declarations no longer do anything. They are
   left in place: they are still true statements about what these elements want,
   and they hold if a measure is ever reintroduced. Read the comments beside
   them as history rather than as a description of what site.css does today.
   ========================================================================== */

/* Buttons ------------------------------------------------------------------
   core/button renders:
     <div class="wp-block-button"><a class="wp-block-button__link wp-element-button">
   where the design has:
     <a class="btn btn--primary">
   The design's .btn rules therefore have to be restated against the inner
   anchor, and the .btn--* variants against a block style on the wrapper. */

.wp-block-button__link {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	gap: var(--sp-2);
	min-height: 48px;
	padding: 0 var(--sp-4);
	border: 1px solid transparent;
	border-radius: var(--radius-pill);
	font-size: var(--step-0);
	font-weight: 600;
	line-height: 1;
	text-decoration: none;
	cursor: pointer;
	white-space: nowrap;
	transition: background-color .18s ease, color .18s ease, border-color .18s ease, transform .18s ease;
}

.wp-block-button__link:hover {
	transform: translateY(-1px);
}

/* .btn--primary */
.wp-block-button.is-style-primary .wp-block-button__link {
	background: var(--orange-500);
	color: var(--white);
}

.wp-block-button.is-style-primary .wp-block-button__link:hover {
	background: var(--orange-600);
	color: var(--white);
}

/* .btn--ghost */
.wp-block-button.is-style-ghost .wp-block-button__link {
	background: transparent;
	color: var(--navy-800);
	border-color: var(--line-strong);
}

.wp-block-button.is-style-ghost .wp-block-button__link:hover {
	border-color: var(--navy-800);
	color: var(--navy-800);
	background: rgba(30, 37, 80, 0.03);
}

/* .btn--onnavy
   The design states no hover for this one, so neither does this. The colour
   therefore holds through a hover where the design's own button would briefly
   turn orange under site.css §3's `a:hover`: the block style selector is a
   class heavier than that rule, where the design's single class was not. */
.wp-block-button.is-style-onnavy .wp-block-button__link {
	background: var(--orange-500);
	color: var(--white);
}

/* The design puts an inline <svg> inside the button. A bound core/button has no
   room for child markup, so the icon is drawn from the same sprite path as a
   masked pseudo-element. Same shape, same currentColor. */
.wp-block-button.has-icon-phone .wp-block-button__link::before {
	content: "";
	flex: none;
	width: 17px;
	height: 17px;
	background: currentColor;
	-webkit-mask: var(--icon-phone) center / contain no-repeat;
	mask: var(--icon-phone) center / contain no-repeat;
}

/* Same treatment for the service switcher's per-treatment booking link, drawn
   from the calendar glyph already in assets/sprite.svg as i-calendar. */
.wp-block-button.has-icon-calendar .wp-block-button__link::before {
	content: "";
	flex: none;
	width: 17px;
	height: 17px;
	background: currentColor;
	-webkit-mask: var(--icon-calendar) center / contain no-repeat;
	mask: var(--icon-calendar) center / contain no-repeat;
}

:root {
	--icon-phone: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23000' stroke-width='1.7' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M5 3.5h3.5l1.8 4.4-2.3 1.4a12 12 0 0 0 5.7 5.7l1.4-2.3 4.4 1.8V18a2.5 2.5 0 0 1-2.7 2.5A16.5 16.5 0 0 1 2.5 6.2 2.5 2.5 0 0 1 5 3.5z'/%3E%3C/svg%3E");
	--icon-calendar: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23000' stroke-width='1.7' stroke-linecap='round' stroke-linejoin='round'%3E%3Crect x='3.5' y='5.5' width='17' height='15' rx='2'/%3E%3Cpath d='M3.5 10.5h17M8 3.5v4M16 3.5v4'/%3E%3C/svg%3E");
}

/* Stacked buttons ----------------------------------------------------------
   The design's sidebar card is
     <div class="card stack"><a class="btn btn--primary">…</a><a class="btn">…</a></div>
   and .stack is `display:flex; flex-direction:column; gap` with no align-items,
   so the two anchors take the default `stretch` and fill the card.

   core/buttons cannot be that element. It renders a wrapper <div> around every
   button, and a vertical flex layout brings a generated container rule of core's
   own - `flex-direction:column; align-items:flex-start` - which is a decision
   the design does not make. flex-start is what leaves the two buttons at their
   text widths, one short and one shorter, instead of the matched pair the design
   draws.

   Restated at .wp-block-buttons.stack so it out-specifies that generated rule
   whichever order the two arrive in, and carried down to both the wrapper and
   the anchor, because a stretched wrapper with an inline-flex anchor inside it
   is still a short button. Nothing new is decided: this is site.css's .stack,
   said against the markup core produces.

   Reaches the same card on the service category template, which writes this
   markup inline and had the same divergence. */

.wp-block-buttons.stack {
	flex-direction: column;
	align-items: stretch;
	gap: var(--sp-3);
}

.wp-block-buttons.stack > .wp-block-button,
.wp-block-buttons.stack > .wp-block-button > .wp-block-button__link {
	width: 100%;
}

/* File ---------------------------------------------------------------------
   core/file renders
     <div class="wp-block-file"><object class="wp-block-file__embed"></object>
       <a>name</a><a class="wp-block-file__button wp-element-button">Download</a>
     </div>
   which is also what the [pdf] shortcode prints - see amclinic-core's
   includes/content/pdf.php. The design draws no file download, so nothing new
   is decided here: the button is the design's .btn.btn--ghost, the secondary
   action beside a link, and the name is set at the button's size so the two
   read as one line.

   Without this core sets the pair at .8em and the button in its own dark
   global button colours. The size is given to each anchor rather than the
   wrapper, because core's .8em is on the wrapper at two classes, where a rule
   of ours would tie with it and be settled by whichever sheet printed last. */

.wp-block-file > a {
	font-size: var(--step-0);
}

/* .btn.btn--ghost */
.wp-block-file .wp-block-file__button {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	gap: var(--sp-2);
	min-height: 48px;
	padding: 0 var(--sp-4);
	border: 1px solid var(--line-strong);
	border-radius: var(--radius-pill);
	background: transparent;
	color: var(--navy-800);
	font-size: var(--step-0);
	font-weight: 600;
	line-height: 1;
	text-decoration: none;
	cursor: pointer;
	white-space: nowrap;
	transition: background-color .18s ease, color .18s ease, border-color .18s ease, transform .18s ease;
}

/* Core also fades its button on hover, which the design's does not. */
.wp-block-file .wp-block-file__button:hover {
	transform: translateY(-1px);
	border-color: var(--navy-800);
	color: var(--navy-800);
	background: rgba(30, 37, 80, 0.03);
	opacity: 1;
}

/* Hero meta ----------------------------------------------------------------
   The design uses <span> children; core/paragraph renders <p>. site.css styles
   .hero__meta span, so the same rules are restated for the paragraph. */

.hero__meta p {
	display: inline-flex;
	align-items: center;
	gap: 8px;
	margin: 0;
	max-width: none;
}

/* Hero image ---------------------------------------------------------------
   The design fills .hero__aside with a .ph placeholder at height:100%;width:100%
   and notes that it should be swapped for a real image. core/image renders
     <figure class="wp-block-image"><img>
   with a default figure margin, so the same fill behaviour is restated for it.
   object-fit is what "fill this box with a photograph" means once there is an
   actual image, which .ph never had to express.

   Nor did .ph have to express being taken out of flow, and this does. A <div>
   has no intrinsic height, so the design's placeholder takes whatever height
   .hero__aside ends up with - its min-height, or the copy column beside it,
   whichever is taller. An <img> has one, and width:100% in a column ~700px wide
   turns the theme's 4:5 placeholder into 875px of hero before height:100% is
   ever resolved: the row it is meant to fill is sized from it. Absolute against
   the aside - which site.css already makes position:relative - is what restores
   the design's arrangement, where the box decides and the picture fills it.

   The height below holds on the front end and not in the editor, where core
   prints an inline one of its own; see Editor canvas at the end of this
   file. */

.hero__aside .wp-block-image {
	position: absolute;
	inset: 0;
	height: 100%;
	width: 100%;
	margin: 0;
}

.hero__aside .wp-block-image img {
	display: block;
	height: 100%;
	width: 100%;
	object-fit: cover;
}

/* Separator ----------------------------------------------------------------
   core/separator is drawn as a border:
     .wp-block-separator { border-top: 2px solid currentColor; }
   where the design's .rule is a filled bar. Core's rule ships in the block
   library stylesheet, which always loads, so the design has to be restated at
   a specificity that wins rather than relying on load order. */

hr.wp-block-separator.rule {
	width: 56px;
	max-width: 56px;
	height: 3px;
	border: 0;
	background: var(--orange-500);
	opacity: 1;
	margin: var(--sp-4) 0;
}

/* Headings and paragraphs --------------------------------------------------
   core/heading adds .wp-block-heading; core/paragraph with a className emits
   exactly the design's markup wherever the design's own element is a <p>.
   site.css styles both by element, and wp-block-styles is not enabled, so there
   is nothing to restate. Where a paragraph stands in for some other element the
   section that does it restates the difference — see the trust bar. */

/* Group wrappers -----------------------------------------------------------
   core/group adds its own class to elements the design styles by their design
   class alone. Nothing to restate; noted so the class is not mistaken for a
   hook that can be styled. */

/* Icon block ---------------------------------------------------------------
   amclinic-ai/icon renders the design's own icon holder - <span class="chip">
   for the Dark and Light styles, <span class="step__icon"> for Numbered step,
   <span class="icon-lead"> for Inline lead - so site.css styles it unchanged
   and the added wp-block class is not a styling hook. Only the light variant
   needs restating: the design expresses it as a second class, .chip--light, and
   a block style variation can only offer is-style-light. Numbered step and
   Inline lead need nothing, because the block emits the design's class itself
   rather than adding to .chip. */

.wp-block-amclinic-ai-icon.is-style-light {
	background: var(--cream-deep);
	color: var(--navy-700);
}

/* Light, small is the same again with a size added: .chip--light.chip--sm, the
   30px cream chip the free health advice page leads its disclaimer with. Light
   is offered at both sizes and Solid at one because that is how the design uses
   them - a navy pill is only ever the small one. */

.wp-block-amclinic-ai-icon.is-style-light-sm {
	width: 30px;
	height: 30px;
	background: var(--cream-deep);
	color: var(--navy-700);
}

.wp-block-amclinic-ai-icon.is-style-light-sm .icon {
	width: 16px;
	height: 16px;
}

/* Solid is the same case again: the design writes .chip--solid.chip--sm - a
   filled navy pill, smaller than the square chip - and a block style variation
   can only offer is-style-solid. The two design classes are one look and are
   only ever used together, so the style is both of them. */

.wp-block-amclinic-ai-icon.is-style-solid {
	width: 30px;
	height: 30px;
	border-radius: var(--radius-pill);
	background: var(--navy-800);
	color: var(--white);
}

.wp-block-amclinic-ai-icon.is-style-solid .icon {
	width: 16px;
	height: 16px;
}


/* Trust bar ----------------------------------------------------------------
   The design writes each proof point as
     <span><b>title</b><span>description</span></span>
   and styles the two lines as `.trustbar__item span` and `.trustbar__item b`.
   Both lines are core/paragraph here, so neither selector reaches them: the
   shared rule below restates the first, and .trustbar__title the second.
   core/paragraph also renders <p>, which site.css §3 gives a bottom margin and
   a measure that the design's inline elements never had, so those are cleared
   as well.

   The fourth item's lines come from clinic detail blocks that render the
   design's own <b> and <span>, which site.css still reaches; nothing here
   applies to them. */

.trustbar__item p {
	margin: 0;
	max-width: none;
	font-size: var(--step--1);
	color: #b9c0dd;
}

.trustbar__item .trustbar__title {
	display: block;
	color: var(--white);
	font-weight: 600;
	font-size: var(--step-0);
}


/* Reviews ------------------------------------------------------------------
   One rule, for one element. The design writes the aggregate score as
     <div class="score"><b>4.9</b><span class="stars">…</span></div>
   and styles the figure as `.score b`. It is a bound value, so it has to be a
   block, and no core block renders a bare <b> - it is a paragraph here, which
   that selector does not reach. site.css §3 also gives <p> a bottom margin and
   a measure that the design's <b> never had; inside a baseline-aligned flex row
   of two items the margin is height the design does not have, so both are
   cleared, as they are for the trust bar's paragraphs.

   The stars beside it are still the design's own <span>, held in a core/html
   block so an editor can remove them, so `.stars` reaches them unchanged.

   The quote cards need nothing. core/quote renders the design's <blockquote>
   and <cite> around a core/paragraph <p>, which is the design's markup element
   for element, so `.card`, `.card--pad`, `.quote`, `.quote p` and `.quote cite`
   all apply as written. Core's own quote stylesheet adds only box-sizing,
   overflow-wrap and `display: block` on the cite, none of which the design
   contradicts. */

.score p {
	margin: 0;
	max-width: none;
	font-family: var(--font-display);
	font-size: 3rem;
	font-weight: 500;
	color: var(--navy-800);
	line-height: 1;
}


/* Concern grid -------------------------------------------------------------
   The design writes each card as a single anchor:
     <a class="concern" href="…">
       <span class="chip chip--light">…</span>
       <span class="concern__title">…</span>
       <span class="concern__more">Explore →</span>
     </a>
   No core block renders an anchor around other blocks, so the card is a group
   <div class="concern"> and the link moves inside it, onto the title - see
   patterns/health-concerns.php for why the title carries it rather than the
   "Explore" line. `.concern`, `.concern__title`, `.concern__more` and
   `.concern .chip` all still reach the elements site.css wrote them for. Three
   things do not.

   Both lines are core/paragraph where the design has <span>, so site.css §3
   gives them a bottom margin and a measure the design's inline elements never
   had - the same two declarations the hero's meta lines, the reviews score and
   the trust bar's paragraphs already clear. */

.concern p {
	margin: 0;
	max-width: none;
}

/* The title's text now sits inside an <a>, and neither rule that used to dress
   it reaches a child anchor: the design's colour is on `.concern__title` and
   its `text-decoration: none` is on `.concern`. Both are restated. The hover
   is restated too - site.css §3 turns a hovered link orange, where the design's
   card answers a hover with its border and a lift and leaves the title navy. */

.concern__title a {
	color: inherit;
	text-decoration: none;
}

.concern__title a:hover {
	color: inherit;
}

/* The design's click target is the whole card. A link round the title alone
   would leave the chip and the "Explore" line dead, so it is stretched back
   over the card it used to be: the same hit area, stated for markup that
   cannot nest the way the design's does. The lift on hover still belongs to
   `.concern`, which the overlay sits inside. */

.wp-block-group.concern {
	position: relative;
}

.concern__title a::after {
	content: "";
	position: absolute;
	inset: 0;
}

/* …but on the front end only. In the editor the overlay would cover the chip
   and the "Explore" line and swallow the clicks that select them, which is the
   one thing making the section blocks was for. add_editor_style() scopes this
   file to the canvas wrapper and leaves selectors that already name that class
   alone (EDITOR_STYLE_TRANSFORM_OPTIONS in block-editor.js, verified in 7.0.4),
   so the rule below matches while editing and never once the page is served. */

.editor-styles-wrapper .concern__title a::after {
	content: none;
}


/* Centred section head ------------------------------------------------------
   One rule, and it exists because of another rule in this file rather than
   because of anything core does. The design centres the head's parts with

     .sec-head--center p    { margin-inline: auto }
     .sec-head--center .rule { margin-inline: auto }

   The paragraph selector still reaches core/paragraph. The rule does reach the
   separator - `.rule` is written onto the block - but the Separator section
   above restates the design's bar as `hr.wp-block-separator.rule`, which is a
   class heavier and takes the whole `margin` shorthand with it, including the
   margin-inline the design set to auto. So the bar lands hard left instead of
   under the centred heading. Restated here at a weight that clears it.

   It applies to every centred head that has become blocks - the concern grid,
   the journey and the why cards - and nothing else in one of those heads needs
   anything: the eyebrow and the heading are the design's own elements. */

.sec-head--center hr.wp-block-separator.rule {
	margin-inline: auto;
}


/* Patient journey ----------------------------------------------------------
   Nothing to restate in the step itself; one rule below that is not a
   restatement at all, flagged as such.

   The design's step is
     <li class="step"><span class="step__icon">…</span><div><h3>…</h3><p>…</p></div></li>
   and every part of it is the element site.css addresses. `.step h3` and
   `.step p` reach core/heading and core/paragraph, which render <h3> and <p>;
   the icon block renders the `.step__icon` span itself under its Numbered step
   style, so the counter that draws the step number increments as the design
   says; and `.steps`, `.step` and the <ol>/<li> they are written on come from
   group blocks with those tags. The measure and bottom margin site.css §3 gives
   a <p> are not cleared here as they are elsewhere, because the design's step
   description is a real <p> and already carries them - `.step p` narrows the
   measure to 30ch and centres it. */

/* A row of steps that does not fill its tracks -----------------------------
   READ THIS BEFORE COPYING IT. Unlike everything else in this file, the rule
   below is not a restatement: it decides something site.css does not say. It
   is here under D11 rather than D6 - the section was made editable, and being
   editable creates a state the design was never drawn in.

   site.css lays the steps out on an explicit five-track grid:

     .steps { display: grid; grid-template-columns: repeat(5, minmax(0, 1fr)); }
     @media (max-width: 1080px) { .steps { …repeat(3, minmax(0, 1fr)) } }
     @media (max-width:  620px) { .steps { …1fr } }

   The tracks exist whether or not there are steps to fill them, and a 1fr
   track always takes its share of the width, so four steps occupy tracks 1-4
   and the row hangs off the left. Before the conversion there were always
   exactly five and it never showed; an editor can now delete one.

   Two things follow from the grid being explicit, and this rule answers both:

   1. Under-fill - fewer steps than tracks, the case above.
   2. A partial last row - five steps in the 3-up range between 620px and
      1080px render as three then two, and that second row is left-aligned.
      That one is not new. It is how the design behaves today on a tablet.

   Flex answers both because justify-content centres every line a wrapping
   container produces, where a grid's justify-content aligns the track set as
   a whole and cannot reach a short second row. The basis reproduces the width
   a 1fr track resolves to, so at five steps the layout is the design's exactly
   - same widths, same gutters, centring with no free space to distribute - and
   below five the row keeps that width and centres instead of stretching.

   The basis restates the track count and the gap by hand, which is the cost of
   this approach: it has to be re-derived if site.css ever changes either. Each
   breakpoint therefore names its own, in the same order and at the same widths
   site.css states them. min-width is what minmax(0, …) was doing - without it
   a flex item refuses to shrink below its content.

   The 0.05px is not a fudge, it is the one thing that makes this safe. A full
   row is five bases plus four gaps and that comes to exactly 100%, so whether
   the fifth step fits rests on how the browser rounds a division it cannot do
   exactly - and browsers lay out in fixed units, 1/64px in Blink. Rounded up,
   five bases exceed the row by up to 5/64px and the fifth step wraps onto a
   line of its own. Flex-shrink does not save it: lines are broken before any
   shrinking happens. Taking a twentieth of a pixel off each base puts a
   quarter-pixel of slack in the row, which covers the worst rounding and is
   below anything a screen can show.

   Reverting is one block: delete these four rules and the grid returns. */

.steps {
	display: flex;
	flex-wrap: wrap;
	justify-content: center;
}

.steps > .step {
	flex: 0 1 calc((100% - 4 * var(--sp-4)) / 5 - 0.05px);
	min-width: 0;
}

@media (max-width: 1080px) {

	.steps > .step {
		flex-basis: calc((100% - 2 * var(--sp-4)) / 3 - 0.05px);
	}
}

@media (max-width: 620px) {

	.steps > .step {
		flex-basis: 100%;
	}
}


/* Split section head --------------------------------------------------------
   The design writes the arrow link as a direct child of the split head:
     <div class="sec-head sec-head--split"><div>…</div><a class="link-arrow">
   No core block renders a bare anchor, so it is a core/paragraph holding that
   same anchor. `.link-arrow` still reaches the anchor, so nothing about the
   link itself needs restating; it is the paragraph around it that is new, and
   it becomes the flex item the anchor used to be. site.css §3 gives every <p> a
   bottom margin and a measure the design's anchor never had, so both are
   cleared - the same two declarations the hero's meta lines and the reviews
   score already need, for the same reason. */

.sec-head--split > p {
	margin: 0;
	max-width: none;
}


/* Practitioners ------------------------------------------------------------
   The design writes the team grid as
     <div class="grid grid--4"><article class="person">
   The section is a Query Loop, so core/post-template writes
     <ul class="wp-block-post-template grid grid--4"><li class="wp-block-post">

   The list takes the grid classes from the pattern and they apply unchanged.
   The item does not: core generates each <li> itself, with get_post_class()
   deciding its classes, and there is no attribute anywhere in the block that
   reaches it. So `.person` is restated here against the item, and the pattern
   marks the list `.people` to say which items are meant. Verified against
   render_block_core_post_template() in wp-includes/blocks/post-template.php.

   Nothing else in the card needs restating. `.person__body`, `.person__name`
   and `.person__role` are written onto real blocks and reach the design's own
   rules; core's post-title and post-excerpt stylesheets add only box-sizing and
   word-break, and the portrait states its 4:5 ratio through the featured image
   block's own attributes rather than through `.ph--portrait`.

   The two rules are in the order site.css states them, because the design
   depends on that order: `.person p` is the more specific selector and takes
   the paragraph colour back off `.person__role`. Restating them the other way
   round would turn that into an orange line the design does not have. */

.people > .wp-block-post {
	background: var(--white);
	border: 1px solid var(--line);
	border-radius: var(--radius-lg);
	overflow: hidden;
}

.people > .wp-block-post p {
	font-size: var(--step--1);
	color: var(--ink-soft);
	line-height: 1.6;
}


/* Visit --------------------------------------------------------------------
   The navy details panel and the map beside it. Five rules: one for a colour
   the design writes inline, one for a rule this file has already overridden,
   two for the inline elements core has no block for, and one for the frame
   that replaces the design's map placeholder.

   The eyebrow is `<p class="eyebrow" style="color:#b9c0dd">` in the design, the
   one colour in it written inline rather than in site.css, because it is the
   only eyebrow that sits on navy. theme.json sets color.custom to false, so the
   editor cannot offer an arbitrary hex and a block cannot carry one; the
   colour moves onto the design's own class instead.

   The separator loses its colour to this file rather than to core. The
   Separator section above restates `.rule` as `hr.wp-block-separator.rule`,
   which is a class heavier than site.css's `.visit__panel .rule` and takes the
   panel's narrow translucent bar with it. Restated here at a weight that
   clears it, in the two declarations site.css writes.

   The list items read
     <li><span class="chip">…</span><span><b>…</b><span>…</span></span></li>
   and site.css styles the two lines as `.visit__list b` and `.visit__list span`.
   Both lines are core/paragraph here, so neither selector reaches them:
   `.visit__list p` restates the description and `.visit__title` the line above
   it - the same split, for the same reason, as the trust bar's. The bottom
   margin and measure site.css §3 gives a <p> go with them, as they do wherever
   a paragraph stands in for an inline element.

   The address is the exception, and needs nothing: it is a clinic detail block,
   which renders the design's own <span>, so `.visit__list span` still reaches
   it exactly as written.

   The map is a clinic map block, which renders an <iframe>. What the design has
   there is `.visit__map.ph`, and `.ph` is the half that states the fill - width
   and height 100% - while `.visit__map` gives the grid cell its minimum height.
   The frame replaces the placeholder, so it takes the placeholder's fill. A
   frame is also inline and 300x150 by default, which is what the display and
   the border are for; mjm-clinic states all four for the block itself, but at
   no specificity, so this section's names win wherever the two meet. */

.visit__panel .eyebrow {
	color: #b9c0dd;
}

.visit__panel hr.wp-block-separator.rule {
	width: 40px;
	background: rgba(255, 255, 255, .35);
}

.visit__list p {
	margin: 0;
	max-width: none;
	font-size: var(--step--1);
	color: #b9c0dd;
}

.visit__list .visit__title {
	display: block;
	color: var(--white);
	font-weight: 600;
}

.visit__map {
	display: block;
	width: 100%;
	height: 100%;
	border: 0;
}


/* Service category page -----------------------------------------------------
   The treatment switcher itself needs nothing here: mjm-clinic/service-tabs
   renders the design's own markup, because inc/blocks.php hands the plugin the
   design's class names. Nor does the check list of what a first appointment
   includes - core/group's tagName carries the design's <ul> and <li>, as the
   visit panel's list already does, and the tick is an amclinic-ai/icon under
   its Plain style, which renders the design's own <svg class="icon">. What is
   left is the three places where core's markup and the design's differ.

   (1) The treatment panel's picture. The design fills .treatment__media with a
   .ph placeholder, and the switcher puts the service's cover image there when
   there is one. object-fit is what "fill this box" means once there is an
   actual photograph, exactly as it is for the hero image above.

   (2) The price list. The design writes it as
     <dl class="price-list"><div><dt>name</dt><dd>price</dd></div>
   and a dt and a dd are the two elements a group and a paragraph cannot be:
   core/paragraph always emits <p>. Tagging the list <dl> anyway would put <p>
   children inside a <dl>, which is not valid, so the list and its rows are
   divs - `.price-list` and `.price-list > div` still reach both - and the dt
   and dd rules are restated against the two paragraphs. The margin site.css §3
   gives every <p> goes with them; the design's dt and dd carry none.

   The offer row's name runs to two lines - the name, then the offer itself in
   smaller muted type - which the design writes inside the dt, after a <br>. A
   paragraph cannot hold a second paragraph, so that cell is a group of two,
   and the dt rules name it as well. The row's colour then has to out-specify
   them, because they name a child position and it names a class.

   (3) Four inline declarations the design writes on elements that are now
   blocks. A block's style attribute is serialised from its attributes, so a
   hand-written one would invalidate the block; each is restated where the
   design writes it, and nowhere else. */

.treatment__media img {
	display: block;
	height: 100%;
	width: 100%;
	object-fit: cover;
}

.price-list > div > p,
.price-list > div > div > p {
	margin: 0;
}

.price-list > div > p:first-child,
.price-list > div > div > p:first-child {
	font-size: var(--step--1);
	font-weight: 600;
	color: var(--navy-800);
}

.price-list > div > p:last-child {
	font-family: var(--font-display);
	font-size: var(--step-1);
	color: var(--navy-800);
	white-space: nowrap;
}

/* The offer row, both cells. The two rules above are worth a class and two
   elements each, so naming .is-offer alone loses to them and the position has
   to be named again with it. The old price keeps the muted grey site.css gives
   every <s> in the list, as it does in the design. */
.price-list .is-offer > p:last-child,
.price-list .is-offer > div > p:first-child {
	color: var(--orange-600);
}

/* The offer line under the name. .fine (site.css §3) is the design's own class
   and carries the size and the muted colour - which is why the line is grey on
   an orange row there too, the class beating what the dt around it passes down.
   The weight is the one thing left: the design resets the dt's 600 inline. */
.price-list .fine {
	font-weight: 400;
}

/* The section head over the treatments: 56ch rather than the 34ch .lede carries
   for a hero column. */
.svc-layout .sec-head .lede {
	max-width: 56ch;
}

/* The aside cards' headings: --step-1, the size the design also gives .callout
   h3, with the same gap under them as the card's other openers. */
.svc-aside .card > h3 {
	font-size: var(--step-1);
	margin-bottom: var(--sp-3);
}

/* The aside's arrow link, at the aside's own --step--1 rather than .link-arrow's
   --step-0. It cannot simply inherit: .link-arrow sets a size of its own. */
.svc-aside .link-arrow {
	font-size: var(--step--1);
}

/* A section head after the first one in the column sits further from the section
   above it and closer to the paragraph below than .sec-head's own --sp-6 gap.
   The design writes exactly that as an inline style on every head below the
   treatments - see the four in design-assets/chinese-herbal-medicine.html - and
   a block's style attribute is serialised from its attributes, so it is a class
   here instead. Keyed on both classes, so it reaches those heads and not the one
   over the treatments, which opens the column and needs no extra room.

   It was written for the journey head the template used to carry. That head has
   gone - what a first appointment involves is not the same sentence for massage
   as for herbs, so it is a category's to write - and the rule is now for the
   heads an editor writes in Main content, which is where those sections live. */
.svc-layout .sec-head.mt-5 {
	margin-top: var(--sp-7);
	margin-bottom: var(--sp-4);
}


/* FAQ group ----------------------------------------------------------------
   .faq-group has no counterpart in the design, which writes a group's heading
   and its .faq accordion as two siblings of the section that holds them. A
   synced pattern cannot: render_block_core_block() emits the record's blocks
   with no element of its own, so those two siblings became two children of
   whatever the pattern was dropped into, and a two column grid holding two
   groups laid out four cells - every heading in a column to the left of its own
   answers. inc/faq.php wraps each group in one element so the pair is one item;
   these two declarations are what the wrapper needs to sit in a track like the
   design's own element would.

   min-width undoes the min-width: auto every grid item starts with, which a
   long question would otherwise push its track past. align-self undoes the
   align-items: center that core's flex layout gives every is-layout-flex
   container (block-supports/layout.php), which would float a short group
   against the middle of a taller one in a Row. Neither is a design decision:
   the design's own heading and accordion are in normal flow, top aligned and
   inside .wrap, and this is what it takes for the wrapper to render the same. */
.faq-group {
	min-width: 0;
	align-self: start;
}


/* Footer brand column ------------------------------------------------------
   The design writes the first column as

     <div>
       <span class="brand brand--footer"><img class="brand__wordmark" …></span>
       <p class="site-footer__tag">…</p>
       <p>…</p>

   The two paragraphs are core/paragraph and land on the design's own elements,
   so `.site-footer__tag` and `.site-footer p` apply as written.

   The wordmark is amclinic-ai/brand, which prints the design's own <span> - the
   theme's blocks render the design element itself rather than one with
   something added, so there is nothing to restate here. It is a block only
   because a template part is static HTML and cannot name the theme directory;
   see blocks/brand/render.php.

   Note this is why the mark is not core/site-logo: that block wants a file
   uploaded to the media library, has no second cut for a dark ground, and
   renders <div class="wp-block-site-logo"><a><img class="custom-logo">> - a
   block-level wrapper where the design has an inline element, which would need
   the whole of `.brand` restating against it. */

/* Social links -------------------------------------------------------------
   The design writes the row as three hand-written anchors round sprite
   symbols:

     <div class="socials"><a href="#" aria-label="Instagram"><svg class="icon">

   which fixes both the networks and their order in the markup. It is
   core/social-links here, so the networks are chosen from the block's own
   service picker, and each link's URL is typed in the editor. Core supplies the
   brand glyph for whichever service is chosen, so the three sprite symbols
   i-instagram, i-facebook and i-x are no longer drawn by this row - they stay in
   the sprite, and the icon block still offers them.

   `.socials` is written onto the block and reaches the <ul> core renders, so the
   row's own flex, gap and margin-top are the design's. The list needs no
   list-style reset: core gives the item `display: block`, then `inline-block`,
   and an <li> that is not `display: list-item` draws no marker.

   Everything below restates the design's anchor against core's. Core states the
   anchor's colour at four classes -

     .wp-block-social-links .wp-block-social-link.wp-social-link
       .wp-block-social-link-anchor { color: currentColor; fill: currentColor }

   which is heavier than the design's `.socials a`, so the design's rules are
   restated at core's own selector plus the design's class. That matters for the
   hover, where the design changes the colour and core's rule would otherwise
   hold it at the inherited one. The resting state agrees either way: core's
   currentColor resolves to the #b4b8c2 that `.site-footer` sets.

   The block carries the Logos Only style because the design has no filled pill
   behind the glyph: core's default style paints one per service, and logos-only
   also drops the 0.25em anchor padding that would push the circle past 40px. */

.socials.wp-block-social-links .wp-block-social-link.wp-social-link .wp-block-social-link-anchor {
	width: 40px;
	height: 40px;
	border-radius: 50%;
	display: grid;
	place-items: center;
	border: 1px solid #2c2f38;
	color: #b4b8c2;
	text-decoration: none;
}

.socials.wp-block-social-links .wp-block-social-link.wp-social-link .wp-block-social-link-anchor:hover {
	border-color: var(--white);
	color: var(--white);
}

/* The design sizes the glyph in pixels; core sizes it as 1em of the list's own
   24px font-size. Restated above core's two-class rule so it holds whichever
   order the two stylesheets print in - core loads social-links as a separate
   handle when split block assets are on. */
.socials.wp-block-social-links .wp-block-social-link.wp-social-link .wp-block-social-link-anchor svg {
	width: 18px;
	height: 18px;
}

/* Not a restatement: core lifts the item on hover, which the design does not
   describe. The design answers a hover with the border and the glyph turning
   white, so the scale is removed rather than left to run alongside it. */
.socials .wp-block-social-link:hover {
	transform: none;
}


/* Footer base line ---------------------------------------------------------
   The design writes the copyright as a <span> inside `.site-footer__base` and
   colours it by inheritance, from the bar itself. It is a core/paragraph here,
   so besides the bottom margin and the measure that every other converted line
   clears, the colour has to be restated: a <p> is reached directly by
   `.site-footer p`, where the design's <span> was not, and an inherited colour
   loses to any rule that names the element. The font size still comes from the
   bar, which nothing here disturbs. */

.site-footer__base p {
	margin: 0;
	max-width: none;
	color: #7d8290;
}


/* Footer clinic details ----------------------------------------------------
   One rule, for the one element that changed. The design writes the contact
   list as

     <ul class="footer-contact">
       <li><span class="icon-lead">…</span><span>…</span></li>

   and all three of its values - address, telephone, opening hours - are
   recorded against the clinic location, so each is a clinic detail block. That
   block is the right tool here for the reason patterns/trust-bar.php gives: the
   telephone has to be a tel: anchor and the address a run of lines broken by
   <br>, neither of which a core block can produce.

   The list and each row are group blocks, and core/group tags itself div,
   header, main, section, article, aside or footer - never <ul> or <li> - so the
   list is a <div> and the rows are <div>s. `.footer-contact` is written on the
   list and applies as it stands; list-style, margin and padding are inert on a
   <div> and the flex column is what draws the rows. `.footer-contact li` is the
   one selector that no longer reaches anything, restated below.
   `.footer-contact a` still reaches the telephone.

   The icon is an amclinic-ai/icon block under its Inline lead style, which
   renders the design's own <span class="icon-lead"> - the same arrangement the
   trust bar uses for its chips, and for the same reason: which icon a row
   carries is an editorial choice, and as raw markup it could only be changed by
   editing SVG by hand. The row groups are locked, but a lock on a template
   stops a block being moved or removed, not configured, so the style and the
   variation picker both stay live in the toolbar.

   It is a block in its own right rather than something the value block draws,
   which keeps each value in an element of its own. The address needs that: its
   lines are broken by <br>, and a <br> among the children of a flex container
   is a flex item rather than a line break. */

.footer-contact > * {
	display: flex;
	gap: var(--sp-2);
}


/* Footer navigation --------------------------------------------------------
   In the design .footer-nav is a bare <ul>. As a block it is a non-responsive
   vertical core/navigation:
     <nav class="wp-block-navigation footer-nav …"><ul class="wp-block-navigation__container">
   so the design's list rules are restated against the inner ul, at two classes
   so they clear core's per-instance layout styles whatever order those print
   in.

   The link rules need more weight: core writes the item colour as
   `.wp-block-navigation .wp-block-navigation-item__content.wp-block-navigation-item__content
   { color: inherit }` (three classes), and site.css §6 describes the HEADER
   item against the same generic classes — semibold, 44px tall, padded — which
   reaches the footer items too. Both are settled at three classes here, with
   the design's plain footer link restated explicitly. */

.wp-block-navigation.footer-nav {
	/* Core defaults the nav element's flex gap to 2em and the ul inherits it. */
	gap: var(--sp-2);
}

.footer-nav .wp-block-navigation__container {
	display: flex;
	flex-direction: column;
	align-items: flex-start;
	gap: var(--sp-2);
	list-style: none;
	margin: 0;
	padding: 0;
}

.wp-block-navigation.footer-nav .wp-block-navigation-item__content {
	min-height: 0;
	padding-inline: 0;
	font-weight: 400;
	white-space: normal;
	color: #b4b8c2;
	text-decoration: none;
}

.wp-block-navigation.footer-nav .wp-block-navigation-item__content:hover {
	color: var(--white);
}

/* Navigation ---------------------------------------------------------------
   site.css describes the navigation in core/navigation's own class names, so
   the design applies to a core/navigation block directly and this file has
   only two jobs.

   1. Reconcile markup core emits that the design has no counterpart for.
   2. Carry site.css's navigation cascade over core's block library styles.

   On (2): enqueue.php loads site.css after wp-block-library, which settles ties
   but not specificity, and core's navigation sheet reaches seven classes with
   !important inside the overlay. The generated block at the end of this file
   restates every one of site.css's nav rules at a single shared increment.
   It has to be every rule at the same increment - lifting only the losing ones
   reorders the design against itself and the dropdowns stop opening. */

/* (1) Markup core adds that the design does not describe --------------------
   Core pads its overlay as a full-screen modal - a clamp() inset on the
   container and room for the close button above the content. The design's
   drawer is a panel flush under the header and provides its own spacing. */
.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container.is-menu-open {
	padding: 0;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container.is-menu-open .wp-block-navigation__responsive-container-content {
	padding-top: 0;
}

/* Core offsets the dialog by the admin bar height while the modal is open. The
   drawer already sits below the header, which the admin bar has itself pushed
   down, so the offset would double-count. */
.site-nav[class][class][class][class][class][class] .is-menu-open .wp-block-navigation__responsive-dialog {
	margin-top: 0;
}

/* Below 600px core hides the closed drawer with display:none and opens it as a
   flex column, which defeats the design's max-height slide. The design's
   container is a plain block at every width - its closed state is already
   max-height: 0 + visibility: hidden, so it can stay a block throughout. */
.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container {
	display: block;
}

/* Core lays the drawer's content wrapper out as a flex row (column while the
   overlay is open, aligned to the nav's justification). The design's dialog is
   a plain block whose children - search, list, CTAs - are full-width and stack
   in source order, so the wrapper is flattened to a block at every width. */
.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-content {
	display: block;
}

/* Core strips the CLOSED drawer's background with
     .wp-block-navigation__responsive-container:not(.is-menu-open.is-menu-open)
     { background-color: inherit !important }
   so the white panel turns transparent the moment it starts to roll shut. The
   design's drawer is white in both states. !important is used only because
   core uses it; scoped to the drawer breakpoint - on desktop the transparent
   container is correct, sitting over the header's translucent blur. */
@media (max-width: 1080px) {

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container {
		background-color: var(--white) !important;
	}
}

/* (2) site.css's navigation cascade, carried over core ----------------------
   Regenerate after any change to site.css's nav section or a WordPress upgrade:

     python3 tools/gen-nav-overrides.py src/themes/amclinic-ai/assets/css/site.css
*/

/* Generated by tools/gen-nav-overrides.py - do not hand-edit.

   Every navigation rule in site.css, restated with 6 [class] hooks so the
   whole set clears core (heaviest core selector: 7 classes) while keeping
   site.css's own relative weights intact. Boosting rules individually would
   invert the design's cascade - see the note at the top of the script. */

.site-nav[class][class][class][class][class][class] {
	margin-inline: auto;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__container {
	flex-wrap: nowrap;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__container {
	display: flex;
	align-items: center;
	gap: var(--sp-2);
	list-style: none;
	margin: 0;
	padding: 0;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation-item {
	position: relative;
	display: flex;
	align-items: center;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation-item__content {
	display: inline-flex;
	align-items: center;
	gap: 4px;
	min-height: 44px;
	padding-inline: 14px;
	font-weight: 600;
	font-size: var(--step-0);
	white-space: nowrap;
	color: var(--navy-800);
	text-decoration: none;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation-item__content:hover {
	color: var(--orange-600);
}

.site-nav[class][class][class][class][class][class] button.wp-block-navigation-item__content {
	font-weight: 600;
	font-size: var(--step-0);
	padding-block: 0;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-icon {
	display: grid;
	place-items: center;
	width: 20px;
	height: 44px;
	margin-left: -10px;
	padding: 0;
	border: 0;
	background: none;
	color: var(--ink-muted);
	cursor: pointer;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-icon .icon {
	width: 15px;
	height: 15px;
	stroke-width: 2.2;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-open {
	display: none;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-close {
	display: none;
}

.site-nav[class][class][class][class][class][class] .nav-search {
	display: none;
}

.site-nav[class][class][class][class][class][class] .nav-cta {
	display: none;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-container {
	position: absolute;
	top: 100%;
	left: 0;
	z-index: 60;
	min-width: 268px;
	margin: 0;
	padding: var(--sp-2) 0;
	list-style: none;
	background: var(--white);
	border: 1px solid var(--line);
	border-radius: var(--radius-lg);
	box-shadow: 0 18px 44px -18px rgba(23, 28, 63, .32);
	opacity: 0;
	visibility: hidden;
	transform: translateY(6px);
	transition: opacity .16s ease, transform .16s ease, visibility .16s;
}

.site-nav[class][class][class][class][class][class] .has-child:hover > .wp-block-navigation__submenu-container {
	opacity: 1;
	visibility: visible;
	transform: translateY(0);
	width: auto;
	height: auto;
	overflow: visible;
}

.site-nav[class][class][class][class][class][class] .has-child > .wp-block-navigation-submenu__toggle[aria-expanded="true"] ~ .wp-block-navigation__submenu-container {
	opacity: 1;
	visibility: visible;
	transform: translateY(0);
	width: auto;
	height: auto;
	overflow: visible;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-container .wp-block-navigation-item {
	display: block;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-container .wp-block-navigation-item__content {
	display: block;
	min-height: 0;
	padding: 11px var(--sp-4);
	font-size: var(--step-0);
	line-height: 1.4;
	white-space: normal;
}

.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-container .wp-block-navigation-item__content:hover {
	background: var(--cream);
	color: var(--orange-600);
}

.site-nav[class][class][class][class][class][class] .has-child:hover > .wp-block-navigation-item__content {
	background: var(--cream);
	border-radius: var(--radius-pill) 0 0 var(--radius-pill);
	color: var(--navy-800);
}

.site-nav[class][class][class][class][class][class] .has-child:focus-within > .wp-block-navigation-item__content {
	background: var(--cream);
	border-radius: var(--radius-pill) 0 0 var(--radius-pill);
	color: var(--navy-800);
}

.site-nav[class][class][class][class][class][class] .has-child:hover > .wp-block-navigation__submenu-icon {
	background: var(--cream);
	border-radius: 0 var(--radius-pill) var(--radius-pill) 0;
}

.site-nav[class][class][class][class][class][class] .has-child:focus-within > .wp-block-navigation__submenu-icon {
	background: var(--cream);
	border-radius: 0 var(--radius-pill) var(--radius-pill) 0;
}

@media (max-width: 1080px) {

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-open {
		display: grid;
		place-items: center;
		width: 44px;
		height: 44px;
		padding: 0;
		margin-left: auto;
		border: 0;
		background: none;
		cursor: pointer;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-open .burger-bars {
		display: block;
		width: 20px;
		height: 2px;
		background: var(--navy-800);
		box-shadow: 0 6px 0 var(--navy-800), 0 -6px 0 var(--navy-800);
	}

	.site-nav[class][class][class][class][class][class] {
		margin: 0;
		order: 3;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container {
		position: fixed;
		inset: var(--header-h) 0 auto 0;
		background: var(--white);
		border-bottom: 1px solid var(--line);
		box-shadow: var(--shadow-md);
		max-height: 0;
		overflow: hidden;
		visibility: hidden;
		transition: max-height .3s ease, visibility .3s;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container.is-menu-open {
		max-height: calc(100vh - var(--header-h));
		overflow: auto;
		visibility: visible;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-close {
		height: 100%;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-dialog {
		padding-bottom: var(--sp-5);
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__container {
		flex-direction: column;
		align-items: stretch;
		gap: 0;
		padding: var(--sp-2) var(--gutter) 0;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__container > .wp-block-navigation-item {
		display: flex;
		flex-wrap: wrap;
		align-items: center;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__container > .wp-block-navigation-item > .wp-block-navigation-item__content {
		flex: 1;
		min-height: 56px;
		padding-inline: 0;
		font-size: var(--step-1);
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-icon {
		width: 46px;
		height: 56px;
		margin: 0;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-icon .icon {
		width: 18px;
		height: 18px;
		transition: transform .2s ease;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-icon[aria-expanded="true"] .icon {
		transform: rotate(180deg);
	}

	.site-nav[class][class][class][class][class][class] .has-child:hover > .wp-block-navigation-item__content {
		background: none;
		border-radius: 0;
	}

	.site-nav[class][class][class][class][class][class] .has-child:focus-within > .wp-block-navigation-item__content {
		background: none;
		border-radius: 0;
	}

	.site-nav[class][class][class][class][class][class] .has-child:hover > .wp-block-navigation__submenu-icon {
		background: none;
		border-radius: 0;
	}

	.site-nav[class][class][class][class][class][class] .has-child:focus-within > .wp-block-navigation__submenu-icon {
		background: none;
		border-radius: 0;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-container {
		position: static;
		flex: 0 0 100%;
		opacity: 1;
		visibility: visible;
		transform: none;
		min-width: 0;
		padding: 0;
		border: 0;
		border-radius: 0;
		box-shadow: none;
	}

	.site-nav[class][class][class][class][class][class] .has-child:has(> .wp-block-navigation__submenu-icon[aria-expanded]) > .wp-block-navigation__submenu-container {
		max-height: 0;
		overflow: hidden;
		transition: max-height 5ms linear;
	}

	.site-nav[class][class][class][class][class][class] .has-child > .wp-block-navigation__submenu-icon[aria-expanded="true"] ~ .wp-block-navigation__submenu-container {
		max-height: 560px;
		padding-bottom: var(--sp-2);
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__submenu-container .wp-block-navigation-item__content {
		padding: 12px 0 12px var(--sp-3);
		color: var(--ink-soft);
	}

	.site-nav[class][class][class][class][class][class] .nav-cta {
		display: flex;
		flex-wrap: wrap;
		gap: var(--sp-2);
		margin-top: var(--sp-3);
		padding: var(--sp-4) var(--gutter) 0;
		border-top: 1px solid var(--line);
	}

	.site-nav[class][class][class][class][class][class] .nav-cta .wp-block-button {
		flex: 1 1 210px;
	}

	.site-nav[class][class][class][class][class][class] .nav-cta .wp-block-button__link {
		display: flex;
		width: 100%;
	}

	.site-nav[class][class][class][class][class][class]:has(.is-menu-open) ~ .header__actions .icon-btn {
		display: none;
	}

	.site-nav[class][class][class][class][class][class]:has(.is-menu-open) ~ .header__actions .header__tel {
		display: none;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-close {
		display: none;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-open .burger-x {
		display: none;
		width: 24px;
		height: 24px;
		stroke-width: 2.2;
		color: var(--navy-800);
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-open[aria-expanded="true"] .burger-bars {
		display: none;
	}

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__responsive-container-open[aria-expanded="true"] .burger-x {
		display: block;
	}
}

/* (3) The block's classes are echoed onto its inner list ------------------
   Core re-emits the navigation block's wrapper classes - including custom
   ones - on the inner <ul class="wp-block-navigation__container">, so every
   .site-nav selector above also matches the list itself. Verified in rendered
   markup on WP 7.0.4.

   Almost all of that is harmless (same declarations land on the same
   elements), except site.css's element-level PLACEMENT rules for the nav
   element: `.site-nav { margin-inline: auto }` on desktop and
   `.site-nav { margin: 0 0 0 auto; order: 3 }` in the drawer breakpoint.
   Applied to the list they re-order it after the drawer's CTA buttons and
   shove it right. Restated here, after the generated block, so the list keeps
   the design's own values from `.wp-block-navigation__container`. */

.site-nav[class][class][class][class][class][class] .wp-block-navigation__container {
	margin: 0;
	order: 0;
}

/* Core's open-overlay styles stack each drawer item as a COLUMN
   (flex-direction: column on .wp-block-navigation-item), which centres the
   title and drops the chevron onto its own line. The design's drawer row is
   the title (flex: 1) beside the chevron (46px), with the submenu wrapping
   full-width underneath - all of which site.css already states except the
   direction, which it left at the browser default core now overrides. */
@media (max-width: 1080px) {

	.site-nav[class][class][class][class][class][class] .wp-block-navigation__container > .wp-block-navigation-item {
		flex-direction: row;
	}
}

/* About page sections ------------------------------------------------------
   Restatements only, for the three sections the About design adds. Each is
   either a fill the design expressed by making the box itself the placeholder,
   or one of its inline style declarations - which a block cannot carry, since a
   block's style attribute is serialised from its attributes and a hand-written
   one invalidates it. Same two causes as the hero image and the service
   category's four, and nothing new is decided here.

   (1) The split's picture. The design fills .split__media with a .ph at
   height:100%;width:100%, and site.css gives that box the rounding and the 4:3
   ratio. core/image renders a <figure> with a margin and an <img> at its
   intrinsic size, so the fill is restated exactly as it is for .hero__aside and
   .treatment__media. */

.split__media {
	margin: 0;
}

.split__media img {
	display: block;
	height: 100%;
	width: 100%;
	object-fit: cover;
}

/* (2) The overlapping portraits, which are a Query Loop over the featured
   practitioners. Same situation as the practitioner cards above: core/post-
   template generates each <li> itself and no block attribute reaches it, so
   .avatar-stack goes on the list and the design's circle is restated against
   the item.

   The design writes that circle on .ph. Everything geometric about it comes
   across - the 74px, the radius, the white ring, the overlap and the reset on
   the first - and only its font-size and padding do not, because those existed
   to inset the placeholder's caption and there is no caption on a photograph.
   Padding is zeroed rather than left out: .ph is still on the element when a
   plain image is used instead, and would otherwise inset the picture by 4px.

   The figure is given the height the .ph box had, because a featured image
   sets its own aspect-ratio and would otherwise size itself rather than fill
   the circle it is in. */

.avatar-stack > .wp-block-post {
	width: 74px;
	height: 74px;
	padding: 0;
	border: 3px solid var(--white);
	border-radius: 50%;
	overflow: hidden;
	margin-left: -16px;
}

.avatar-stack > .wp-block-post:first-child {
	margin-left: 0;
}

.avatar-stack .wp-block-image,
.avatar-stack .wp-block-post-featured-image {
	margin: 0;
	height: 100%;
}

.avatar-stack .wp-block-image img,
.avatar-stack .wp-block-post-featured-image img {
	display: block;
	height: 100%;
	width: 100%;
	object-fit: cover;
}

/* (3) The practitioners teaser's two inline declarations, scoped to .wrap.center
   - the pairing the design uses for this section and for no other. The section
   head sits closer to the portraits than a section head normally sits to what
   follows it, and its lede runs to 52ch rather than the 34ch site.css gives a
   .lede in a hero column. */

.wrap.center > .sec-head {
	margin-bottom: var(--sp-5);
}

.wrap.center .sec-head .lede {
	max-width: 52ch;
}

/* (4) The gap the design writes between a pull quote and the section head that
   follows it in the same .wrap. The quote closes a thought and the head opens
   the next one, so the two need a section's worth of air between them without
   being two sections. */

.pullquote + .sec-head {
	margin-top: var(--sp-8);
}

/* Contact list -------------------------------------------------------------
   The design writes "Get directions" and "Free Health Advice" as bare anchors,
   sitting directly in the item they belong to:
     <p>101–105 Camden High Street…</p><a class="link-arrow" href="#visit">
   No core block renders a bare anchor, so each is a core/paragraph holding that
   same anchor - the arrangement patterns/team.php describes. `.link-arrow`
   still reaches the anchor and needs nothing restated; what does is the design's
   offset above it, which is written against the anchor and cannot show on an
   inline-level box. It moves to the paragraph that is now around it, at the
   value the design gives each of the two. */

.contact-list p:has(> .link-arrow) {
	margin-top: 10px;
}

.card--cream p:has(> .link-arrow) {
	margin-top: var(--sp-3);
}


/* Fact bar -----------------------------------------------------------------
   Same situation as the trust bar above. The design writes each item as
     <div><b>claim</b><span>detail</span></div>
   and styles the two lines as `.factbar b` and `.factbar span`. Both are
   core/paragraph here, so neither selector reaches them: .factbar__title
   restates the first and the shared rule the second. core/paragraph renders
   <p>, which site.css §3 gives a bottom margin and a measure that the design's
   inline elements never had, so both are cleared - the strip is three centred
   columns and a measure would leave the text off-centre inside them. */

.factbar p {
	margin: 0;
	max-width: none;
	font-size: var(--step--1);
	color: var(--ink-muted);
}

.factbar .factbar__title {
	display: block;
	color: var(--navy-800);
	font-size: var(--step-0);
	font-weight: 700;
}


/* Card ---------------------------------------------------------------------
   The design's card is .card, and its padded form .card.card--pad - two classes
   an editor could only reach by typing them into Additional CSS classes. They
   are registered as block styles on core/group in inc/blocks.php, so the same
   box is a choice in the Styles panel; these restate the design against the
   class a style variation produces.

   Nothing new is decided here. `is-style-card` is .card.card--pad, and
   `is-style-card-cream` is that with .card--cream on top - so a group carrying
   the literal design classes and a group carrying the style render the same,
   which is what lets the two coexist while pages are moved across. */

.wp-block-group.is-style-card,
.wp-block-group.is-style-card-cream {
	background: var(--white);
	border: 1px solid var(--line);
	border-radius: var(--radius-lg);
	box-shadow: var(--shadow-sm);
	padding: var(--sp-5);
}

.wp-block-group.is-style-card-cream {
	background: var(--cream);
	border-color: transparent;
	box-shadow: none;
}

/* And what the design says about the type inside a cream card, which is the
   half of .card--cream that is not the ground it sits on.

   The card half of each selector is inside :where(), which scopes the rule
   without weighing it. Written plainly, `.wp-block-group.is-style-card-cream p`
   is two classes where the design writes one, and it reaches every paragraph
   nested anywhere inside the card - including paragraphs belonging to a
   component with type rules of its own, .numlist being the first to arrive. In
   the design those components win, being written later at equal weight; two
   classes turned that round, so a numbered list dropped into a cream card came
   out in the card's type rather than its own, headings and all.

   Weightless, these rules sit at the same 0-0-1 as the base `p` and `h3` they
   are here to beat, and lose - as the design's do - to any component that has
   said something about its own type. Which is what the note above promises: a
   group carrying the literal design classes and a group carrying the style
   render the same. */

:where(.wp-block-group.is-style-card-cream) h3 {
	font-family: var(--font-sans);
	font-size: var(--step-0);
	font-weight: 700;
	margin: 0 0 var(--sp-2);
}

:where(.wp-block-group.is-style-card-cream) p {
	margin: 0;
	color: var(--ink-soft);
	font-size: var(--step--1);
}

:where(.wp-block-group.is-style-card-cream) .link-arrow {
	margin-top: var(--sp-3);
	font-size: var(--step--1);
	color: var(--orange-600);
}


/* Explainer page -----------------------------------------------------------
   Two elements on that page are a <span> inside a card in the design: the
   concept card's kicker and the link card's "Read more". The editor has no
   block that emits a bare span, so both arrive as paragraphs - and a paragraph
   falls inside the card's own `p` rule, which is 0-1-1 and out-ranks the
   element's own 0-1-0 class on the one property they disagree about. Left
   alone, both would come out in the card's body colour rather than orange.

   Restated against the paragraph. Nothing new is decided: these are the
   colours site.css already gives each of the two elements. */

.concept p.concept__kicker { color: var(--orange-600); }
.link-card p.link-card__more { color: var(--orange-600); }


/* Aside cards --------------------------------------------------------------
   The rule under a card's heading is tighter than the one under a section
   heading - site.css writes `.aside-card .rule { margin: var(--sp-3) 0 }` - and
   loses it to this file for the same reason the visit panel's does: the
   Separator section above restates the design's bar as
   `hr.wp-block-separator.rule`, which is a class heavier and carries §3's
   margin with it. Restated here at a weight that clears it, in the one
   declaration site.css writes. */

.aside-card hr.wp-block-separator.rule {
	margin: var(--sp-3) 0;
}


/* Clinic contact lines -----------------------------------------------------
   The design writes the sentence above the telephone number as a <span> inside
   .contact-lines, and the editor has no block that emits one, so it arrives as
   a core/paragraph. A <p> brings §3's margin and measure into a flex column of
   contact lines, where a span brought neither; both are taken back off. What
   the line looks like is untouched - .contact-lines and .contact-lines .fine
   reach a paragraph exactly as they reach a span.

   Stated at the design's own weight rather than weightless, because the strip
   is normally inside a card that has already said something about a paragraph:
   .aside-card p is 0-1-1, and anything below it would lose. */

.contact-lines p {
	margin: 0;
	max-width: none;
}


/* Editor canvas ------------------------------------------------------------
   Nothing past this line reaches the front end. [data-block] is the client id
   useBlockProps() puts on every block's own element in the editor and that
   nothing in saved markup carries, so it names the editor's copy of a block
   and only that. It is used rather than .editor-styles-wrapper because sheets
   registered with add_editor_style() are themselves prefixed with that class
   before they are injected into the canvas iframe: a selector naming it would
   come out looking for two nested wrappers and match neither.

   core/image is the one block whose edit() and save() disagree about the
   markup they produce. save() writes the <img> dimensions only when there is a
   dimension to write:

     if ( width !== undefined || height !== undefined ) { … style.height = … }

   edit() runs the same branch unguarded, so an image with neither attribute -
   which is every image in this theme's patterns - is rendered in the editor
   with style="height:auto", an inline declaration no selector can outrank. The
   fill stated above for .hero__aside and .split__media is lost there and only
   there; the <img> keeps the width:100% those rules also give it, so it draws
   itself at the placeholder's own 4:5 ratio and spills out of the box the
   figure is still correctly sized to.

   !important is the only thing that beats an inline style, and what it asserts
   here the design has already decided: the box holds the picture and the
   picture fills it. It also means the editor's own resize handle cannot change
   these two images' height, which is the same decision said a second way.

   The other two fills in this file need nothing. .treatment__media is drawn by
   mjm-clinic/service-tabs, whose <img> is its own markup rather than
   core/image's, and the avatar stack's portraits are already clipped by the
   circle's overflow:hidden. */

.hero__aside .wp-block-image[data-block] img,
.split__media[data-block] img {
	height: 100% !important;
}

/* Condition pages ----------------------------------------------------------
   What the ten What We Help With pages need restated once they are built from
   core blocks rather than the design's markup. site.css carries the design as
   written; these are the differences, and nothing new is decided here.

   The standfirst, the approach block and the FAQ card need nothing. Their
   design markup is <p>, <h2>, <h3> and <div>, which is what core/paragraph,
   core/heading and core/group render, so site.css reaches them element for
   element. */

/* Review strip -------------------------------------------------------------
   The design writes each stat as
     <span class="review-strip__stat"><b>80,000+</b> Patients Treated</span>
   and styles the figure as `.review-strip__stat b`. Two things differ.

   The stat is a <div>, because it holds core/paragraph and a <p> inside a
   <span> is not valid HTML - see patterns/review-strip.php. The class carries
   `display: inline-flex`, so nothing about the layout depends on which element
   it is.

   The line inside it is core/paragraph where the design has bare text, so
   site.css §3 gives it a bottom margin and a measure the design never had. In a
   baseline-aligned flex row the margin is height the design does not have, so
   both are cleared - the same two declarations the reviews score, the trust bar
   and the concern grid already clear.

   The bold is <strong>, which is what core writes for it and what an editor
   gets from the toolbar, so the design's `b` selector is restated for it.
   .review-strip__score is the rating, which cannot share a paragraph with its
   label because a binding replaces the whole of a paragraph's content; it gets
   the same treatment, being the same figure the design sets in <b>. */

.review-strip__stat > p {
	margin: 0;
	max-width: none;
}

.review-strip__stat strong,
.review-strip__score {
	font-family: var(--font-display);
	font-weight: 500;
	font-size: var(--step-1);
	color: var(--navy-800);
}

/* Condition tiles ----------------------------------------------------------
   The design writes a tile as `<li><a>Label</a></li>` and lays the <li> out as
   a flex row whose single item is that anchor. The anchor is one level deeper
   than the design puts it, whichever way the tile is written: a hand written
   tile is a group <li> holding a core/paragraph, because core/list-item holds
   only inline text and cannot carry a class, and a queried tile is core's own
   <li> holding a core/post-title, which renders <p><a> at level 0.

   The paragraph is therefore the flex item in both, and has to behave as the
   anchor did: full width, no measure, no bottom margin. `.tag-grid a` still
   reaches the anchor and still spreads it with its arrow, and `li:has(a)` and
   `:focus-within` both still match, so the hover and focus states are
   unchanged. A .is-pending tile holds no anchor and only needs the same
   paragraph reset.

   `.tag-grid li > p` covers core/post-title as well: the class it carries,
   .wp-block-post-title, is one class deep and this is one class and two
   elements, so the design's reset wins without being restated for it. The same
   goes for the anchor, where core writes `.wp-block-post-title :where(a)` and
   :where() gives that rule no specificity at all. */

.tag-grid li > p {
	margin: 0;
	max-width: none;
	width: 100%;
}

/* The queried grid is core/post-template with .tag-grid written onto it, so the
   list carries both classes and both stylesheets' margins. They are the same
   specificity and disagree about one of them - the design leaves a gap under
   the grid, core zeroes it - which makes the outcome depend on which stylesheet
   loads last, and core's block styles are printed per block as it renders. So
   the design's gap is restated where it outranks both. */

.tag-grid.wp-block-post-template {
	margin-bottom: var(--sp-3);
}

/* A tile that leads with an icon puts the chip beside the paragraph rather than
   inside the anchor. The design nests both in <span class="tag-grid__label">
   within the <a>, and amclinic-ai/icon is a block, so it cannot be written
   inside a core/paragraph's link - see patterns/treatment-uses.php. The chip is
   therefore the <li>'s first flex item and the paragraph its second, which is
   the row that span laid out, so the gap it carried is given to the <li> and
   .tag-grid__label is not ported at all.

   Nothing else about the component changes. `flex: none` on .chip holds the
   chip at its size, the paragraph's `width: 100%` above shrinks by exactly the
   chip and the gap, and `.tag-grid a` still spreads the label and its arrow
   across what is left. A tile with no icon - every tile a queried grid writes -
   has one child and no gap to show. */

.tag-grid li {
	gap: var(--sp-3);
}
