| @@ -511,20 +511,54 @@ | ||
| 511 | 511 | background: transparent; |
| 512 | 512 | } |
| 513 | 513 | |
| 514 | 514 | /* |
| 515 | - * `boot-layout__surfaces` is the white card the React app draws its | |
| 516 | - * content onto. In classic admin it sits on the dark #wpwrap with | |
| 515 | + * The surfaces wrapper is the white card the React app draws its | |
| 516 | + * content onto. In classic admin it sits on the dark layout with | |
| 517 | 517 | * rounded corners and a margin that makes it read as a "card." Inside |
| 518 | - * a desktop window the surface IS the content — rounded corners and | |
| 519 | - * side margins leave ugly bleed at the edges. Collapse it to a plain | |
| 518 | + * a desktop window the surface IS the content, so that frame is just | |
| 519 | + * bleed at the right and bottom edges. Collapse it to a plain | |
| 520 | 520 | * edge-to-edge surface. |
| 521 | + * | |
| 522 | + * Core builds these class names with CSS modules, so only the | |
| 523 | + * `__<local-name>` suffix is stable; the hash in front of it changes | |
| 524 | + * with every Core build. Match on the suffix, scoped to the boot | |
| 525 | + * container. The bare `boot-layout__*` names are the pre-CSS-modules | |
| 526 | + * spelling, kept for Core builds that still ship it. | |
| 527 | + * | |
| 528 | + * The container is not a tight enough scope on its own. The page a | |
| 529 | + * boot screen routes to mounts INSIDE the layout, and a plugin page | |
| 530 | + * built with CSS modules gives its own elements the same | |
| 531 | + * `<hash>__<name>` shape: Jetpack's Stats v2 dashboard lays its | |
| 532 | + * widgets out in a `…__layout` grid, and the `min-height: 100vh` meant | |
| 533 | + * for Core's layout element stretched that grid to the window and | |
| 534 | + * spread the dashboard's rows across it, with the widgets pushed | |
| 535 | + * out of sight. Everything a page renders lives inside admin-ui's | |
| 536 | + * navigable region, so exclude that subtree: these rules only ever | |
| 537 | + * touch Core's own frame around the page, never the page. | |
| 521 | 538 | */ |
| 539 | +.os-chromeless .boot-layout-container [class*='__surfaces']:not( .admin-ui-navigable-region * ), | |
| 540 | +.os-chromeless .boot-layout-container [class*='__stage']:not( .admin-ui-navigable-region * ), | |
| 541 | +.os-chromeless .boot-layout-container [class*='__canvas']:not( .admin-ui-navigable-region * ), | |
| 522 | 542 | .os-chromeless .boot-layout__surfaces, |
| 523 | 543 | .os-chromeless .boot-layout__stage, |
| 524 | 544 | .os-chromeless .boot-layout__canvas { |
| 525 | 545 | border-radius: 0 !important; |
| 526 | 546 | margin: 0 !important; |
| 547 | +} | |
| 548 | + | |
| 549 | +/* | |
| 550 | + * The layout element is absolutely positioned inside a zero-height | |
| 551 | + * `#wpbody`, so `top: 0; bottom: 0` resolve to nothing and its | |
| 552 | + * `min-height: calc( 100vh - <admin bar> )` is what it actually gets. | |
| 553 | + * A chromeless iframe has no admin bar, so that reservation shows up | |
| 554 | + * as a dark band along the bottom of the window. Take the full | |
| 555 | + * viewport back. Same navigable-region guard as above: the page's | |
| 556 | + * own `…__layout` elements keep their height. | |
| 557 | + */ | |
| 558 | +.os-chromeless .boot-layout-container [class*='__layout']:not( .admin-ui-navigable-region * ), | |
| 559 | +.os-chromeless .boot-layout { | |
| 560 | + min-height: 100vh !important; | |
| 527 | 561 | } |
| 528 | 562 | |
| 529 | 563 | /* |
| 530 | 564 | * The boot screens render their own H1 (`.boot-navigation-screen__title`, |
