/* ============================================================================ script-window.css · the autocue window's own look Lifted verbatim out of patterns/slides.css on 2026-08-19 when the window became a shared module (script-window.js), on the chip-frame precedent of 17 August. Not one declaration changed: the FlightDeck links this file immediately after slides.css, which is exactly where these rules used to sit, so its cascade is what it always was. The class names stay `deck-script*` for the same reason. ============================================================================ */ /* ---------- the script panel (autocue) ---------- Chrome, not a slide element: fixed in screen space, so it never scales with the frame, never exports and never reaches an audience. Geometry comes from the field in screen pixels; everything else comes from the design system. The colour blend is the point. Mike keys the chroma green out of his recording, so text mixed towards that same green stays readable on his screen and is gone in the video. Above zero the panel drops its own background and border, because a console-coloured box would key back in and sit there in the footage, and everything it still draws goes to the same green as the words: the drag label, the blend slider, the hex readout, the three buttons, the corner grip, the scrollbar. The whole panel leaves together, or the part that stayed behind is the part Mike sees in the film. At zero nothing is hiding from anything, so the words are white and the head keeps ordinary chrome colours. Note that zero does NOT bring the panel's own background back while the key is up: the body.deck-green block at the end of this file drops it whatever the blend, and that is deliberate and unchanged, so at zero with the key up the white words stand on the stage itself. With the key down, zero is the ordinary opaque console box it always was. Whether the words sit BEHIND the slide's boxes is a separate question with a separate answer, and it turns on the mode rather than on the blend or the key: presenting puts them behind, editing keeps them in front so they can be typed into. All of it is at the end of this section, with the dates and Mike's words. */ .deck-script { position: fixed; left: 24px; top: 120px; display: flex; flex-direction: column; /* the field sets width/height from its own state, so the box has to BE that number — border-box or every resize grew it by the two border pixels */ box-sizing: border-box; background: color-mix(in srgb, var(--bg) 94%, transparent); border: var(--b-hair) solid color-mix(in srgb, var(--fg) 22%, transparent); border-radius: var(--r-lg); /* One number, named, because the head and the corner grip have to hold this exact rank when the rest of the panel drops behind the slide (see the body.deck-green block at the end of this file). Two hand-copied 33s would drift the first time one of them was tuned. */ --deck-script-z: 33; z-index: var(--deck-script-z); color: var(--fg); font-family: var(--font-mono); overflow: hidden; --script-size: 17px; /* The field computes this: a walk across the green hues, from the stage's own chroma at the bottom of the slider through mint, spring green and pure green to a neon lime at the top, so every position is a DIFFERENT green rather than one green at a different strength. The old color-mix walked towards the cream foreground, which made most of the range not green at all. deck.js `_greenAt` carries the reasoning and Mike's words. */ --script-ink: var(--deck-key-ink, var(--deck-chroma, #5a9f7a)); /* What everything that is NOT the words wears once the blend is above zero. canvases/deck.js _applyScript writes the live value inline; this is the fallback for first paint and for a stage with no hue to walk. */ --script-controls-ink: var(--script-ink); /* The two parts of the blend slider the browser would otherwise draw for itself. Named here so the blended block below can swap both at once. At the far left the panel is ordinary chrome, so they are ordinary chrome: the rail off --fg and the knob on the stage's own green, which is what accent-color used to give. */ --script-rail: color-mix(in srgb, var(--fg) 28%, transparent); --script-knob: var(--deck-chroma, #5a9f7a); } /* THE FAR LEFT IS WHITE, NOT GREEN. Mike, 10 August 2026: "When the slider is all the way on the left (so the background is black) you can switch the text to white. There's no benefit to keeping it green." He is right, and blend 0 was the worst position on the slider, measured on the page the same day. With the key DOWN it was chroma green on the panel's own near-black box: readable, but dim, and hiding from nothing. With the key UP the panel had already dropped its background (the body.deck-green block at the end of this file), so the words were the chroma standing on the chroma and simply gone, while every control in the head sat there at full strength. A position where the script cannot be read and the chrome can is a dead position. So blend 0 leaves the green walk entirely: the words are the design system's console foreground, and the walk through the greens starts at blend 1. What is lost is a "words fully gone" stop, and it was not worth keeping: the x button and the touch bar's script button both take the whole panel away, and blend 1 still puts the words within a whisker of the chroma for the "only just there" hunt (the fade zone runs to blend 12, see _greenAt in canvases/deck.js). --deck-key-ink is deliberately NOT touched. It still carries the chroma at blend 0, because the slide's own not-yet-arrived words and the frame guide wear it, and white words on a keyed slide would be the one thing the audience could read. This is the panel's own ink and nothing else's. */ .deck-script:not([data-blended]) { --script-ink: var(--fg); } .deck-script.hidden { display: none; } /* THE CHIP INK AND TYPE (Mike, 2 October 2026, Events 1895963 and 1897043; tokens.css, CHIP TYPE). This is one of the author chips, so at blend zero its words and head are white, never the console's cream, and its head wears the chip type: the name ":: script" in the sans, the hex readout and the three short buttons in the mono. Above zero nothing here changes what the blend does: every mark still takes the one green. */ .deck-script[data-surface] { --fg: var(--chip-ink); --fg-soft: var(--chip-ink); --muted: var(--chip-ink-muted); --whisper: var(--chip-ink-faint); } /* A CANVAS THAT DOES NOT KEY GREEN OUT (Mike, 2 October 2026): "The script chip as it is was built for the flight deck, which was a green screen thing ... now we've got the ink and the viewer ... which doesn't require me to be looking at a green screen ... We can change the colours of the writing so that it's not green because I'm the only one that can see it. We just want it to be clear and easy for me to read." script-window.js leaves [data-blended] off a window mounted with greenKey false, so every green rule below that hangs on it never applies, and the window is the blend-zero window at every position of the slider: white words on the dark ground, the chip's own outlines. What is left is the two parts that were green even at zero, the slider's knob (the stage's chroma) and a hint that was a dim 45%, which is hard to read on a ground this dark. The FlightDeck does not pass greenKey false, so it keeps all of it. */ .deck-script-plain { --script-knob: var(--chip-ink); --script-rail: color-mix(in srgb, var(--chip-ink) 35%, transparent); } .deck-script-plain .deck-script-body:empty::before { opacity: 0.75; } .deck-script-head { display: flex; align-items: center; gap: 4px; padding: 6px 8px; border-bottom: var(--b-hair) solid color-mix(in srgb, var(--fg) 14%, transparent); flex: 0 0 auto; } .deck-script-drag { flex: 1; cursor: grab; font-family: var(--font-sans); font-size: var(--chip-name-size); font-weight: var(--chip-name-weight); letter-spacing: 0; touch-action: none; user-select: none; } .deck-script-drag:active { cursor: grabbing; } .deck-script-colour { display: flex; align-items: center; gap: 4px; } /* THE SLIDER IS DRAWN HERE, NOT BY THE BROWSER. accent-color only colours the thumb and the filled part of the track. The EMPTY part of the track is the browser's own, and it is a pale bar the key cannot touch: measured on the page, 10 August 2026, the input's own background computed to rgb(255,255,255) and the rail read as a light bar in the screenshot with the key up, sitting in the footage next to words that had vanished. Nothing short of appearance:none can reach it, so every pixel of this control is ours now: rail, filled length and knob. The filled length is not drawn, on purpose. Rebuilding it means a background gradient whose stop the field has to keep in step with the value on every input event, which is a second copy of the slider's state in a second place. The knob's position already says where the value is, and that is the only thing Mike reads off it. */ .deck-script-colour input[type="range"] { appearance: none; -webkit-appearance: none; width: 76px; /* the pointer target, not the rail. appearance:none hands us the hit area as well as the paint, and a 3px rail with a 3px box would be a worse control than the browser's. 16 keeps the grab about where the native one was while the visible groove stays hairline. */ height: 16px; min-width: 0; margin: 0; background: transparent; /* A form control does not inherit colour, so this one sat on the browser's own near-black (#101010, read on the page 10 August 2026) at every blend. It draws no text of its own today, so nothing showed, but it is the one value in the panel that a browser could reach for as currentColor without telling anyone. Inheriting costs nothing and closes it. */ color: inherit; cursor: pointer; } .deck-script-colour input[type="range"]::-webkit-slider-runnable-track { height: 3px; border-radius: var(--r-pill); background: var(--script-rail); } .deck-script-colour input[type="range"]::-webkit-slider-thumb { appearance: none; -webkit-appearance: none; width: 11px; height: 11px; margin-top: -4px; border: none; border-radius: var(--r-pill); background: var(--script-knob); } .deck-script-colour input[type="range"]::-moz-range-track { height: 3px; border-radius: var(--r-pill); background: var(--script-rail); } .deck-script-colour input[type="range"]::-moz-range-thumb { width: 11px; height: 11px; border: none; border-radius: var(--r-pill); background: var(--script-knob); } .deck-script-colour output { /* seven mono characters at the chip's number size */ width: 58px; font-size: var(--chip-num-size); font-weight: var(--chip-num-weight); text-align: right; font-variant-numeric: tabular-nums; } .deck-script-head button { font: inherit; font-size: var(--chip-num-size); font-weight: var(--chip-num-weight); background: transparent; color: inherit; border: var(--b-hair) solid var(--chip-outline); border-radius: var(--r-sm); padding: 1px 6px; cursor: pointer; } .deck-script-head button:hover { background: color-mix(in srgb, var(--fg) 10%, transparent); } .deck-script-body { flex: 1 1 auto; overflow-y: auto; padding: 10px 12px; font-family: var(--font-sans); font-size: var(--script-size); line-height: var(--lh-relaxed); color: var(--script-ink); white-space: pre-wrap; outline: none; } .deck-script-body:empty::before { content: attr(data-empty); opacity: 0.45; } .deck-script-resize { position: absolute; right: 0; bottom: 0; width: 16px; height: 16px; cursor: nwse-resize; touch-action: none; background: linear-gradient( 135deg, transparent 50%, color-mix(in srgb, var(--fg) 30%, transparent) 50% ); } /* Blended: the box disappears, while the slider walks the words continuously towards the live key colour to suit the exact recording setup. THE CHROME OF THE CHROME GOES WITH THE WORDS. Mike, 10 August 2026: "The chrome of the chrome - the controls of the script chip need to follow the same type of green changing-ness. because at the moment I can see the chromes chrome :)" He proved it with a frame of his own Ecamm output, key up: the script words had gone completely and the head was still sitting there. The cause was a COLOUR, not a strength. Everything in the head took the console foreground, --fg, which is the warm cream #f1ebdb (measured on the page, 10 August 2026: every one of the drag label, the hex readout, the three buttons and the corner grip computed to rgb(241,235,219)). A keyer removes green. Cream is not green at any opacity, so dimming it to 0.35 only made a fainter cream, which is exactly the ghost he photographed. So the fix is to put the SAME ink on the furniture that the words already wear, and the blanket 0.35 on the head goes, because it was buying nothing in the recording and costing him readability on his own screen. WEIGHT IS MIXED TOWARDS THE CHROMA, NEVER TOWARDS TRANSPARENT, wherever a weight is used at all. Alpha was the obvious way to vary strength, and it is wrong HERE, because the head and the corner grip deliberately stay IN FRONT of the slide's boxes while presenting with the key up (the block at the end of this file, and its own reasoning). A translucent green in front of a box composites with the BOX, not with the key colour. Measured on the page, 10 August 2026: with the head sat on the blue marker box behind the word "shape", the ":: script" label at 50% alpha rendered #5c8dbf and its fringe #d3dee9, hue 210, a pale blue-grey that no green keyer will touch. It is the same ghost Mike photographed wearing a different colour. Mixing towards var(--deck-chroma) gives the identical pixel everywhere the backdrop IS the chroma, which is most of the panel most of the time, and an opaque green everywhere it is not. Both ends of every mix are greens Mike keys cleanly, so a mix of them is one too. What is left over a box is the one-pixel antialias fringe of a glyph, which is the floor for any text drawn over anything. ONE GREEN FOR EVERY MARK THE PANEL MAKES, AND THE LADDER IS GONE. Mike, 10 August 2026, having deployed the ladder: "the dragger and 'script' title and the resizer in the RH bottom corner are on top of the objects and don't follow the colour of the rest of the chip." He named exactly the marks that had been mixed down, and none of the ones at full strength, which is the whole finding. Measured on the page the same day, key up, blend 96, chroma soft: the words and the buttons and the knob were rgb(102,255,61), while the drag label was srgb(0.376 0.812 0.359), the hex readout srgb(0.388 0.906 0.299), the button border and the corner grip srgb(0.374 0.793 0.371). Four different greens in one small panel. The ladder was there to keep the words the loudest thing, which is not something Mike asked for, and the cost of it was a panel that did not read as one object. So every mark the panel makes ON the key now takes the one ink: the words, the drag label, the hex readout, the buttons and their borders, the knob, the corner grip, the scrollbar thumb, the focus ring. A weight survives in exactly three places, and only because something has to read AGAINST it: slider rail 30% the groove the knob sits in, or the knob disappears button hover 20% the fill the button's own label sits on selection band 35% the band the selected letters sit on Those three are backdrops, not marks, and each is still a green off the same walk. All of it is var(--script-controls-ink), which walks the same greens on the same chroma as the words but is held out of the bottom eighth of the slider, where the words deliberately fade into the background. canvases/deck.js _applyScript computes it and says why. Above that zone it is the same value as --script-ink to the digit, so the controls change under Mike's hand exactly as he asked; below it they hold the first full-strength green on the walk, so the slider is still there to drag back out with. */ .deck-script[data-blended] { background: transparent; border-color: transparent; /* one declaration covers the drag label, the hex output and the three buttons, all of which inherit their colour from here */ color: var(--script-controls-ink); --script-rail: color-mix(in srgb, var(--script-controls-ink) 30%, var(--deck-chroma, #5a9f7a)); --script-knob: var(--script-controls-ink); } .deck-script[data-blended] .deck-script-head { border-bottom-color: transparent; } /* The drag label is the ":: script" Mike named first. It inherits the ink from the panel now, so the only thing left to say here is that it is never dimmed: an opacity would put it back on a different green from everything else, which is the whole complaint. (Its resting 0.7 at blend zero went on 2 October 2026 with the chip type, so this now only holds the line.) */ .deck-script[data-blended] .deck-script-drag { opacity: 1; } .deck-script[data-blended] .deck-script-head button { border-color: var(--script-controls-ink); } .deck-script[data-blended] .deck-script-head button:hover { background: color-mix(in srgb, var(--script-controls-ink) 20%, var(--deck-chroma, #5a9f7a)); } /* The corner grip Mike named second. A triangle of the one ink, so it keys out with the words rather than sitting on his boxes in a green of its own. */ .deck-script[data-blended] .deck-script-resize { background: linear-gradient(135deg, transparent 50%, var(--script-controls-ink) 50%); } /* A long script scrolls, and the browser's own scrollbar is chrome the panel did not ask for and the key would not swallow. The thumb is a mark on the key with nothing in front of it, so it takes the ink; the track behind it stays transparent, which is what makes the thumb readable at all. */ .deck-script[data-blended] .deck-script-body { scrollbar-color: var(--script-controls-ink) transparent; } /* Keyboard focus and text selection are both drawn by the browser in a colour of its own choosing, and both land in the footage if Mike tabs to a button or drags across a line while the key is up. The ring is a mark and takes the ink. The selection sets a BAND and leaves the letters their own colour, which is what a highlight is for, so it keeps a weight: the letters have to read against it. */ .deck-script[data-blended] .deck-script-head button:focus-visible, .deck-script[data-blended] .deck-script-colour input[type="range"]:focus-visible { outline: 2px solid var(--script-controls-ink); outline-offset: 1px; } .deck-script[data-blended] ::selection { background: color-mix(in srgb, var(--script-controls-ink) 35%, var(--deck-chroma, #5a9f7a)); } /* ---------- the panel's own box, whenever the key is up ---------- Blend above zero already drops the background and the border, for the reason at the top of this section: a console-coloured box keys back in and sits in the footage. This does the same at blend 0, which is the one blend that otherwise keeps it. The default blend is 96, so in practice there is no box to lose either way. It is only a colour, so it is true in both modes. */ body.deck-green .deck-script { background: transparent; border-color: transparent; } /* ---------- behind the boxes, while PRESENTING with the key up ---------- The answer to Mike's question at the top of this file. The words drop below the whole playfield, so every box on the slide paints over them, and they still stand on the key colour because the key colour is on the body now. PRESENTING IS THE GATE, AND THE KEY ALONE WAS THE WRONG ONE. Mike, 10 August 2026, having deployed the key-only version: "I've just noticed I now can't edit the script inside the script chip - I double click, option double click and nothing." He keys green while he WORKS, so gating on the key had made his autocue read-only in his real use. Measured on the page the same day, key up in edit: a click at the middle of the words landed on DIV.deck-prim-sticky, the slide's own box, focus never reached the panel, and an option double click opened that sticky note's editor instead of his script. Behind is worth having when he is READING the words off camera and worth nothing while he is WRITING them, so it follows the mode. Editing a deck is now exactly what it always was, green or no green, and he needs no setting to remember: he types in edit, reads in present. canvases/deck.js _applyMode puts the class on the body and carries his words. ONLY WITH THE KEY UP, still. With the key down the slide paints a solid --bg sheet of its own over the same rectangle, so a panel behind it is not behind anything, it is gone. THE HEAD AND THE GRIP STAY IN FRONT, at the panel's own rank, and this is MEASURED rather than assumed. Behind is not merely unclickable under a box: the playfield is a transparent fixed layer over the WHOLE window, so anything at a negative rank loses the hit test everywhere. Driven with a real pointer, 10 August 2026, with the head and the grip dropped to the words' own rank: drag, resize and blend were all dead both over a solid box and over bare key colour, and elementsFromPoint at the drag label returned the slide, the frame, the stage and two playfield wrappers all above it. The panel became a picture of itself. So the head keeps the blend slider Mike walks against his real recording, the grip keeps the resize, and what he gives up while presenting with the key up is clicking INTO the words, which is the one thing he does not do mid-take. POSITION ABSOLUTE IS THE WHOLE TRICK. Fixed always creates a stacking context, which would seal the head in with the words and bury the blend slider with them. This page cannot scroll (html and body are both overflow hidden, and scrollHeight equals the window height, measured 10 August 2026), so absolute against the initial containing block is the same rectangle in the same screen pixels, and the placement maths never notices: _setScriptPosition and _wireScriptDrag are clientX/clientY and window.innerWidth throughout. */ body.deck-green.deck-presenting .deck-script { position: absolute; z-index: auto; /* behind for the eye is behind for the hand: a press in the panel's dead area reaches the box that is now visibly in front of it */ pointer-events: none; } body.deck-green.deck-presenting .deck-script-body { z-index: -1; } body.deck-green.deck-presenting .deck-script-head, body.deck-green.deck-presenting .deck-script-resize { z-index: var(--deck-script-z); pointer-events: auto; /* AND THEY PAINT NOTHING UNTIL THEY ARE TOUCHED. See the block below for Mike's words, what was measured and why this is an opacity rather than a rank. */ opacity: 0; } /* ---------- the head and the grip, while PRESENTING with the key up ---------- Mike, 10 August 2026: "the dragger and 'script' title and the resizer in the RH bottom corner are on top of the objects and don't follow the colour of the rest of the chip." The colour half of that is answered further up this file. This is the other half: once the words went behind, these two became the only part of the panel still sitting over his artwork while he records, and they are only there because the block above deliberately holds them in front. DROPPING THEM BEHIND IS FATAL, and that is measured, not reasoned: at the words' own rank, drag, resize and blend were all dead over a solid box and over bare key colour alike, and the panel became a picture of itself. The evidence is in the block above. So they stay exactly where they are, stay grabbable, and paint nothing. A zero-opacity element still wins a hit test, which is the whole trick. Driven with a real pointer at 1440x900, 10 August 2026, with the pointer parked away from the panel: the frame was byte for byte identical to the same frame with both marks set to visibility hidden, so nothing of either one is painted, while elementFromPoint still returned div.deck-script-drag on the label, INPUT on the slider and div.deck-script-resize on the corner. Mike, on the option proved and offered: "yes I take it". TOUCHING EITHER ONE BRINGS BOTH BACK, because the pair is one piece of furniture. The hover is read on the PANEL even though the panel is pointer-events: none, which was measured rather than assumed: hovering the head or the grip sets :hover on .deck-script, and hovering the WORDS does not, because that press lands on the box in front of them. Drag, resize and blend all work from there, and a drag stays lit throughout because pointer capture keeps the hover on the element that captured it. THE KEYBOARD ROUTE BACK IS focus-within ON THE HEAD, NEVER ON THE PANEL. Tabbing reaches the blend slider (measured the same day: the touch bar, then the slider), so a hand that cannot find the strip with the pointer still has something to aim at. Scoping it to the head is the point: the words are a contenteditable that KEEPS its focus across a mode switch (measured the same day, typing in edit and then pressing present left .deck-script:focus-within true), so a panel-wide rule would hold the furniture lit through a whole take, which is the exact fault this rule exists to remove. The grip follows the head through the sibling combinator so the pair never half-appears. */ body.deck-green.deck-presenting .deck-script:hover .deck-script-head, body.deck-green.deck-presenting .deck-script:hover .deck-script-resize, body.deck-green.deck-presenting .deck-script-head:focus-within, body.deck-green.deck-presenting .deck-script-head:focus-within ~ .deck-script-resize { opacity: 1; } /* And while presenting with the key up they paint NOTHING. Mike, 10 August 2026: "the dragger and 'script' title and the resizer in the RH bottom corner are on top of the objects". Once the words dropped behind his boxes these two were the only part of the panel left over his artwork, and the colour fix made them more visible rather than less, because they went from dull to bright. Dropping them behind with the words was tried and is fatal (see the block above): the panel becomes a picture of itself. Painting nothing keeps every pixel of the behaviour, because a zero-opacity element still wins a hit test. They sit exactly where they were, they stay grabbable, and touching one brings it back at full strength. focus-within is the keyboard's way back, so an author who cannot find something invisible to point at can still tab to the blend slider and have it reappear. */ body.deck-green.deck-presenting .deck-script-head, body.deck-green.deck-presenting .deck-script-resize { opacity: 0; } body.deck-green.deck-presenting .deck-script-head:hover, body.deck-green.deck-presenting .deck-script-head:focus-within, body.deck-green.deck-presenting .deck-script-resize:hover { opacity: 1; }