PluginProbe
OpenStation: Desktop Windows, Dock & Virtual Desktops for WP Admin / 1.1.11
OpenStation: Desktop Windows, Dock & Virtual Desktops for WP Admin v1.1.11
1.1.11 1.1.10 1.1.9 1.1.8 1.1.7 1.1.6 1.1.5 1.1.4 1.1.3 1.1.2 1.1.1 1.1.0 1.0.1 1.0.0 0.9.8 0.9.7 0.9.6 0.9.4 0.9.5 0.9.3 0.9.2 0.9.1 0.9.0 0.8.9 0.8.8 All 35 releases
← All changes | assets/css/chromeless.css +134 -4 1.1.6 → 1.1.11 View file →
@@ -368,8 +368,85 @@
368 368 width: auto;
369 369 }
370 370
371 371 /* ---------------------------------------------------------------
372 + * Metabox screens — the one-column breakpoint is 160px too early.
373 + *
374 + * Core collapses every `#poststuff` two-column screen (the classic
375 + * post editor, any CPT editor, a WooCommerce order) to one column
376 + * at `max-width: 850px`. That number is a VIEWPORT width, and it is
377 + * sized for a viewport that still has the 160px admin menu in it:
378 + * at 851px core leaves roughly 650px of usable content — less than
379 + * the 763px the two columns actually need (`#post-body-content`'s
380 + * 463px floor plus the 300px sidebar reservation), which is why
381 + * core's own two-column layout scrolls sideways just above the
382 + * breakpoint.
383 + *
384 + * A chromeless iframe hides the admin menu, so the same 851px gives
385 + * 835px of content — comfortably two columns — and core stacks it
386 + * anyway. The sidebar then lands BELOW the editor, and since the
387 + * classic editor grows to fit its text, a long post pushes Publish,
388 + * Categories, Tags and Featured image thousands of pixels down the
389 + * page. The user's word for that is "vanished".
390 + *
391 + * Same shape as the WooCommerce header fix at the top of this file:
392 + * the page reserved space for a sidebar we removed, so reclaim the
393 + * reservation. Two columns stay until the content really stops
394 + * fitting: 763px of content, plus the 16px `#wpbody-content` gutter
395 + * above, plus up to 17px for a classic vertical scrollbar — which a
396 + * media query does NOT subtract from the width it matches on, the
397 + * same reason `100vw` overflows a scrolling page. That is 796px.
398 + * Below it, core's one-column layout is correct and stays.
399 + *
400 + * The reservation is written flow-relative rather than as core's
401 + * `margin-right` / `float: right`, because core ships the mirrored
402 + * values in a separate `edit-rtl.css` and this file has no RTL
403 + * build — one logical declaration lands on the correct side in
404 + * both directions. `float: right` stays ahead of `float:
405 + * inline-end` as the fallback.
406 + *
407 + * Attachments keep core's own, wider, 1200px breakpoint: the media
408 + * editor's sidebar carries the whole attachment form and needs the
409 + * room. `.post-type-attachment` is excluded rather than re-stacked
410 + * so that rule keeps working untouched.
411 + *
412 + * Verifying: open a post with a few thousand words in a window
413 + * ~800px wide. Publish/Categories/Tags sit beside the editor, not
414 + * under it, and the page has no horizontal scrollbar.
415 + * --------------------------------------------------------------- */
416 +@media only screen and ( min-width: 796px ) and ( max-width: 850px ) {
417 + .os-chromeless:not( .post-type-attachment ) #wpbody-content #poststuff #post-body.columns-2 {
418 + margin-inline-end: 300px;
419 + }
420 +
421 + .os-chromeless:not( .post-type-attachment ) #wpbody-content #post-body.columns-2 #postbox-container-1 {
422 + float: right;
423 + float: inline-end;
424 + margin-inline-end: -300px;
425 + width: 280px;
426 + }
427 +
428 + .os-chromeless:not( .post-type-attachment ) #poststuff #post-body.columns-2 #side-sortables {
429 + min-height: 250px;
430 + width: 280px;
431 + }
432 +
433 + /*
434 + * Core hides the Layout radios with the two-column layout. They
435 + * are the way back to one column, so they come back with it.
436 + *
437 + * `edit.css` is part of the `wp-admin` bundle and loads on every
438 + * screen, so that hide reaches the Dashboard's own 1-4 column
439 + * radios too. Only un-hide them where this block actually gave a
440 + * layout back.
441 + */
442 + .os-chromeless:not( .post-type-attachment ):has( #post-body.columns-2 ) .screen-layout,
443 + .os-chromeless:not( .post-type-attachment ):has( #post-body.columns-2 ) .columns-prefs {
444 + display: block;
445 + }
446 +}
447 +
448 +/* ---------------------------------------------------------------
372 449 * Block Editor — hide Gutenberg chrome that would break the window.
373 450 *
374 451 * The fullscreen-mode close button (the "W" logo top-left of the editor)
375 452 * is an <a href="/wp-admin/edit.php"> that navigates the iframe to a
@@ -434,15 +511,35 @@
434 511 background: transparent;
435 512 }
436 513
437 514 /*
438 - * `boot-layout__surfaces` is the white card the React app draws its
439 - * 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
440 517 * rounded corners and a margin that makes it read as a "card." Inside
441 - * a desktop window the surface IS the content — rounded corners and
442 - * 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
443 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.
444 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 * ),
445 542 .os-chromeless .boot-layout__surfaces,
446 543 .os-chromeless .boot-layout__stage,
447 544 .os-chromeless .boot-layout__canvas {
448 545 border-radius: 0 !important;
@@ -449,8 +546,22 @@
449 546 margin: 0 !important;
450 547 }
451 548
452 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;
561 +}
562 +
563 +/*
453 564 * The boot screens render their own H1 (`.boot-navigation-screen__title`,
454 565 * e.g., "Fonts") at the top of the surface. The desktop window already
455 566 * shows the page title in its title bar, so the in-page title is
456 567 * redundant. Visually hide it but keep it in the DOM for screen readers
@@ -543,8 +654,27 @@
543 654 * --------------------------------------------------------------- */
544 655 .os-chromeless .commands-command-menu__container,
545 656 .os-chromeless .commands-command-menu {
546 657 display: none !important;
658 +}
659 +
660 +/* ---------------------------------------------------------------
661 + * A file drag over a native upload box.
662 + *
663 + * The chromeless bridge hands an OS-file drop to Core's own
664 + * `<input type="file">` when it lands on one, or anywhere on the
665 + * `form.wp-upload-form` box around it (Upload Plugin, Upload
666 + * Theme), and stamps `data-os-file-drop-active` on that box while
667 + * the drag is over it. Outside the shell the box gives no sign it
668 + * will take a drop; inside, the shell used to take the file
669 + * instead, so people learned it would not. Say so while it can.
670 + *
671 + * Core's own admin colour, read the way common.css reads it, not
672 + * the station's: this is a wp-admin control on a wp-admin page.
673 + * --------------------------------------------------------------- */
674 +.os-chromeless [data-os-file-drop-active] {
675 + outline: 2px dashed var( --wp-admin-theme-color, #3858e9 );
676 + outline-offset: -2px;
547 677 }
548 678
549 679 /* ---------------------------------------------------------------
550 680 * Appearance → Themes workspace