← All changes | assets/css/dock.css +55 -12 1.1.5 → 1.1.12 View file →

		@@ -87,8 +87,19 @@
87	87	color: var( --os-dock-icon-color, rgba( 255, 255, 255, 0.7 ) );
88	88	transition: background-color 0.15s ease, transform 0.15s ease, color 0.15s ease;
89	89	}
90	90
	91	+/*
	92	+ * The tile whose window is in front sits on a lit plate. Declared
	93	+ * before the hover rule at the same specificity so the pointer still
	94	+ * wins while it is over the tile. Falls back to nothing, which is
	95	+ * what every placement drew before the token existed.
	96	+ */
	97	+.os-dock__item--focused .os-dock__item-primary {
	98	+ background-color: var( --os-dock-item-bg-focused, transparent );
	99	+ color: var( --os-dock-icon-color-hover, var( --os-ui-fg-on-accent, #fff ) );
	100	+}
	101	+
91	102	.os-dock__item-primary:hover {
92	103	background-color: var(
93	104	--os-dock-item-bg-hover,
94	105	rgba( 255, 255, 255, 0.15 )
		@@ -113,21 +124,29 @@
113	124	}
114	125
115	126	/* Stacked card hint on hover — a second card peeks from behind the
116	127	icon when the tile has multiple open windows. Only visible on hover so
117		- it never conflicts with focused tiles. */
118		-.os-dock__item--stacked:hover .os-dock__item-primary::before,
119		-.os-dock__item--stacked[data-peek-active] .os-dock__item-primary::before {
	128	+ it never conflicts with focused tiles.
	129	+ *
	130	+ * Painted on the TILE, not on the button it hints at. The hover that
	131	+ * arms this also scales the button, a transform makes a stacking
	132	+ * context, and a `z-index: -1` child of one cannot escape it: the card
	133	+ * landed above the button's own hover plate instead of behind the
	134	+ * tile, reading as a second plate laid over the first. The tile is
	135	+ * transformed by nothing, and a positioned child (the button) paints
	136	+ * over a parent's `::before` at the same level, so the card sits where
	137	+ * its name says without asking for a z-index at all. */
	138	+.os-dock__item--stacked:hover::before,
	139	+.os-dock__item--stacked[ data-peek-active ]::before {
120	140	content: "";
121	141	position: absolute;
122	142	top: -4px;
123	143	inset-inline-start: -4px;
124		- width: 100%;
125		- height: 100%;
126		- border-radius: inherit;
	144	+ width: 40px;
	145	+ height: 40px;
	146	+ border-radius: 10px;
127	147	background: rgba( 255, 255, 255, 0.06 );
128	148	border: 1px solid rgba( 255, 255, 255, 0.10 );
129		- z-index: -1;
130	149	pointer-events: none;
131	150	}
132	151
133	152	/* Dashicon inside dock item. */
		@@ -249,9 +268,9 @@
249	268	padding: 0;
250	269	border: 2px solid var( --os-dock-bg, rgba( 0, 0, 0, 0.4 ) );
251	270	border-radius: 50%;
252	271	background: var( --wp-admin-theme-color, #2271b1 );
253		- color: var( --os-ui-fg-on-accent, #fff );
	272	+ color: var( --os-ui-accent-ink, var( --os-ui-fg-on-accent, #fff ) );
254	273	cursor: pointer;
255	274	transition: background-color 0.15s ease, transform 0.15s ease;
256	275	z-index: 1;
257	276	}
		@@ -1003,17 +1022,26 @@
1003	1022	* general problem. The inline padding is symmetric so the tile cluster
1004	1023	* stays centred in the pill. `min-width: 0` lets the wrapper shrink below its
1005	1024	* content's natural width, so the dock pill's `max-width` is what
1006	1025	* decides when scroll kicks in instead of the content forcing the
1007		- * pill wider. `justify-content: center` keeps tiles balanced inside
1008		- * the pill when content fits; when it overflows, scroll engages and
1009		- * items extend past the visible area.
	1026	+ * pill wider. `justify-content: safe center` keeps tiles balanced inside
	1027	+ * the pill when content fits; when it overflows, the `safe` keyword
	1028	+ * ensures alignment falls back to `start` so `scrollLeft = 0` reveals the
	1029	+ * first item and all items remain scrollable without clipping. Bare
	1030	+ * `center` put the leading tiles at a negative offset, and a scroll
	1031	+ * container clamps `scrollLeft` at 0, so Dashboard and its neighbours
	1032	+ * were clipped with no way to scroll back to them. **The plain `start`
	1033	+ * above it is the fallback, not a leftover** — a browser that cannot
	1034	+ * parse the overflow-alignment keyword drops the `safe center`
	1035	+ * declaration and keeps that one, which left-aligns the tiles rather
	1036	+ * than hiding them. Deleting it restores the bug on those browsers.
1010	1037	*/
1011	1038	.os-dock[ data-os-dock-placement="bottom" ] .os-dock__scroll {
1012	1039	display: flex;
1013	1040	flex-direction: row;
1014	1041	align-items: center;
1015		- justify-content: center;
	1042	+ justify-content: start;
	1043	+ justify-content: safe center;
1016	1044	gap: 6px;
1017	1045	flex: 1 1 auto;
1018	1046	min-width: 0;
1019	1047	padding-top: 4px;
		@@ -1362,8 +1390,23 @@
1362	1390
1363	1391	html.os-dock-vt::view-transition-old( root ),
1364	1392	html.os-dock-vt::view-transition-new( root ) {
1365	1393	animation: none;
	1394	+ }
	1395	+
	1396	+ /*
	1397	+ * The transition layer must not catch the pointer. By default it
	1398	+ * does — the whole page reads as inert until the morph settles —
	1399	+ * and with the root opted out of the snapshot that is worse than
	1400	+ * pointless: the live desktop is right there under a layer that
	1401	+ * swallows every mouseup and every pointerenter for 260ms. The
	1402	+ * behavior module already holds a park back while a button is
	1403	+ * down; this is the other half, so a hover that lands on a tile
	1404	+ * while the rail is still morphing out starts its hover-intent
	1405	+ * timer instead of waiting for the next pointer movement.
	1406	+ */
	1407	+ html.os-dock-vt::view-transition {
	1408	+ pointer-events: none;
1366	1409	}
1367	1410
1368	1411	::view-transition-group( os-dock-os-dock ),
1369	1412	::view-transition-group( os-dock-os-side-dock ) {