/* * content.css — the standard WordPress blocks. * * Sibling of header.css and footer.css, and the documented exception to the * rule in sws-kit/docs/assets.md that visual styles live in the block's own * stylesheet: a core block has no block.json of ours to hang one on, so the * owner has to be declared somewhere, and this is it. Theme blocks are not * styled here — they keep their own sheets and this file steps around them. * * Loaded twice, one file, two contexts: wp_enqueue_style() on the front end * and add_editor_style() in the block editor. * * Two roots, and the split is load-bearing: * * main.site-main > … geometry — column, alignments, * rhythm. Inert in the editor, * where
does not exist and * settings.layout does the job. * :is(.site-main, .editor-styles-wrapper) … appearance — surfaces, type, * overflow. Identical both sides. * * The editor prefixes every selector it is given with :where(.editor-styles- * wrapper) and skips the ones that already mention it, which is why the second * root is written the way it is. * * Specificity, not source order, is what wins here. Measured on this install: * core prints its per-block sheets (wp-block-quote-theme-css and friends) * AFTER every theme sheet, so a rule that merely ties with core loses. The * :is() root supplies the one class that breaks the tie. * * Colours are always var(--wp--preset--color--*) with a literal fallback, so a * context that has not resolved :root still renders something sane. */ /*-------------------------------------------------------------- # Geometry — front end only --------------------------------------------------------------*/ /* * The column, expressed once and reused by the alignments and the float * insets. Both widths come from theme.json rather than from a number written * here, so the editor canvas and the front end read the same source and cannot * drift apart. * * Percentages inside a custom property resolve where the property is used, so * 100% is the width of
for every child that reads them. * * The gutter is expressed as max-width arithmetic and never as padding: the * theme has no global box-sizing (css/base.css says why), and a formula built * from min() and a percentage does not care about the box model. */ main.site-main { --sws-col: min(var(--wp--style--global--content-size, 45rem), 100% - 2 * var(--sws-gutter, 0.75rem)); --sws-col-wide: min(var(--wp--style--global--wide-size, 1116px), 100% - 2 * var(--sws-gutter, 0.75rem)); --sws-col-inset: calc((100% - var(--sws-col)) / 2); } /* * Core blocks get border-box; theme blocks keep the content-box their rails are * built on. Block supports drop padding onto the very element that carries the * width — :where(.wp-block-group.has-background) is core's own example — so at * content-box a group with a background is wider than its column by its own * padding. * * Excluded by namespace, never by alignment: get_block_wrapper_attributes() * stamps wp-block-sws-theme- on every theme block, while alignfull is * absent from any block that declares "align": false, as spacer does. */ main.site-main > :not([class*="wp-block-sws-theme-"]), main.site-main > :not([class*="wp-block-sws-theme-"]) *, main.site-main > :not([class*="wp-block-sws-theme-"]) *::before, main.site-main > :not([class*="wp-block-sws-theme-"]) *::after { box-sizing: border-box; } /* * Floats are excluded alongside wide and full: a floated figure has to keep its * intrinsic width, and core's own constrained rule excludes the same three. * * On archive, search and 404 templates the direct child is
, so the * same rule gives those templates a content column for free. Blocks inside * .entry-content then inherit the article's width rather than being capped a * second time, which would inset them by a second gutter. */ main.site-main > :where(:not(.alignfull):not(.alignwide):not(.alignleft):not(.alignright):not([class*="wp-block-sws-theme-"])) { max-width: var(--sws-col); margin-inline: auto; } main.site-main > .alignwide { max-width: var(--sws-col-wide); margin-inline: auto; } main.site-main > .alignfull:not([class*="wp-block-sws-theme-"]) { max-width: none; margin-inline: 0; } /* * Top-level floats are a case core never has to solve. In a block theme an * .alignleft sits inside .is-layout-constrained and floats against the column; * here there is no such wrapper, so it would float against the viewport while * the paragraph beside it stays in the column — text wrapping around something * parked far to its left. The inset pins the float to the column edge instead. */ main.site-main > .alignleft { float: left; max-width: calc(var(--sws-col) / 2); margin-block: 0 1.5rem; margin-inline: var(--sws-col-inset) 2em; } main.site-main > .alignright { float: right; max-width: calc(var(--sws-col) / 2); margin-block: 0 1.5rem; margin-inline: 2em var(--sws-col-inset); } main.site-main > .aligncenter { margin-inline: auto; } /* Nothing full-bleed may start beside a leftover float. */ main.site-main > .alignfull, main.site-main > .alignwide, main.site-main > [class*="wp-block-sws-theme-"] { clear: both; } /* * A float and a readable line cannot share a row on a phone. This is the one * behaviour that is not intrinsic — no min() or clamp() cancels a float — so it * takes a media query, and the threshold is one core declares itself (600px, * the busiest in this release) rather than a number invented here. */ @media (max-width: 600px) { main.site-main > .alignleft, main.site-main > .alignright { float: none; max-width: var(--sws-col); margin-inline: auto; } } /* * Rhythm, from the single number in theme.json. * * Owl form is required: a margin-block-start on every child would collapse out * of
, which has neither padding nor border, and push the whole content * area down instead of separating the blocks. * * The :not() on the second element is this project's own condition. Theme * sections are designed to sit flush — the home page runs hero straight into * the section below it — so an unqualified `* + *` would insert a gap at every * joint and move every production page. This way: theme→theme 0, core→theme 0 * (the section brings its own padding-block), theme→core and core→core get the * gap. * * The variable is --wp--style--block-gap. The --wp--style--global--block-gap * form quoted in the kit docs is not emitted by WordPress 7.1 — verified on * this install — and using it would silently pin the rhythm to the literal. */ main.site-main > :not([class*="wp-block-sws-theme-"]) { margin-block-end: 0; } main.site-main > * + :not([class*="wp-block-sws-theme-"]) { margin-block-start: var(--wp--style--block-gap, 1.5rem); } /* * A leading

or

would otherwise collapse its UA margin out of

. * * Namespaced like the rest: a theme section as the first child sets its own * leading space and this file has no business zeroing it. With this exclusion * the only rule in the whole stylesheet that still reaches a theme block is the * clear above, which is deliberate — a float must not run into a section. */ main.site-main > :first-child:not([class*="wp-block-sws-theme-"]) { margin-block-start: 0; } /*-------------------------------------------------------------- # Appearance — front end and editor canvas --------------------------------------------------------------*/ /* * Every rule below that targets a bare element rather than a .wp-block-* class * carries :not([class*="wp-block-sws-theme-"] *), which keeps it out of the * theme blocks' own markup. * * This is not belt and braces. The contact form is Contact Form 7 inside a * theme block, so its fields are plain and