/* * The panel measure — the one width that is neither prose nor the whole page. * * WHAT A PANEL IS. Two pages on this site are not documents. The account is a * dashboard of stacked cards and the checkout is a two-column form beside a * cart, and both of them need a measure between theme.json's 696px reading * column and its 1420px wide-size. 696px gives EDD's 2fr/1fr checkout grid two * 340px columns, neither of which works, and it puts the account's section nav * on top of the section it is navigating. 1420px is the browse grid's width and * makes a five-field form look abandoned in the middle of it. * * WHY THE NUMBER IS NOT IN THIS FILE. It is `settings.custom.layout.panel` in * theme.json, which WordPress publishes as `--wp--custom--layout--panel`, and * that is the only place 1180px is written down. It used to be written down * four times: as `contentSize` on the account dashboard group, as `contentSize` * twice in templates/page-checkout.html, and as a `--f32-page-measure` custom * property duplicated verbatim into two stylesheets so that a template part * which could not be passed a width could at least be handed a class. The * checkout's three copies said 1100px and the account's said 1180px, which is * not a design decision anybody made — it is what happens when the same idea is * typed out twice a month apart. They are now one number, and the checkout * moved to it. * * The block header reads the same property (`is-width-panel` in the Page Header * block's stylesheet), so the title band and the content beneath it cannot * disagree about where the page ends. * * WHY TWO CLASSES. Core's constrained layout writes its cap as * `.wp-container-xxx > :where(:not(.alignleft):not(.alignright):not(.alignfull))`, * which scores one class — the `:where()` contributes nothing and only the * generated container class counts. A single-class selector here would tie, and * core prints its block-support styles inline in `` after the theme's * enqueued stylesheets, so a tie is a loss. `.wp-block-group` is not padding: * it is what the element already is, so the selector buys its weight by being * more honest rather than by doubling a class. No `!important`; see the same * argument, arrived at the same way, in * assets/blocks/sparklestock-docs-index.css. * * The rule caps the CHILDREN and not the group, which is what `constrained` * layout does and therefore what the group's own `alignwide`/`alignfull` * children keep expecting. Leave `layout: constrained` on the group: it is * still what centres the children and what makes `align` mean anything inside. * * WHERE THE CLASS GOES: on `
` on both pages, and additionally on the * account dashboard group. `
` has to carry it because the page's H1 is * now the first block INSIDE `
` - a constrained parent caps every child, * so a `width: panel` header inside a 696px `
` would have been a 696px * header over a 1180px dashboard, with the title starting 242px to the right of * everything it titles. That is the exact defect the two deleted stylesheet * patches existed to fix, arriving from the other direction. The dashboard * needs the class as well because it is constrained in its own right, and * without a `contentSize` its children would fall back to the global 696px. * * Widening `
` on the account page widens everything in it, including the * login form a logged-out visitor gets instead of the dashboard. That one is * put back to the reading measure in assets/css/account.css, next to the * greeting rule that is the same block's other half. * * Loaded on the account and the checkout only, per f32_enqueue_panel_styles(). * * @package F32 */ .wp-block-group.f32-panel > * { max-width: var(--wp--custom--layout--panel); }