- Shipped
- August 10, 2026 at 7:41 PM UTC
- Author
- kamo
- Commit
- 09bbb05
The tokens were declared on the calendar wrapper element, which reads as the tidy thing to do and is wrong. MUI dialogs and menus render through a portal into document.body, and custom properties cascade through the DOM rather than through React context — so inside the event dialog every var(--cal-*) resolved to nothing. Text fell back to the default colour, borders and backgrounds vanished entirely, and the dialog rendered as a plain colourless box. Moving them to :root fixes it for every portalled calendar surface at once, and keeps the white-labelling: each value is a color-mix over --color-primary substituted at use time, so a tenant theme redeclaring that colour still recolours all of them. With the tokens actually resolving, the dialog is rebuilt rather than restyled: - A colour spine down the left edge takes the event's colour — its own, or the calendar it lands on — so the thing being created has an identity before it has a name, and changing the colour visibly changes the object. - The header states the day it lands on in mono, with the weekday and time beside it. Previously you read two input values to work out what day you were creating something on. - When is one bordered card: both times, the derived duration, the presets, and all-day as a mode toggle in its own header rather than a lone switch three fields away from the times it changes. - Calendar and colour are chips and swatches with real surfaces, hover lift and selection rings, not dropdowns listing the names of colours. - A live preview chip shows how the event will appear on the grid, built from the same values, so the colour choice is concrete before committing. - Sections stagger in, the duration pill springs on change, and the recurrence block animates open. All of it is suppressed under prefers-reduced-motion. No new translation keys: every string is an existing one, and the duration, the preview and the date header are derived data.