/* Editorial pages run their bands on the WIDE rail, not the reading measure.

   THE PROBLEM. theme.json sets contentSize 840 / wideSize 1440. A full-bleed band (an
   alignfull group or cover) lays its children out with `constrained`, so anything inside it
   that is not explicitly aligned lands at 840 — and at 1600px that leaves a form, a Media &
   Text or a columns row stranded in the middle of the screen with ~380px of dead space either
   side. The theme's own patterns dodge this by setting `align:wide` on their inner content
   (section-service-band, section-cta-band and the rest all do it). The hand-built pages were
   not written that way, and about-us proves the inconsistency is accidental rather than
   intended: one columns row sits at 1440 because somebody set it wide, while the Media & Text
   above it sits at 840 because nobody did.

   THE LEVER. WP's layout engine constrains those children with ONE generic rule:

     .is-layout-constrained > :where(:not(.alignleft):not(.alignright):not(.alignfull))
       { max-width: var(--wp--style--global--content-size) }

   It reads a CUSTOM PROPERTY, not a baked value — so redefining that property inside page
   content moves every band child to the wide rail at once, without touching the block markup,
   without a per-page edit, and without the client having to remember to set "Wide width" on
   everything they add. Explicit alignments still win exactly as before: `alignwide` reads
   wide-size (unchanged), `alignfull` and the left/right floats are excluded by the selector.

   WHY IT IS SCOPED TO A CLASS ON <main> AND NOT TO `body.page`. The front page and the
   products index are Pages too, and both carry `page-template-default` on the body, so a
   body-class rule would silently restyle two purpose-built templates that already look right.
   `templates/page.html` is used ONLY when no more specific template matches — front-page.html
   and page-our-products.html take precedence for those two — so a class printed by that
   template hits precisely the editorial pages this is meant for and nothing else.

   THE EDITOR AGREES. This file is enqueued through `enqueue_block_assets` (front end AND the
   editor canvas) and the class lives in the template markup, so the Site Editor shows the same
   widths the front end ships. That is the whole reason this is a custom-property override
   rather than a stylesheet fighting WP's layout rules with heavier selectors.

   PROSE KEEPS ITS MEASURE, and that exception is the point of the second rule. Moving the
   container width moves the reading measure with it, and a paragraph does not want to be 1440px
   wide: at 16px that is around 190 characters per line where comfortable reading is 45–90.
   It is not hypothetical — /privacy-policy/ has twelve such paragraphs and /service-model/
   thirteen, and without the exception both became a wall of full-width text. So the STRUCTURAL
   blocks (groups, Media & Text, columns, covers, forms, images) take the wide rail and the
   TEXT-LEVEL blocks sitting directly in a band stay on the measure.

   Headings and lists are exempted alongside paragraphs on purpose. Exempting `p` alone would
   leave a heading at 1440 above a paragraph at 840 — both centred, so their left edges would
   sit 300px apart and the copy would read as misaligned. Prose moves as one block or not at
   all. It also preserves the relationship about-us already had, where a section heading sits on
   the measure above a columns row on the wide rail.

   An editor can still overrule any of it per block: `alignwide` and `alignfull` are excluded
   from the exception, so setting Wide width on a paragraph in the sidebar does what it says. */

.pwr-page-wide :where(.is-layout-constrained) {
	--wp--style--global--content-size: var(--wp--style--global--wide-size, 1440px);
}

/* The measure, captured from theme.json rather than restated, so the two cannot drift. It is
   read on :root — NOT inside .pwr-page-wide — because the rule above redefines that property on
   every constrained container beneath main, and capturing it in there would just hand back the
   overridden 1440. */
:root {
	--pwr-measure: var(--wp--style--global--content-size, 840px);
}

/* `.is-layout-constrained` is a real class here, not :where(), so this lands at 0,2,0 and beats
   WP's own 0,1,0 layout rule regardless of which stylesheet the browser prints last — an
   equal-specificity tie decided by source order is exactly the kind of thing that works locally
   and breaks when the CSS is concatenated differently. The :not()s keep an explicitly aligned
   block doing what the editor asked. */
.pwr-page-wide .is-layout-constrained > :where(p, h1, h2, h3, h4, h5, h6, ul, ol, dl, blockquote, pre, figcaption):not(.alignwide):not(.alignfull):not(.alignleft):not(.alignright) {
	max-width: var(--pwr-measure);
}