/* ============================================================ * STM Telerik Popups — GLOBAL (non-scoped) overrides * ============================================================ * Telerik renders calendar / dropdown-list / autocomplete popups * by appending a `.k-animation-container` to , OUTSIDE the * scoped Blazor component subtree. Scoped `::deep .k-…` rules in the * components' `.razor.css` compile to `[b-xxxx] .k-…` and therefore * can NEVER match a body-appended popup — they are dead. * * These rules live here as plain GLOBAL selectors so they actually * match the popup layer. They only refine popups that already * receive baseline brand colours + font from kendo-bridge.css. * * LOAD ORDER (must hold for the cascade to win): * 1. kendo-theme.css (Telerik base theme) * 2. kendo-bridge.css (maps --kendo-* → --stm-*) * 3. stm-telerik-popups.css (THIS FILE — component-specific refinements) * * Token-only: every value references a real --stm-datePicker-* / * --stm-dropdown-* token (verified present in dist/generated/stm-light.css). * ============================================================ */ /* ── DatePicker calendar popup (datePicker.json) ── */ /* Rounded corners + elevation live on the popup container. Telerik injects its own component styles at RUNTIME (after this ), so a same-specificity rule loses the source-order tie; we use the full 3-class match plus !important to win deterministically. overflow:hidden clips the inner calendar to the rounded corner. (Verified via Playwright against the rendered popup — see scripts/verify-telerik-popups.mjs.) */ .k-popup.k-datepicker-popup.k-calendar-container, .k-animation-container .k-popup.k-calendar-container { border-radius: var(--stm-datePicker-calendarRadius) !important; box-shadow: var(--stm-datePicker-calendarElevation); overflow: hidden; } .k-calendar-container, .k-calendar { background-color: var(--stm-datePicker-calendarContainer); padding: var(--stm-datePicker-calendarPadding); } .k-calendar .k-calendar-header, .k-calendar .k-calendar-nav { background-color: var(--stm-datePicker-headerContainer); color: var(--stm-datePicker-headerText); } .k-calendar .k-calendar-title, .k-calendar .k-calendar-nav-today { color: var(--stm-datePicker-headerText); /* TOK-66: the calendar is an ALL-TEXT component and had zero typography slots, so every character in it rendered at whatever the vendor chose. */ font-family: var(--stm-datePicker-headerTypography-font-family); font-size: var(--stm-datePicker-headerTypography-font-size); font-weight: var(--stm-datePicker-headerTypography-font-weight); line-height: var(--stm-datePicker-headerTypography-line-height); } .k-calendar .k-calendar-nav-prev, .k-calendar .k-calendar-nav-next, .k-calendar .k-nav-fast { color: var(--stm-datePicker-headerNavIcon); } .k-calendar .k-calendar-weekdays th, .k-calendar .k-month-header th { color: var(--stm-datePicker-weekdayText); font-family: var(--stm-datePicker-weekdayTypography-font-family); font-size: var(--stm-datePicker-weekdayTypography-font-size); font-weight: var(--stm-datePicker-weekdayTypography-font-weight); line-height: var(--stm-datePicker-weekdayTypography-line-height); } .k-calendar .k-calendar-td .k-link, .k-calendar .k-calendar-cell .k-link { width: var(--stm-datePicker-dayCellSize); height: var(--stm-datePicker-dayCellSize); border-radius: var(--stm-datePicker-dayCellRadius); color: var(--stm-datePicker-dayCellText); font-family: var(--stm-datePicker-dayCellTypography-font-family); font-size: var(--stm-datePicker-dayCellTypography-font-size); font-weight: var(--stm-datePicker-dayCellTypography-font-weight); line-height: var(--stm-datePicker-dayCellTypography-line-height); /* TOK-66: neither leg transitioned at all, so selection snapped. */ transition: background-color var(--stm-datePicker-motionDuration) var(--stm-datePicker-motionEasing), color var(--stm-datePicker-motionDuration) var(--stm-datePicker-motionEasing); } /* TOK-66: neither leg styled day-cell FOCUS, so the calendar's keyboard affordance was whatever the vendor drew — different per framework, and not the brand's. Inset offset: a day cell is packed against its neighbours. */ .k-calendar .k-calendar-td .k-link:focus-visible, .k-calendar .k-calendar-cell .k-link:focus-visible { outline: var(--stm-datePicker-dayCellFocusRingWidth) solid var(--stm-datePicker-dayCellFocusRing); outline-offset: var(--stm-datePicker-dayCellFocusRingOffset); } /* TOK-66: a day outside min/max was left entirely to the vendor, so an out-of-range date looked different in React and Blazor. */ .k-calendar .k-disabled .k-link, .k-calendar .k-calendar-td.k-disabled .k-link { color: var(--stm-datePicker-dayCellDisabledText); background-color: var(--stm-datePicker-dayCellDisabledBg); } .k-calendar .k-other-month .k-link { color: var(--stm-datePicker-dayCellTextOutsideMonth); } .k-calendar .k-calendar-td .k-link:hover, .k-calendar .k-calendar-cell .k-link:hover { background-color: var(--stm-datePicker-dayCellHoverBg); } .k-calendar .k-selected .k-link, .k-calendar .k-state-selected .k-link { background-color: var(--stm-datePicker-dayCellSelectedBg); color: var(--stm-datePicker-dayCellSelectedText); } /* TOK-66: pinning the selected day's hover back to its own fill was expressed as a selector trick rather than a value, so a brand wanting a hover cue on the selected day had nowhere to put it. */ .k-calendar .k-selected .k-link:hover, .k-calendar .k-state-selected .k-link:hover { background-color: var(--stm-datePicker-dayCellSelectedHoverBg); } /* TOK-66: today was a BORDER and nothing else, and its width had three sources — this sheet used input.borderWidth, the (now deleted) scoped calendar copy used core.border.width.thin, and React hardcoded a bare 1px. */ .k-calendar .k-today .k-link { border: var(--stm-datePicker-dayCellTodayBorderWidth) solid var(--stm-datePicker-dayCellTodayBorder); color: var(--stm-datePicker-dayCellTodayText); } .k-calendar .k-range-mid .k-link { background-color: var(--stm-datePicker-rangeFill); } .k-calendar .k-range-start .k-link, .k-calendar .k-range-end .k-link { background-color: var(--stm-datePicker-rangeEndpointFill); color: var(--stm-datePicker-dayCellSelectedText); } /* ── DropDown / AutoComplete popup (dropdown.json) ── */ .k-popup, .k-animation-container .k-list-container { background-color: var(--stm-dropdown-popupContainer); border-radius: var(--stm-dropdown-popupRadius); /* TOK-127: a bare 1px stood here while the colour beside it was already a slot — the same shape TOK-83 found on the modal hairline. Value-preserving (thin = 1px). */ border: var(--stm-dropdown-popupBorderWidth) solid var(--stm-dropdown-popupBorder); box-shadow: var(--stm-dropdown-popupElevation); max-height: var(--stm-dropdown-popupMaxHeight); } /* TOK-127 — the option list's own vertical padding. * * Two things here are deliberate and neither is obvious from reading the token. * * ① The selector repeats `.k-list-container.k-popup`. Kendo pads this popup on all * four sides from exactly that two-class rule (0,2,0); the block above matches a * plain `.k-popup` (0,1,0) and would silently lose. Matching the same two classes * ties, and THIS SHEET LOADS AFTER kendo's all.css, so the tie goes to us — no * !important needed, unlike the calendar rules above, whose competitor is injected * at runtime. * ② It SHRINKS: Kendo ships 8px, the DS says 4px — the value React's MuiMenu paper has * carried since TOK-70 (render-verified 2026-08-20, both legs at 1440×1024). The * inline half of Kendo's inset is zeroed below under TOK-140. */ .k-list-container.k-popup { padding-block: var(--stm-dropdown-popupPaddingY); /* TOK-140: and NO inline padding. Kendo insets the list 8px on each side; React's MuiMenu paper insets it none, letting the option's own paddingX be the whole indent and its hover fill span the popup edge to edge. Leaving Kendo's inset in place would have rendered the DS's 12px option indent as 20px — the reason the option-padding fix below is not sufficient on its own. There is no `dropdown.popupPaddingX` slot because on this design there is no such distance: 0 is not a value we are declining to tokenise, it is the absence of a box. */ padding-inline: 0; } /* TOK-140 — the option's own padding, at a specificity that actually reaches the render. * * The previous single-class rule bound `optionPaddingY/X` and LOST: Kendo pads from * `.k-list.k-list-md .k-list-item` (0,3,0) against its (0,1,0), so Blazor drew Kendo's * 4px/8px while React drew the DS's 8px/12px, and every guard stayed green — a token * bound, correct, and dead. Matching Kendo's own two-class shape ties the specificity * and this sheet loads later, so the tie is ours. * * `.k-list-optionlabel` rides along deliberately: it is the DefaultText row ("Select an * option"), a sibling of the options that Kendo pads from the same rule. Pad the items * and not the label and the first row of every dropdown sits 4px shallower than the * rest — which is worse than the divergence this row exists to close. */ .k-list.k-list-md .k-list-item, .k-list.k-list-md .k-list-optionlabel, .k-list .k-list-item, .k-list .k-list-optionlabel, .k-list .k-item { padding: var(--stm-dropdown-optionPaddingY) var(--stm-dropdown-optionPaddingX); } .k-list-item, .k-list .k-item, .k-list .k-list-optionlabel { font-family: var(--stm-dropdown-optionTypography-font-family); font-size: var(--stm-dropdown-optionTypography-font-size); font-weight: var(--stm-dropdown-optionTypography-font-weight); line-height: var(--stm-dropdown-optionTypography-line-height); /* TOK-127: Kendo animates the option at 250ms from a rule of the SAME specificity as this one, so source order alone carries it. MOVES THE RENDER — 250ms → 120ms, matching React's MuiMenuItem. (Both the ledger and the token's own $description said "150ms"; core.motion.duration.fast resolves to 120ms. The prose was wrong, the binding is not.) */ transition: background-color var(--stm-dropdown-optionMotionDuration) var(--stm-dropdown-optionMotionEasing), color var(--stm-dropdown-optionMotionDuration) var(--stm-dropdown-optionMotionEasing); } .k-list-item:hover, .k-list .k-item:hover { background-color: var(--stm-dropdown-optionHover); } .k-list-item.k-selected, .k-list .k-item.k-selected { background-color: var(--stm-dropdown-optionSelected); color: var(--stm-dropdown-onOptionSelected); } /* ── Window/Dialog footer (StmDialog DialogButtons) ─────────────────────────── * TelerikWindow portals to the root, so StmDialog's scoped ::deep rules never * reach the footer, and its action row renders as Kendo's `k-actions-stretched` * (each button stretched into a column — the confirm floats mid-row, * render-verified 2026-07-16). Right-align like every DS dialog footer and * kill the stretch on the button wrappers. */ .k-window .k-window-actions, .k-dialog .k-dialog-actions, .k-dialog .k-dialog-buttongroup { display: flex; gap: var(--stm-space-sm); justify-content: flex-end; align-items: center; } .k-window .k-window-actions > *, .k-dialog .k-dialog-actions > * { flex: 0 0 auto; } /* ── Tooltip (tooltip.json) — TOK-113; RETAINED after #197 ──────────────────── * StmTooltip is Own and in the core now (#197), so the DS itself no longer * renders a TelerikTooltip. These rules stay because a consumer may still use * TelerikTooltip DIRECTLY (the "Direct vendor use" archetype), and an unthemed * vendor tooltip beside an STM one is precisely the two-mechanisms-on-one-screen * problem #197 was filed about. The history below is why they are here and not * in a scoped component sheet. * * ── Tooltip (tooltip.json) — TOK-113 ────────────────────────────────────────── * These rules used to live in StmTooltip.razor.css as `::deep .k-tooltip`, which * compiles to `[b-xxxx] .k-tooltip`. TelerikTooltip appends its popup to * (BODY > div > .k-animation-container > .k-child-animation-container > * .k-tooltip) with NO scope attribute on it, so that block could never match — * exactly the failure this file exists for. It was not merely cosmetic: with the * rule dead, `tooltip.typography` and `tooltip.maxWidth` never reached the Blazor * leg, so tooltips rendered at the inherited 16px and grew unbounded while the * React twin was 12px capped at 320px. Verified against the live popup. * * The container/onContainer colours DID land, via kendo-bridge.css — which is why * the block looked like it was working. */ .k-animation-container .k-tooltip, .k-tooltip { background-color: var(--stm-tooltip-container); color: var(--stm-tooltip-onContainer); max-width: var(--stm-tooltip-maxWidth); box-shadow: var(--stm-tooltip-elevation); font-family: var(--stm-tooltip-typography-font-family); font-size: var(--stm-tooltip-typography-font-size); font-weight: var(--stm-tooltip-typography-font-weight); line-height: var(--stm-tooltip-typography-line-height); border-width: var(--stm-tooltip-borderWidth); border-radius: var(--stm-tooltip-radius); padding-block: var(--stm-tooltip-paddingY); padding-inline: var(--stm-tooltip-paddingX); } .k-animation-container .k-tooltip .k-callout, .k-tooltip .k-callout { color: var(--stm-tooltip-container); width: var(--stm-tooltip-arrowSize); height: var(--stm-tooltip-arrowSize); }