| @@ -124,21 +124,29 @@ | ||
| 124 | 124 | } |
| 125 | 125 | |
| 126 | 126 | /* Stacked card hint on hover — a second card peeks from behind the |
| 127 | 127 | icon when the tile has multiple open windows. Only visible on hover so |
| 128 | - it never conflicts with focused tiles. */ | |
| 129 | -.os-dock__item--stacked:hover .os-dock__item-primary::before, | |
| 130 | -.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 { | |
| 131 | 140 | content: ""; |
| 132 | 141 | position: absolute; |
| 133 | 142 | top: -4px; |
| 134 | 143 | inset-inline-start: -4px; |
| 135 | - width: 100%; | |
| 136 | - height: 100%; | |
| 137 | - border-radius: inherit; | |
| 144 | + width: 40px; | |
| 145 | + height: 40px; | |
| 146 | + border-radius: 10px; | |
| 138 | 147 | background: rgba( 255, 255, 255, 0.06 ); |
| 139 | 148 | border: 1px solid rgba( 255, 255, 255, 0.10 ); |
| 140 | - z-index: -1; | |
| 141 | 149 | pointer-events: none; |
| 142 | 150 | } |
| 143 | 151 | |
| 144 | 152 | /* Dashicon inside dock item. */ |
| @@ -1014,17 +1022,26 @@ | ||
| 1014 | 1022 | * general problem. The inline padding is symmetric so the tile cluster |
| 1015 | 1023 | * stays centred in the pill. `min-width: 0` lets the wrapper shrink below its |
| 1016 | 1024 | * content's natural width, so the dock pill's `max-width` is what |
| 1017 | 1025 | * decides when scroll kicks in instead of the content forcing the |
| 1018 | - * pill wider. `justify-content: center` keeps tiles balanced inside | |
| 1019 | - * the pill when content fits; when it overflows, scroll engages and | |
| 1020 | - * 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. | |
| 1021 | 1037 | */ |
| 1022 | 1038 | .os-dock[ data-os-dock-placement="bottom" ] .os-dock__scroll { |
| 1023 | 1039 | display: flex; |
| 1024 | 1040 | flex-direction: row; |
| 1025 | 1041 | align-items: center; |
| 1026 | - justify-content: center; | |
| 1042 | + justify-content: start; | |
| 1043 | + justify-content: safe center; | |
| 1027 | 1044 | gap: 6px; |
| 1028 | 1045 | flex: 1 1 auto; |
| 1029 | 1046 | min-width: 0; |
| 1030 | 1047 | padding-top: 4px; |
