/**
 * Desktop Mode — Window styles (entry point).
 *
 * The window stylesheet used to be 1,500 lines of chrome, states,
 * overview, and OS Settings mixed together. It now imports four
 * focused files so each concern lives on its own:
 *
 *   - window-chrome.css    — base window, title bar, icon, title,
 *                            controls, focused/unfocused variants,
 *                            menu panel, screen-meta buttons, tabs,
 *                            window body, primary iframe, native body.
 *   - window-states.css    — resize handle, drag/resize overlays,
 *                            maximized, fullscreen, opening animation,
 *                            minimized, closing, reduced-motion, RTL.
 *   - window-overview.css  — zoom-out overview grid + floating labels
 *                            + per-desktop top bar + dock-collapse.
 *   - os-settings.css      — the OS Settings native panel (wallpaper
 *                            picker, accent, dock size, uploader,
 *                            Media Library grid). Will move to its own
 *                            enqueue once it stops being coupled to the
 *                            window chrome loading order.
 *
 * The `desktop-mode-windows` script handle registers this file as its
 * CSS source, so all four sub-sheets ship with a single handle — no
 * changes required to `includes/assets.php` or `includes/render.php`.
 *
 * @since 6.9.0
 */

@import url( "window-chrome.css" );
@import url( "window-states.css" );
@import url( "window-overview.css" );
@import url( "os-settings.css" );
@import url( "effects.css" );

/*
 * Cross-window drag drop highlight — kept INLINE in this file
 * (not in any of the @import'd sub-sheets) so the mtime-stamped
 * `?ver=…` on `windows.css` reliably invalidates the rules along
 * with the parent stylesheet. Sub-sheets are fetched without an
 * explicit version query and can be served from the browser's
 * heuristic cache even after a hard reload.
 *
 * The cross-window pointer routing itself is driven from
 * JavaScript by `src/drag/iframe-drop-targets.ts` — on drag
 * START with a shortcut payload, every iframe element gets an
 * inline `style.pointerEvents = 'none'` so pointer events fall
 * through to the iframe's parent (`.desktop-mode-window__body`),
 * which is registered as the drop target. No CSS rule is needed
 * to make the routing work — this stylesheet only paints the
 * visual feedback for whichever window is currently the active
 * drop target.
 */
.desktop-mode-window__body[data-desktop-mode-iframe-drop-active] {
	outline: 2px dashed var(--desktop-mode-accent, #2271b1);
	outline-offset: -6px;
	background: color-mix(in srgb, var(--desktop-mode-accent, #2271b1) 8%, transparent);
}

/*
 * Title-bar meta-button dashicon centring — same cache-busting
 * reason: Dashicons inherits `display: inline-block` from core
 * which positions the glyph via text-layout, and the font's
 * baseline isn't the geometric centre of its em-box, so the
 * visible `?` drifts off-centre inside the 28×28 button.
 * Re-flexing the dashicon span re-anchors the glyph regardless
 * of the font's intrinsic metrics. Lives in `windows.css`
 * rather than `window-chrome.css` so the parent stylesheet's
 * mtime stamp invalidates it on every edit — sub-sheet @imports
 * are not version-queried and can be served from cache.
 */
.desktop-mode-window__meta-btn .dashicons {
	display: inline-flex;
	align-items: center;
	justify-content: center;
	line-height: 1;
	/* Reset any inherited `top` / `left` offset that bleeds in
	 * from wp-admin or third-party stylesheets that style icons
	 * by their glyph class (e.g. `.dashicons-editor-help` with
	 * `top: 5px; left: 6px;` — leftover from contextual-help
	 * styling that doesn't belong in our title bar). Without this
	 * the glyph drifts off-centre inside the button. */
	top: 0 !important;
	left: 0 !important;
}