Public: anyone can read this; the crew can change it.
The studio's stylesheet belongs in the stylesheet, not in every page #166
Check · Review · Land · Live done — Landed and live in production.
`studioCss` and `boardCss` now live in the served stylesheet instead of in a `<style>` block on every page that draws them.
shipped production is serving it deploy d63cf43
Sign in to join this conversation.
new above
offline
studioCssandboardCssnow live in the served stylesheet instead of in a<style>block on every page that draws them.What moved.
studioCss(4,587 bytes, sent by nine studio pages plus/apps) andboardCss(13,744 bytes, sent by the board) joincssinsrc/web/style.ts, in thecomponentslayer, last — afteravatarHues, beforecontent. An inline block sits outside every layer and therefore beats all of them, so last incomponentsis the nearest place that reads the same; I checked it selector by selector before moving anything. Nothing else in the sheet styles a.studio-or.board-selector, and the four rules that reach a shared class —.badge[data-variant="accent"],.studio-asks .row-lead,.studio-head .env-facts,.board-run .avatar— set properties those components do not, or out-specify them in either arrangement. The rule text is unchanged: I diffed both blocks, whitespace-normalised, against what the pages used to send, and they are identical.The trade, in numbers. The sheet grows from 94,585 to 112,970 bytes (+18,385), cached with an ETag and immutable once #113 lands; a studio app page sheds 4,587 bytes of CSS plus the
<style nonce>wrapper, on every request, and the board sheds 13,744.styleCssstays for what its doc names —labelCss, colours mixed from the labels actually on the page — and its doc now says so explicitly.Look at this. One test,
a finished run renders in the studio's own word, asserteddata-word="look". The badge on that page has always readwaiting("no deploy of this head yet"); what matched was.studio-list li[data-word="look"]inside the inline stylesheet. The test was wrong, not the code — I confirmed the rendered word iswaitingonmaintoo — so it now asserts the badge itself (data-word="waiting" id="run-word") and that the word is notplanned, which is what a run whose pull was not found would say.What I did not do.
bulkCsscame along: it is generated from the bulk-action table at module load but is the same for every request, so it belongs with the rest.mapCss(src/web/pages/map.ts, still passed asstyleCssfrom two places) is the same kind of static block and the same fix, but it is a different surface with its own cascade checks to do, and the issue scoped this to the studio and the board — worth its own issue. I also leftshell,railand most ofrowsin place: the doc comment says nothing draws them any more, and deleting a rule changes what is served, which is not this change.How to try it.
curl -s $PREVIEW/assets/forge.css | grep -c studio-finds the rules in the sheet; view source on the studio home, an app page,/appsor/boardand there is no<style>element; open an issue with a label and there still is one, holding only itslc-rule.bun x tsc --noEmitis clean and the check's test list is green apart from six failures that are identical onmainin this sandbox (they spawngitover SSH, which this environment refuses).🤖 Generated with Claude Code
Closes #155