/* ============================================================================= MAMBO — STUDIO WORKSPACE v3.29.0 studio.css is NOT purgeable. 58 of its 62 studio-owned class tokens have zero mention in any mambo sheet (94% — worse than chat.css's 68%, which is the sheet that established the rule). Purging it would un-skin the entire workspace: the toolbar, the panel headers, the seams, the float windows, the layout chooser and the drag affordances all live there and nowhere else. So this sheet OVERRIDES IN PLACE, and it does the bulk of the work by redefining tokens rather than by fighting rules. studio.css carries 98 `!important` declarations, but a custom property redefined at higher specificity changes the VALUE an `!important` declaration resolves to — `!important` protects the declaration, not the token it reads. That is why this file needs no `!important` of its own and no ID selectors. Enqueued after eos-studio (see mambo_purge_watch's neighbour in inc/mambo-enqueue.php), so equal-specificity ties fall this way. ========================================================================== */ /* ----------------------------------------------------------------------------- 1. THE PALETTE — the workspace stops being yellow Dennis: "the buttons on the studio toolbar at the top bar should not be using the yellow colours, it should adapt to the new prototype colours." `--st-gold` resolves to `var(--eos-gold, #F5A312)` and is read by EIGHTEEN rules — chips, the studio toggle, panel-header buttons, seam grips, resize handles, the drag dot, focus rings, the layout-tile video swatch and the preset tick-list. Redefining it once repaints all of them; editing eighteen rules would leave the next one to be added still yellow. studio.css declares these tokens in FOUR scopes, and all four have to be answered or the yellow returns in dark mode or inside the body-mounted layout chooser: .eos-watch--cinema (0,1,0) [data-theme="dark"] .eos-watch--cinema (0,2,0) .eos-studio-box, .eos-studio-notice (0,1,0) [data-theme="dark"] .eos-studio-box, .eos-studio-notice (0,2,0) Each override below adds exactly one class of specificity over its target. `.mb-watch` is on the same element as `.eos-watch--cinema` (page-watch.php:92), and the box/notice are body-mounted so they are scoped through `body.mb` instead. The accent tokens are mambo's own, so the workspace follows the light/dark flip already defined in mambo-tokens.css rather than carrying a second palette that has to be kept in step. -------------------------------------------------------------------------- */ .mb-watch.eos-watch--cinema { --st-gold: var(--acc); --st-gold-ink: var(--onacc); --st-focus: var(--acc); } [data-theme="dark"] .mb-watch.eos-watch--cinema { --st-gold: var(--acc); --st-gold-ink: var(--onacc); --st-focus: var(--acc); } /* The layout chooser and the workspace notice mount on , outside .eos-watch--cinema, and force their own light palette so they stay readable over a dark workspace. They need the same accent, from the same tokens. */ body.mb .eos-studio-box, body.mb .eos-studio-notice { --st-gold: var(--acc); --st-gold-ink: var(--onacc); --st-focus: var(--acc); } [data-theme="dark"] body.mb .eos-studio-box, [data-theme="dark"] body.mb .eos-studio-notice { --st-gold: var(--acc); --st-gold-ink: var(--onacc); --st-focus: var(--acc); } /* ----------------------------------------------------------------------------- 2. THE TOOLBAR — centred, and in the page's own chip language Dennis: "make sure the features and controls on the studio toolbar are not left aligned on the toolbar but centred." That is the prototype's own spec, not a preference: dc.html:1057 declares the studio toolbar `display:flex; align-items:center; justify-content:center; flex-wrap:wrap; gap:7px; padding:9px 12px`. studio.css set every one of those except `justify-content`, so the row packed to the left edge of a full-viewport bar and the controls sat a long way from the panels they act on. `flex-wrap: wrap` is already on the shipped rule and stays: with seven panel chips plus five commands the row has to be allowed to wrap on a laptop rather than overflow. Centring a wrapped row also keeps the second line balanced under the first instead of ragged. -------------------------------------------------------------------------- */ .mb-watch .eos-studio-bar { position: relative; justify-content: center; gap: 7px; padding: 9px 12px; } /* `justify-content: center` ALONE DOES NOTHING HERE, and this is the whole reason the bar was left-aligned in the first place. studio.js appends a spacer before the status line, and studio.css:134 gives it `margin-left: auto`. An auto margin consumes all the free space in a flex line, so there is none left for justify-content to distribute — the controls stay packed left however the container is justified. Neutralising the spacer is not optional, it is the fix; the centring above is only what happens once the space is free again. `display: none`, not `flex: 0 0 0`. Zeroing the width is not enough: a zero-width flex item still takes a `gap` on each side, so the spacer kept contributing a trailing 7px and left the controls measurably 4px off centre. Removing it from layout altogether is the only way the two end gaps match. */ .mb-watch .eos-studio-bar .eos-studio-spacer { display: none; } /* The status line is a live region that narrates what just happened ("Notes maximised", "Chat and Bible swapped"). It has to sit at the end AND it must not shift the controls each time its text changes — a centred group that jumps sideways whenever a message arrives is worse than one that is not centred. Taking it out of the flow satisfies both: the controls centre in the full bar width and stay put, and the element keeps its place in the accessibility tree, so role="status" still announces. */ Mobile-first: it stays in the flow by default, where a wrapped row simply carries it and nothing can overlap. Only above the two-column breakpoint, where there is room, is it lifted out. */ .mb-watch .eos-studio-bar .eos-studio-status { overflow: hidden; white-space: nowrap; text-overflow: ellipsis; } @media (min-width: 941px) { .mb-watch .eos-studio-bar .eos-studio-status { position: absolute; inset-inline-end: 14px; max-width: 210px; pointer-events: none; } /* AND THE SPACE IT SITS IN HAS TO BE RESERVED, or lifting it out of the flow just lets the controls run underneath it — measured overlapping by 96px once the row was wide enough. The reserve is SYMMETRIC so the centring above still resolves to the true middle of the bar; an end-only pad would centre the controls in a box that is not the bar. With it, a long control row wraps to a second line before it can reach the status, which is the behaviour `flex-wrap: wrap` was already there to provide. */ .mb-watch .eos-studio-bar { padding-inline: 236px; } } /* ----------------------------------------------------------------------------- 3. CHIP AND TOGGLE STATES With § 1 in place the "on" chips are already off the yellow, but a solid accent fill on six or seven simultaneous chips is a lot of clay for what is a toolbar of secondary controls. The rest of this page's chrome answers the same question with a soft accent wash and accent text — mambo-watch.css:252-256 paints `.eos-cn-ibtn.is-on` exactly that way — so the studio bar uses the page's established language rather than inventing a third one. The strong `--acc` from § 1 still does the work everywhere a strong colour is the point: focus rings, seam grips, the drag dot, the resize handle and the video swatch in the layout tiles. Prototype geometry, from studioBtnEl() at dc.html:3029-3033: 32px tall, 12px side padding, 9px radius, 12.5px at weight 650, transparent when off with a --line border and a --line2 hover. -------------------------------------------------------------------------- */ .mb-watch .eos-studio-bar button, .mb-watch .eos-studio-toggle { height: 32px; padding: 0 12px; border-radius: 9px; font-size: 12.5px; font-weight: 650; white-space: nowrap; transition: background var(--dur-fast, .18s) var(--ease, ease), color var(--dur-fast, .18s) var(--ease, ease), border-color var(--dur-fast, .18s) var(--ease, ease); } .mb-watch .eos-studio-bar button:hover, .mb-watch .eos-studio-toggle:hover { background: var(--line2); } .mb-watch .eos-studio-bar button.is-on, .mb-watch .eos-studio-bar button[aria-pressed="true"], .mb-watch .eos-studio-toggle.is-on, .mb-watch .eos-studio-toggle[aria-pressed="true"] { background: var(--accsoft); border-color: var(--accLight); color: var(--acc); } .mb-watch .eos-studio-bar button.is-on:hover, .mb-watch .eos-studio-toggle.is-on:hover { background: var(--accLight); color: var(--acc); } /* THE PIN, and a neat demonstration of why the token strategy is the right one. studio.css:278 paints its on-state `#eos-studio-pin.is-on { color: var(--st-gold-ink); }`. With § 1's values that token is white, which on the soft accent wash above would be invisible — the one control whose on-state is an icon rather than a label would vanish exactly when it is active. That rule carries an ID, so it sits at (1,1,0) and no mambo selector can out-specify it without an ID of its own — which this layer does not use. It does not need to. A custom property declared ON THE ELEMENT beats one inherited from an ancestor whatever the two selectors' specificities are, so redefining the token here changes the value that rule resolves to and the shipped rule paints correctly on its own. `!important` protects a declaration, not the token it reads. The attribute form keeps this at class-level specificity, so nothing here escalates the cascade. */ .mb-watch .eos-studio-bar [id="eos-studio-pin"] { --st-gold-ink: var(--acc); } @media (prefers-reduced-motion: reduce) { .mb-watch .eos-studio-bar button, .mb-watch .eos-studio-toggle { transition: none; } }