/* The typeface as a set of variables, so one class can take it back out again. THREE weights, not one, and that is the whole point of this block. A system monospace is TWO static faces: measured, 400 and 500 paint identically, and so do 600, 700 and 800 - so "bold" is one enormous step (+42% ink) with nothing in between. JetBrains is a variable font, a real continuum, where 700 is genuinely 700. Shipping the same numbers to both is what flattened the interface: with the body raised to 500 to match the old apparent weight, 700 was only +14% ink and the chrome that used to read as bold - the channel name, [EXIT], RELAYS, every heading - stopped standing out at all. So the numbers are named by their JOB (body, mid, bold) and each font gets the value that does that job in it. 500/700/800 against 400/600/700 lands the webfont at +31% body-to-bold, close to the fallback's +42% and a long way from +14%. The trailing 800 is the top of JetBrains' axis, which is the ceiling on how much of that gap can be closed while the body stays at 500. "sysFont" is the settings toggle switched off: the webfont comes off the front of the stack and the compensating weight goes with it, landing a reader exactly where they were before this font shipped. The @font-face rules below stay declared and cost nothing - a face nobody asks for is never fetched. */ :root { --font-stack: "JetBrains Mono", ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; --font-body-weight: 500; --font-mid-weight: 700; --font-bold-weight: 800; } html.sysFont { --font-stack: ui-monospace, SFMono-Regular, "SF Mono", Menlo, Consolas, "Liberation Mono", monospace; --font-body-weight: 400; --font-mid-weight: 600; --font-bold-weight: 700; } /* --- the typeface ------------------------------------------------------------- JetBrains Mono (SIL Open Font License 1.1, © 2020 The JetBrains Mono Project Authors - the full licence ships beside the files in /fonts/OFL.txt, which the OFL requires and which is why THIS font is here and not Apple's: SF Mono is licensed for use only with Apple-branded apps and may not be embedded to display content, so "just ship the one iOS picks" was never available). Shipped rather than borrowed from the system, because "the system monospace" is a different typeface on every platform: SF Mono on iOS and macOS, and on Windows, Linux and Android the ui-monospace keyword maps to nothing at all and the stack falls through to Consolas or Liberation Mono or whatever the vendor chose. One file means one client, everywhere. Self-hosted, not pulled from a font CDN: an app whose whole pitch is that nothing leaves your device should not be announcing every page load to Google. Six subsets, each with its own unicode-range, so a browser fetches only the scripts the text actually uses - 40KB of latin for most people, and the cyrillic and greek subsets only for the readers who need them. The variable weight axis (100-800) means one file per subset covers every weight in the stylesheet, including the 500 body and 700 bold below. Everything it does not cover - arabic, cjk, devanagari, emoji - falls through to the stack below exactly as before. No latin webfont carries those, and a cjk one is megabytes; the platform already has them. */ @font-face { font-family: "JetBrains Mono"; font-style: normal; font-weight: 100 800; font-display: swap; src: url("/fonts/jetbrains-mono-cyrillic-ext.woff2") format("woff2"); unicode-range: U+0460-052F, U+1C80-1C8A, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F; } @font-face { font-family: "JetBrains Mono"; font-style: normal; font-weight: 100 800; font-display: swap; src: url("/fonts/jetbrains-mono-cyrillic.woff2") format("woff2"); unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116; } @font-face { font-family: "JetBrains Mono"; font-style: normal; font-weight: 100 800; font-display: swap; src: url("/fonts/jetbrains-mono-greek.woff2") format("woff2"); unicode-range: U+0370-0377, U+037A-037F, U+0384-038A, U+038C, U+038E-03A1, U+03A3-03FF; } @font-face { font-family: "JetBrains Mono"; font-style: normal; font-weight: 100 800; font-display: swap; src: url("/fonts/jetbrains-mono-vietnamese.woff2") format("woff2"); unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+0300-0301, U+0303-0304, U+0308-0309, U+0323, U+0329, U+1EA0-1EF9, U+20AB; } @font-face { font-family: "JetBrains Mono"; font-style: normal; font-weight: 100 800; font-display: swap; src: url("/fonts/jetbrains-mono-latin-ext.woff2") format("woff2"); unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C0, U+2113, U+2C60-2C7F, U+A720-A7FF; } @font-face { font-family: "JetBrains Mono"; font-style: normal; font-weight: 100 800; font-display: swap; src: url("/fonts/jetbrains-mono-latin.woff2") format("woff2"); unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD; } :root { /* --- theme palette. These are BITCHAT, the default; the ten other themes override some of them from the data-theme blocks below, and everything further down derives from them via color-mix, so a theme only has to supply its core colors. The names in those blocks have to match THEMES in js/themes.js, which is what the /theme command lists and what hashes user names into a themed band. A theme present in one and not the other is either a name that cannot be selected or a selection that paints nothing - so themeparity.mjs checks the two lists against each other. --- */ --bg: #000000; --fg: #8fe89c; --muted: #7a828c; /* the clickable channel/location prefix - blue reads as "navigate here" and is the one palette slot not already claimed by identity (orange = you / hashed user hues), the app's voice (green), or metadata (gray). */ --geo: #5cb3ff; --user: #8ef29c; /* bitchat's dark-mode green (SwiftUI Color.green ~ systemGreen #30D158) */ --accent: #30d158; /* soft red for problem states (failed send, assist off) */ --danger: #ff7b72; /* follows the page unless a theme says otherwise - see the note in themes.js. What separates chrome from content is --chrome-border, not this. */ --chrome-bg: var(--bg); /* --- surface tuning: dark-theme defaults; light themes override these too --- */ --scanline-color: rgba(0, 0, 0, 0.16); /* CRT hairlines (body::before) */ --vignette-color: rgba(0, 0, 0, 0.32); /* corner falloff (body::after) */ --scrim: rgba(0, 0, 0, 0.82); /* backdrop behind gates/popups */ /* the height of a button docked below a card ([ back ], the gates' [ close ]): 12px of text plus 6px of padding either side */ --card-back-h: 30px; --selection-fg: #eaffea; /* text color inside ::selection */ --field-bg: rgba(0, 0, 0, 0.18); /* inset inputs + the new-messages bar */ /* The same recess, composited rather than translucent. A chamfered outline is two stacked layers - the edge colour with the fill inset 1px on top - so the fill has to be opaque or the edge shows through the whole box instead of just its rim. Mixed against --chrome-bg rather than hardcoded, so a light theme still gets a recess rather than a black hole. */ --field-solid: color-mix(in srgb, #000 18%, var(--chrome-bg)); --overlay-fg: rgba(255, 255, 255, 0.92); /* text on image overlays */ --overlay-shadow: 0 1px 2px rgba(0, 0, 0, 0.45); --bubble-theirs: rgba(255, 255, 255, 0.03); /* their DM bubble fill */ /* bottom safe-area with a js-supplied floor: standalone ios can report a zero bottom inset while the window really does reach the home indicator (same launch-bug family as the misreported viewport height), which sank the composer into the indicator. fitViewport sets --standalone-inset-b when it detects that state; max() means an honest env() always wins, so browser/android layouts are untouched. */ --inset-b: max(env(safe-area-inset-bottom, 0px), var(--standalone-inset-b, 0px)); /* --- derived: never set by themes, always follow --accent --- */ --chrome-border: color-mix(in srgb, var(--accent) 14%, transparent); --chrome-border-strong: color-mix(in srgb, var(--accent) 38%, transparent); /* hover/focus edge for bordered controls */ --glow: 0 0 9px color-mix(in srgb, var(--accent) 42%, transparent); /* phosphor bleed, reserved for chrome (never body text) */ /* css-generated labels, overridden by the i18n layer at runtime. english defaults here so they still read correctly if scripting is disabled. */ --label-toggle-on: "[ on ]"; --label-toggle-off: "[ off ]"; --label-no-users: "no one here yet"; --label-dm-empty: "no messages yet"; --label-no-convos: "no conversations yet"; --label-no-pings: "no pings yet"; } /* --- the themes ------------------------------------------------------------------ Everything above is BITCHAT, the default. Everything here is one of the other ten, selected by a `data-theme` attribute on . This is where the palettes live, and the reason they live here rather than in js/themes.js is timing. They used to be a table in that module, written onto documentElement.style at boot - but themes.js is imported by app.js, app.js pulls nostr-tools off the network, and nothing in that graph runs until the fetch lands. Measured on a warm cache: the saved theme reached the page 259ms AFTER first paint, so every load began with a frame of somebody else's colours - which is what the "connecting..." topbar was flashing. A stylesheet has no such problem. It is render-blocking by definition: the browser will not paint until it has this file, so a theme written here is on the FIRST frame. All the boot script in index.html has to do is set one attribute, which it can do synchronously, before this file has even finished loading. js/themes.js still owns the half that is not colour - the per-user name bands and the reserved "you" colour - and applyTheme is now just the attribute write. So each value is written down once: colours here, identity there. The default names no block of its own on purpose. :root IS bitchat, so an unknown or missing data-theme falls back to it rather than to nothing. --- */ /* cyberpunk 2077: cyan data readouts and hot-pink chrome. Ported value-for-value from the original prototype, which is why the accent is pink rather than the game's menu yellow - that yellow survives as the reserved "you" colour in themes.js. */ html[data-theme="cyberpunk-2077"] { /* OLED black: the pixels are OFF, not showing a very dark plum. The tint that made this bg a plum now lives only in the panel above it, which is where it can still be seen. */ --bg: #000000; --fg: #d7d7dc; --muted: #7e7e88; --geo: #2de2e6; --accent: #ff2a6d; --danger: #ff5a5a; /* not in the prototype (it has no selection colour); tinted from the accent the way every other theme here derives its own. */ --selection-fg: #ffe3ee; } /* blade runner 2049: joi's blossom pink against K's violet LA haze. */ html[data-theme="blade-runner-blossom"] { --bg: #0a0712; --fg: #e4d9f2; --muted: #857a9e; --geo: #b48cff; --accent: #ff6ac2; --selection-fg: #ffeaf6; } /* ex machina: the lab's red emergency lighting during the power cuts. danger becomes an amber alarm, because red is the ambient here and could not also be the alert. */ html[data-theme="ex-machina"] { --bg: #0b0507; --fg: #f2d9d9; --muted: #93706e; --geo: #ff8a5c; --accent: #ff3b30; --danger: #ffd60a; --selection-fg: #ffecec; } /* dune part two, giedi prime: the black sun's infrared monochrome - a world with no colour at all. */ html[data-theme="giedi-prime"] { --bg: #050505; --fg: #ededed; --muted: #878787; --geo: #bdbdbd; --accent: #e6e6e6; --selection-fg: #ffffff; } /* the matrix: code-rain green on true black. Black is #000000 rather than a near-black tint, so an OLED panel switches those pixels off instead of lighting them a couple of points above nothing. The greens run cold: every colour is its old hue pushed toward cyan at the same saturation and lightness, so the theme is recognisably itself and just chillier. --geo is pushed furthest, so the channel colour stays distinct from the accent now that the accent has moved into its old range. */ html[data-theme="matrix-neo"] { --bg: #000000; --fg: #a8ffdf; /* hue 131 -> 158 */ --muted: #567b70; /* 138 -> 162 */ --geo: #80fffb; /* 158 -> 178 */ --accent: #00ffa1; /* 144 -> 158 */ --selection-fg: #e5fff6; } /* guardians of the galaxy: quill's amber-gold 70s haze, milano engine cyan for chrome. */ html[data-theme="star-lord"] { --bg: #0c0806; --fg: #f2ddb8; --muted: #8e7d67; --geo: #ff8c42; --accent: #3fd8ff; --selection-fg: #eafaff; } /* loki's TVA: mid-century amber CRTs and miss minutes orange. */ html[data-theme="time-variance-amber"] { --bg: #0b0906; --fg: #ffd98c; --muted: #97845f; --geo: #ffc861; --accent: #ff9e1f; --danger: #ff6b5e; --selection-fg: #fff3d9; } /* tron legacy: the grid's ice blue and identity-disc cyan. */ html[data-theme="tron-legacy"] { --bg: #04070c; --fg: #cdeeff; --muted: #5f7f8e; --geo: #5ce1ff; --accent: #00b8ff; --selection-fg: #eaf9ff; } /* shared tuning for the two light themes: fainter CRT glass, a bright scrim, and dark-on-light inputs and overlays. Each theme's own block follows and overrides from here, so this has to come first. */ html[data-theme="lumon-light"], html[data-theme="her-light"] { --scanline-color: rgba(0, 0, 0, 0.05); --vignette-color: rgba(0, 0, 0, 0.10); --field-bg: rgba(0, 0, 0, 0.06); --overlay-fg: rgba(0, 0, 0, 0.75); --overlay-shadow: none; --bubble-theirs: rgba(0, 0, 0, 0.05); } /* severance: lumon's milky office light and MDR terminal teal. */ html[data-theme="lumon-light"] { --bg: #eef0ea; --fg: #24424a; --muted: #6c8189; --geo: #2f7d97; --accent: #106a74; --danger: #b3362b; --chrome-bg: #e3e8e1; --scrim: rgba(230, 235, 228, 0.88); --selection-fg: #143c42; } /* her: theodore's coral-and-cream world. */ html[data-theme="her-light"] { --bg: #f7efe6; --fg: #6b4a3f; --muted: #a2867a; --geo: #b04a36; --accent: #e0654f; --danger: #a63324; --chrome-bg: #f0e4d6; --scrim: rgba(247, 239, 230, 0.88); --selection-fg: #4a2f28; } /* --- `hidden` means hidden ------------------------------------------------------- The browser's own `[hidden] { display: none }` lives in the USER-AGENT stylesheet, which every author rule outranks. So any element whose class or id sets `display` - and in a flexbox layout that is most of them - goes on painting while reporting hidden === true, and the js that set it is not wrong about anything. It is a silent failure with nothing to see in the debugger. The patron category shipped that way: `.usersBarrier { display: flex }` quietly beat the attribute, so the heading and its two rules stayed on screen over a field that had correctly hidden itself. An audit found two more already in the tree (#profileNpub, #confirmPreview - the latter guarded by `.actionPreview[hidden]` that its own id rule outranks) and thirty-odd others one toggle away from it. One rule instead of a guard per element, and `!important` because that is the only thing an id selector cannot outrank. It costs nothing: an element that is `hidden` and also meant to be visible is not a thing. */ [hidden] { display: none !important; } html, body { margin: 0; padding: 0; width: 100%; height: 100%; background: var(--bg); color: var(--fg); /* JetBrains Mono first, then the old system stack unchanged behind it - so a blocked or failed font load lands exactly where this used to and nothing looks broken. SFMono-Regular and "SF Mono" stay in the list but have never matched anything: SF Mono is not requestable by name from web content on Apple platforms, and ui-monospace ahead of them is the only door to it. Held in a variable so the settings toggle can drop the webfont without this rule knowing anything about it - see html.sysFont at the top. */ font-family: var(--font-stack); /* Ligatures OFF, and not as a matter of taste. JetBrains Mono ships programming ligatures enabled, so "->" draws as a single arrow, "!=" as "≠", ">=" as "≥". That is a good thing in an editor and the wrong thing here: this is a chat client, where what somebody typed and what everybody else reads have to be the same characters. It also mangles the two things this app is full of - pasted keys and ascii art - and it would quietly rewrite the composer's own "message -> #geo" placeholder. One line to undo if it is ever wanted. */ font-variant-ligatures: none; /* A touch above regular. A webfont at 400 renders lighter than the SF Mono it replaces - partly the typeface, partly that ios darkens stems in a way chrome on android and the desktop do not - so the client looked thinner than it used to on exactly the platform most people read it on. 500 puts the weight back without approaching the 700 the bolds use, and costs nothing: the variable axis carries it in the same file. It travels WITH the webfont: the extra weight exists to compensate for that typeface, so a reader who switches it off should get their system font at its own normal weight, not a bolded version of it. The handful of rules that set 400 explicitly are de-emphasis (a muted alias, a select's options) and sit a step BELOW body while the webfont is on, which is what they were always asking for. */ font-weight: var(--font-body-weight); overflow: hidden; } /* CRT atmosphere: hairline scanlines + a corner vignette laid over the whole screen (gates included). both are static gradients - one composited layer, no animation, no repaints - and faint enough to feel rather than see. the whole layer rides the settings "retro terminal" toggle: js keeps a `retro` class on , and everything CRT-flavored (scanlines, vignette, phosphor glow, the name-gate typewriter) gates on it. off = the same layout in a clean modern skin. */ .retro body::before { content: ""; position: fixed; inset: 0; z-index: 9000; /* above the gates (1000): the glass sits over everything */ pointer-events: none; background: repeating-linear-gradient( 0deg, var(--scanline-color) 0px, var(--scanline-color) 1px, transparent 1px, transparent 3px ); } .retro body::after { content: ""; position: fixed; inset: 0; z-index: 9001; pointer-events: none; background: radial-gradient(ellipse at center, transparent 62%, var(--vignette-color) 100%); } /* modern mode: no phosphor bleed anywhere (--glow feeds every chrome text-shadow), no blinking block cursor after the handle, no relay status dot (the n/m count still tells the story), and the typewriter mask never animates - its resting transform leaves the text plainly visible. */ html:not(.retro) { --glow: none; } html:not(.retro) .cursor, html:not(.retro) .dot { display: none; } html:not(.retro) #nameGate.typing .gateSub span::after { animation: none; } /* phosphor terminal touches: green-tinted selection, accent caret in inputs */ ::selection { background: color-mix(in srgb, var(--accent) 30%, transparent); color: var(--selection-fg); } input, textarea { caret-color: var(--accent); } /* thin accent-tinted scrollbars instead of the browser chrome defaults */ * { scrollbar-width: thin; scrollbar-color: color-mix(in srgb, var(--accent) 22%, transparent) transparent; } *::-webkit-scrollbar { width: 6px; height: 6px; } *::-webkit-scrollbar-track { background: transparent; } *::-webkit-scrollbar-thumb { background: color-mix(in srgb, var(--accent) 22%, transparent); border-radius: 3px; } *::-webkit-scrollbar-thumb:hover { background: color-mix(in srgb, var(--accent) 40%, transparent); } #app { /* fallback only: at runtime js sizes this to the measured visualViewport height, because ios standalone misreports dvh (see fitViewport in app.js) */ height: 100dvh; display: flex; flex-direction: column; position: relative; /* containing block for the DM thread gate, so its composer rides the keyboard like #inputbar */ } #topbar { display: flex; align-items: center; justify-content: space-between; gap: 10px; padding: calc(10px + env(safe-area-inset-top)) 12px 10px; background: var(--chrome-bg); border-bottom: 1px solid var(--chrome-border); color: var(--accent); font-size: 13px; letter-spacing: 0.08em; text-transform: uppercase; text-shadow: var(--glow); /* phosphor bleed on the chrome only - body text stays crisp */ } /* the brand takes the slack and ellipsizes a long handle; the relay status never shrinks or wraps, so the row stays a clean single line at any name length */ .brand { cursor: pointer; min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } #status { flex: none; white-space: nowrap; } /* blinking block cursor after your handle - the terminal's heartbeat. its blink phase resets whenever the topbar rerenders, so it holds solid during bursts of activity and settles into a blink when things go quiet (like a real tty). */ .cursor { display: inline-block; width: 0.5em; height: 0.72em; /* ~cap height */ margin-left: 4px; /* sit the block on the text baseline so it fills the glyph cell and lines up with the letters, instead of text-bottom which dropped it into the descender gap and read low */ vertical-align: baseline; background: var(--accent); animation: blink 1.2s steps(1) infinite; } @keyframes blink { 50% { opacity: 0; } } /* relay link state: a solid dot while we hold connections, a dim pulsing one while we have none (searching) */ .dot { display: inline-block; width: 7px; height: 7px; margin-right: 7px; border-radius: 50%; vertical-align: 6%; background: var(--accent); box-shadow: 0 0 6px color-mix(in srgb, var(--accent) 70%, transparent); } .dot.off { background: var(--muted); box-shadow: none; animation: dotSearch 1.6s ease-in-out infinite; } @keyframes dotSearch { 50% { opacity: 0.25; } } /* your handle, and the channel name, show verbatim - the topbar otherwise force-uppercases (so a case-sensitive channel reads faithfully) */ .handle, .chan { text-transform: none; } /* the status is always interactive now: [EXIT] when focused, settings otherwise */ #status { cursor: pointer; } #terminal { flex: 1; min-height: 0; overflow-y: auto; /* THE LOG NEVER MOVES SIDEWAYS. `overflow-y: auto` alone makes the other axis compute to `auto` as well, so anything too wide to wrap - ascii art, a drawing, a board on a very narrow phone - turned the whole log into a horizontally scrollable surface. Every row then shifts together, the timestamps and names slide off the left edge, and a log you have to drag back into place is worse than one with a picture cropped in it. `clip` would be the honest value here and is NOT usable: a box that scrolls on one axis forces the other to a scrollable value too, so `clip` alongside `overflow-y: auto` computes to `hidden` (measured, not assumed). `hidden` still makes this a scroll container - it stops the reader dragging it, but the browser can still shift it (focus, scrollIntoView) with no way to put it back. So the guarantee is one level down, on .line: every row crops its own overflow, nothing ever overflows this box, and there is no sideways position to scroll to. This line is the backstop for anything that slips past that. */ overflow-x: hidden; display: flex; flex-direction: column; padding: 12px 14px; /* Room at the foot for the digest bar, which - unlike [new messages] - does not clear itself when you reach the bottom. Without this it sat permanently on top of the newest line. Set from js to the COLLAPSED row's height (see setQuietBarInset) and 0 whenever the bar is not up, so nothing is reserved for a bar nobody has. AFTER the shorthand above, which would otherwise reset it - which is exactly what it was doing, leaving a flat 12px that never changed. */ padding-bottom: calc(12px + var(--quiet-bar-h, 0px)); white-space: pre-wrap; word-break: break-word; font-size: 14px; /* The log stays ltr even when the ui is rtl (arabic). Every row is a record with a fixed gutter - "[hh:mm:ss] <@name#tag> body" - and under an rtl paragraph the bidi algorithm reorders that whole prefix: the clock lands on the far side, the angle brackets mirror, and the columns stop lining up. A terminal log is a table of records, not prose, so the frame is held ltr and the CONTENT is what's allowed to flip - see the plaintext rule below. */ direction: ltr; } /* Anything a person typed picks its own direction from its first strong character, the way `dir="auto"` does, and is isolated from its neighbours so it can't drag the surrounding punctuation around with it. That is what lets an arabic message read right-to-left inside a left-to-right row - and equally, an english message read correctly inside the rtl dm panel. .ts is in here because it wears two hats: the trailing clock AND the body of a system line. On the clock it's a no-op (no strong characters, so it keeps the container's direction); on a translated system line it's the whole point. */ .msg, .ts, .noteBody, .dmMsg, #chatInput, #dmInput, #notesInput { unicode-bidi: plaintext; } /* anchor messages to the bottom so the newest sit just above the input (and ride up with the keyboard) instead of a short backlog hanging at the top out of reach. The auto-margin spacer collapses to 0 once content overflows, so scrolling stays fully accessible. */ #terminal::before { content: ""; margin-top: auto; } .line { /* #terminal is a flex column, so lines are flex items and would shrink to fit an over-full view (the global feed) instead of letting it scroll. Plain lines survive that visually - a flex item's automatic minimum size floors them at their text height - but that floor only applies while overflow is VISIBLE, so a decorated line that clips (see .flair) collapses to its padding and its text disappears. Pin every line to its natural height: correct for a scrolling log, and it keeps any future clipping decoration safe. */ flex: none; margin: 0 0 4px 0; /* ...and no row may widen the log. #terminal wraps and breaks words, so ordinary text - urls, CJK, emoji - never gets here; what does is the handful of things that CANNOT wrap: a nowrap span, a game board narrower screens can't fit, ascii someone drew wider than a phone. Those get cropped at the row's own edge rather than pushing the whole column sideways. `clip` on x with `visible` on y, which is the one legal mix of the two. It has to be that pair: `hidden` on x would drag y along with it and make every row a scroll container, cutting off the flair decoration that deliberately spills above and below its line. `clip` crops without scrolling and leaves y alone. The clip margin then lets sideways glow out as well - it widens the paint boundary only, and creates no scrollable overflow (24px clears neon's widest bloom, its outermost shadow being ~21px). */ overflow-x: clip; overflow-y: visible; overflow-clip-margin: 24px; } /* live arrivals materialize with a short fade+rise; rerenders (channel hops, repaints) skip it so the whole backlog never re-animates. */ .line.arrive { animation: lineIn 0.18s ease-out; } @keyframes lineIn { from { opacity: 0; transform: translateY(3px); } } /* ephemeral status notices fade out before they're removed from the log */ .line.system { transition: opacity 0.3s ease; } .line.system.fading { opacity: 0; } /* messages that @-mention you: full-bleed across the terminal's horizontal padding (14px) so the highlight reaches the screen edges. The tint color is the sender's own color, set inline in JS. */ .line.mention { margin-left: -14px; margin-right: -14px; padding: 2px 14px; } .geo { color: var(--geo); cursor: pointer; text-decoration: underline; text-underline-offset: 2px; text-decoration-thickness: 1px; transition: filter 0.12s ease; } .geo:hover { filter: brightness(1.35); } /* "+7": how many messages the global feed passed over from this channel before drawing this line. Deliberately quiet - it is a density readout, not part of the message - but it sits tight against the channel name, because what it counts belongs to the channel rather than to the person speaking. Not underlined and not a tap target: the chip beside it is the thing you click. */ .geoMore { color: var(--muted); font-size: 0.82em; margin-left: 2px; vertical-align: 1px; } /* The quiet-channels digest: one folded row standing in for a burst of messages from channels with no history. Written as an aside, not an announcement. It is smaller than a message, muted to the same grey as a timestamp, and carries no "*" emphasis - because the thing it is reporting is precisely that nothing here demanded your attention. A notice that shouted about being flooded would be the flood arriving in a different costume. */ .quietDigest { display: inline-flex; align-items: baseline; gap: 6px; color: var(--muted); /* the same size as [new messages] directly beneath it - they are two notices on one surface, and two type sizes made them read as two unrelated things */ font-size: 0.9em; cursor: pointer; opacity: 0.8; transition: opacity 0.12s ease; -webkit-tap-highlight-color: transparent; } .quietDigest:hover { opacity: 1; } .quietMark { font-size: 0.9em; } .quietLabel { overflow-wrap: anywhere; } /* the channels themselves, once unfolded: a wrapped row of ordinary #geo chips, so each one is the same tappable thing it is anywhere else in the feed. It sits ABOVE its own toggle in the markup, because the bar is anchored to the foot of the feed - a list that opened downward would open into the composer. */ .quietGeos { display: block; padding: 2px 0 4px; font-size: 0.9em; /* Two independent limits, because a flood can name a great many rooms and neither alone is enough. The chip COUNT is capped in js (QUIET_MAX_CHIPS) so the dom never holds a thousand nodes; this caps the HEIGHT, so even sixty chips on a narrow phone scroll inside the panel instead of swallowing the feed. */ max-height: calc(var(--vvh, 100vh) * 0.3); overflow-y: auto; overscroll-behavior: contain; } /* One row per channel: where it was said on the left, what was said pinned to the right. A column of bare geohashes says nothing about whether you wanted any of it, which is the only question a reader has here. */ .quietRow { display: flex; align-items: baseline; gap: 10px; padding: 3px 12px; } .quietRow:hover { background: color-mix(in srgb, var(--accent) 7%, transparent); } .quietRowGeo { flex: none; } /* the preview: one line, clipped, never wrapping - it is a glimpse, and a row that wrapped would turn this list into the feed it is standing in for */ .quietRowText { flex: 1 1 auto; min-width: 0; overflow: hidden; white-space: nowrap; text-overflow: ellipsis; text-align: end; color: var(--muted); opacity: 0.85; } /* "+940 more" - the list is capped, and says so rather than just stopping */ .quietMore { display: block; padding: 4px 12px 2px; color: var(--muted); opacity: 0.8; white-space: nowrap; text-align: end; } .quietGeos[hidden] { display: none; } /* The bar itself: a fixture at the foot of the feed rather than a row inside it. Same neutral fill and blur as [new messages] directly beneath it, so the two read as one family of notices hovering over the same edge - but muted rather than accent, because one is an action and this is an aside. */ /* Transparent: the surface underneath both notices is #bottomBars (see there). */ #quietBar { background: none; user-select: none; } #quietBar[hidden] { display: none; } /* the same padding [new messages] uses, so the two lines sit on the same rhythm */ #quietBarToggle { display: flex; width: 100%; align-items: baseline; gap: 6px; padding: 8px 12px; border: 0; background: transparent; font: inherit; /* AFTER the shorthand, which resets size to inherit and was quietly undoing the 0.9em on .quietDigest - leaving this notice a size larger than the one beneath it. The same trap the log's padding fell into. */ font-size: 0.9em; text-align: start; } /* a hairline between the two notices ONLY when both are up: they are one surface, but they are still two different things and a shared edge with no articulation at all reads as one run-on sentence. Inset from the edges so it is a divider rather than a second border. */ #quietBar:not([hidden]) + #newMessagesBar:not([hidden]) { border-top: 1px solid color-mix(in srgb, var(--chrome-border) 55%, transparent); } .inlineLink, .inlineGeo { color: inherit; text-decoration: underline; text-underline-offset: 2px; text-decoration-thickness: 1px; cursor: pointer; transition: filter 0.12s ease; } .inlineLink:hover, .inlineGeo:hover { filter: brightness(1.35); } .inlineGeo { font-weight: var(--font-bold-weight); } /* An inline nostr: reference to a PERSON, drawn as their name. Styled like the #geo chip beside it rather than like a link: both are references to somewhere in this app, and neither leaves it. The accent colour is what says "this is a handle" - the same signal a name in a message header carries. */ .inlineMention { color: var(--accent); font-weight: var(--font-bold-weight); cursor: pointer; overflow-wrap: anywhere; transition: filter 0.12s ease; } .inlineMention:hover { filter: brightness(1.35); } /* ...and a reference we could not turn into anything better: an naddr, or a quote with nowhere to draw a card. Muted, because it is a placeholder standing where sixty characters of bech32 used to be - visible as a reference, not pretending to be content. */ .inlineRef { padding: 0 4px; border: 1px solid var(--chrome-border); border-radius: 2px; color: var(--muted); font-size: 0.85em; } /* bitchat weights: a medium name over a regular body, for everyone. Your own messages used to be fully bold on top of that (see .line.mine below, where the rule was and why it went); they are weighted like everyone else's now and marked only by their color. */ .user { font-weight: 500; } .msg { color: var(--fg); } /* a message made of nothing but emoji renders large - at body size a lone reaction reads as a typographic accessory rather than the gesture it was meant to be. Two sizes (see emojiScaleClass): fewer emoji, more room. inline-block + line-height:1 is what keeps the row from ballooning. Left inline, the glyph's own leading is added on top of the line's, so a 2.4em emoji pushes the row far taller than the emoji itself; taking it out of the inline flow and giving it a tight line box means the row grows by the glyph and nothing more. The small vertical-align nudge sits it on the run of text rather than hanging it off the baseline, so the "<@name#tag>" beside it stays visually attached. */ .emojiBig, .emojiMed { display: inline-block; line-height: 1; vertical-align: -0.12em; /* emoji are color glyphs, and "&g" paints text by clipping a gradient to it - which turns them into gradient silhouettes. Barely noticeable at body size, glaring at 2.4em, and it throws away the only thing a jumbo emoji is for. The fill is re-anchored so they always render as themselves. An explicit color, not currentColor: "&g" sets `color: transparent` as well as the fill, and color is inherited - so currentColor here resolves to the very transparency being undone. (The pay/ui chips can use currentColor safely because they declare a color of their own.) */ color: var(--fg); -webkit-text-fill-color: var(--fg); } .emojiBig { font-size: 2.4em; } .emojiMed { font-size: 1.6em; } /* Minecraft "&"-code animated formatting (see format.js). &g rainbow: a hue gradient clipped to the text that flows sideways. background-clip:text needs transparent fill; the gradient repeats so the scroll loops seamlessly. */ .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #ff5555 0%, #ffcc00 8%, #55ff55 16%, #55ffff 24%, #5b8dff 32%, #c74ddb 40%, #ff5555 48% ); background-size: 200% 100%; -webkit-background-clip: text; background-clip: text; -webkit-text-fill-color: transparent; color: transparent; animation: fmtRainbow 6s linear infinite; /* keep an underline/strike visible even though the glyph fill is transparent */ text-decoration-color: #ff8fb0; } @keyframes fmtRainbow { to { background-position: 200% 0; } } /* An emoji inside a colored or gradient run, kept as itself. -webkit-text-fill-color and background-clip:text both overrule a color font and flatten an emoji into a solid shape, so a run that sets either has to hand the emoji back their own painting. Everything the parent could be doing to the glyph fill is undone here; the parent's bold/italic/underline still apply, which is right - those don't destroy the emoji. "&s" makes format.js stop emitting this wrapper, and the silhouette comes back. */ .fmtEmoji { /* var(--fg), not `initial`: initial resolves to BLACK, which is invisible on this background the moment a matched sequence renders as a monochrome glyph rather than a color one (keycaps and a few dingbats do). A color emoji paints from its own palette either way - what actually rescued it is dropping the background-clip mask below. */ color: var(--fg); -webkit-text-fill-color: var(--fg); background: none; -webkit-background-clip: border-box; background-clip: border-box; animation: none; } /* &g is a WILDCARD, not literally "rainbow": with no flair equipped it's the rgb gradient above, but an equipped flair retunes it to its own palette, so your text and your row read as one effect. This needs no JS and no protocol change - the flair class is on the line and the &g span is inside it, so a descendant selector is the whole mechanism. Only the gradient (and its pace) is swapped; the scroll keyframes are shared, and the reduced-motion rule below still wins because it zeroes animation-name, leaving the themed gradient as a static fill. */ /* fire's &g reads as text lit BY the fire: the ember gradient keeps rolling, but the brightness huffs on the same uneven catch-and-settle curve as the row's glow, so the words swell and dim with the flame instead of scrolling at a fixed pace. Overriding animation-name here outranks the generic .fmtRainbow rule, so the reduced-motion block re-disables this selector by name. */ .flair-fire .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #ff3d00 0%, #ff7a18 8%, #ffb057 16%, #ffe6a3 24%, #ffb057 32%, #ff6a00 40%, #ff3d00 48% ); animation: fmtEmberText var(--fire-text-dur, 4.4s) linear var(--fire-text-delay, 0s) infinite; text-decoration-color: #ffb057; } @keyframes fmtEmberText { 0% { background-position: 0 0; filter: brightness(0.88) saturate(1); } 9% { filter: brightness(1.42) saturate(1.15); } 34% { filter: brightness(0.92) saturate(1); } 46% { filter: brightness(1.24) saturate(1.1); } 61% { filter: brightness(0.85) saturate(0.95); } 72% { filter: brightness(1.38) saturate(1.15); } 100% { background-position: 200% 0; filter: brightness(0.88) saturate(1); } } /* lightning's &g doesn't scroll - it STRIKES. A drifting gradient would fight the flair's whole idea, so the text sits dim and storm-blue and flares white on the same uneven double-tap cadence as the row's flashes (randomized per line via --lit-text-*). The gradient still creeps a little so the glow isn't static. Overriding animation-name here would outrank the reduced-motion rule below, so that block re-disables this selector explicitly. */ .flair-lightning .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #00a6ff 0%, #3fc9ff 12%, #a5ecff 24%, #ffffff 33%, #3fc9ff 42%, #00a6ff 48% ); animation: fmtStormText var(--lit-text-dur, 7s) linear var(--lit-text-delay, 0s) infinite; text-decoration-color: #a5ecff; } @keyframes fmtStormText { 0%, 100% { background-position: 0 0; filter: brightness(0.62); } 7% { filter: brightness(0.62); } 8.5% { filter: brightness(1.85); } 10% { filter: brightness(0.7); } 11.5% { filter: brightness(1.4); } 14%, 48% { filter: brightness(0.62); } 49.5% { filter: brightness(2.1); } 51% { filter: brightness(0.72); } 52.5% { filter: brightness(1.6); } 56% { filter: brightness(0.62); } 99.9% { background-position: 140% 0; } } /* rain's &g is the only wildcard that flows DOWN, matching the flair's motion: a vertical gradient scrolled along the y axis (hence the flipped background-size), so the text looks like water running over it. Overrides animation-name, so the reduced-motion block disables this selector by name too. */ .flair-rain .fmtRainbow { /* One period per TILE. A repeating-gradient at background-size:auto is sized to the element, so its last repeat is cut wherever the box ends and the next tile restarts mid-period - the seam that made the scroll snap back. Sizing the tile to exactly the 26px period instead (first and last stop the same color) means the tiles butt up perfectly, and a 26px scroll lands exactly one tile along: a true seamless loop. */ background-image: linear-gradient( 180deg, #3f7fc4 0%, #6fb2e8 23%, #c4e7ff 42%, #8ecbf2 62%, #5595d4 81%, #3f7fc4 100% ); background-size: 100% 26px; background-repeat: repeat; animation: fmtRainText var(--rain-text-dur, 3.2s) linear var(--rain-text-delay, 0s) infinite; text-decoration-color: #a9d6f5; } /* INCREASING background-position-y slides the image down the box, so the colors travel downward with the rain. (Going 0 -> 100% instead scrolls the viewport down THROUGH the image, which makes the pattern appear to climb - the bug this fixes.) */ @keyframes fmtRainText { 0% { background-position: 0 0; filter: brightness(0.95); } 50% { filter: brightness(1.16); } 100% { background-position: 0 26px; filter: brightness(0.95); } } /* plume's &g runs the same way the flair does: blown-out at the start of the run and falling away to deep violet, with the hot band sweeping along it so the glyphs look lit from the left as the plume moves. The brightness lift is what sells the overexposure - the same clipping the puffs get from overlapping, applied to type. Overrides animation-name, so the reduced-motion block disables it by name too. */ .flair-plume .fmtRainbow { background-image: linear-gradient( 90deg, #7e3ff2 0%, #a855f7 18%, #d8b4fe 34%, #fbf5ff 46%, #d8b4fe 58%, #a855f7 76%, #7e3ff2 100% ); background-size: 220% 100%; background-repeat: repeat; animation: fmtPlumeText var(--plume-text-dur, 6.5s) ease-in-out var(--plume-text-delay, 0s) infinite; text-decoration-color: #d8b4fe; } @keyframes fmtPlumeText { 0% { background-position: 0 0; filter: brightness(0.92); } 50% { filter: brightness(1.3); } 100% { background-position: 220% 0; filter: brightness(0.92); } } /* neon's &g is the TUBE, spelled out: an aqua field with a hard white core punched through it twice a cycle. The white stops are doubled at adjacent positions so the core is a crisp edge rather than a soft blend - a real tube's filament doesn't fade into its glow, it sits inside it. The field is exactly &b's aqua (#55ffff, see COLORS in format.js), which reads more like a lit tube than the deeper cyan that was here: a tube is bright and slightly washed out, not saturated. Nothing darkens between the cores either - the only variation across the run is the approach to white and back, which is all a real tube has. Aqua rather than the pink even though pink is the commoner tube, because at text size hot pink sat right on the row's own pink glass and the two smeared; aqua reads as a SECOND tube in the same sign, and simply matches on a cyan row. */ .flair-neon .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #55ffff 0%, #55ffff 6%, #c7ffff 8.5%, #ffffff 10%, #ffffff 11.4%, #c7ffff 13%, #55ffff 16%, #55ffff 28%, #c7ffff 31%, #ffffff 33%, #ffffff 34.4%, #c7ffff 36.5%, #55ffff 40%, #55ffff 50% ); animation-duration: var(--neon-text-dur, 5.5s); animation-delay: var(--neon-text-delay, 0s); text-decoration-color: #55ffff; } .flair-stars .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #ffffff 0%, #cfe6ff 8%, #a8ccff 16%, #f0d2e8 24%, #ffffff 32%, #bcd8ff 40%, #ffffff 48% ); animation-duration: 8s; /* a slow shimmer, matching the twinkle's calm */ text-decoration-color: #dbe9ff; } /* &k obfuscated: app.js scrambles the glyphs on a timer; the class is just the hook it queries. A faint dim marks it as noise even between frames. */ .fmtObf { opacity: 0.92; } @media (prefers-reduced-motion: reduce) { /* freeze the rainbow to a static (still colorful) gradient; app.js likewise scrambles obfuscated text only once instead of animating it. */ .fmtRainbow { animation: none; } } /* --- line flair: preset ambient effects (see flair.js) ---------------------- Drawn entirely by keyframes on pseudo-elements: no images, no canvas, and no per-frame JavaScript. Each effect animates only opacity/transform, which the browser keeps on the compositor, so a screenful of flaired lines costs almost nothing on the main thread. Particle fields are ONE 2px dot cloned by box-shadow into a dozen sparks - a whole ember shower in a single layer. `isolation` opens a stacking context so the z-index:-1 decoration paints behind the text yet stays inside the row; `overflow:hidden` stops particles spilling onto neighbouring lines. */ /* THE ONE RULE EVERY FLAIR'S WASH FOLLOWS, before the individual effects below. ========================================================================== A flair's ambient tint runs HORIZONTALLY - linear-gradient(90deg, ...) - and never top-to-bottom. ========================================================================== Not a style preference. A chat log is rows stacked directly on one another, so a wash that is bright at one horizontal edge and dark at the other puts a light line and a shadow line along every row boundary - which is exactly how a bevel is drawn. The whole log turns into a column of extruded 3d buttons, and it happens at the moment a SECOND flaired row appears, so it looks fine while you are building the flair on its own. Three of these were built vertical first and all three had to be turned: fire's glow, fireflies' lit meadow, and the bubbles tank. A flat wash loses the one effect it was drawn for and keeps the log flat, and flat is worth more every time. If a flair needs a vertical component, it belongs in the fx layer as something that MOVES - the eye reads motion as depth and reads a static vertical ramp as a bezel. */ .flair { position: relative; isolation: isolate; overflow: hidden; } .flair::before, .flair::after { content: ""; position: absolute; pointer-events: none; z-index: -1; } /* a flaired row gets breathing room for the effect, pulled back by negative margins so its text stays aligned with plain lines. */ .line.flair { padding: 3px 6px; margin: 0 -6px 4px; border-radius: 4px; } /* the live-animated swatches /flair prints */ .flairChip { display: inline-block; padding: 3px 10px; border-radius: 4px; margin-right: 4px; /* Every swatch the same width, so a strip that wraps lines up in columns instead of ragging - the names run from four characters to nine, and left to size themselves the rows had nothing in common. `ch` is the right unit for it: the labels are the log's monospace, so one ch is exactly one character, and 9 is the longest name there is. Centred, because a short name padded on one side only looks like a mistake rather than a column. Row spacing too - wrapped rows of chips with no gap between them read as one block of color rather than as a list. */ min-width: 9ch; text-align: center; margin-bottom: 5px; /* An inline-block's baseline is its last line box UNLESS its overflow is clipped, in which case it's the bottom margin edge. Every flair here clips except neon, which has to let its glow out - so left on the default the neon swatch aligned by a different rule from its neighbours and sat visibly lower in the row. Taking all of them off the baseline entirely is what keeps the strip level. */ vertical-align: middle; } /* fire: a bonfire under a night sky. The glow fades HORIZONTALLY (as lightning's does): a vertical wash reads as a bevel once rows stack up, giving the whole log an unintended 3d-button look. It also HUFFS rather than pulses - a smooth sine reads as a machine breathing, so the keyframes surge fast and fall away slowly at uneven intervals, the way a fire catches and settles. Two independent particle fields rise off the bottom edge: bright embers straight off the flame (::after) and slower, wider-wobbling ash that snuffs out partway up (.flairFx). Both corkscrew instead of travelling straight, and every value - the huff's period and depth, each field's speed, phase, spacing, color and drift - is randomized per line in flair.js. Two fields is the trick that lets some sparks die early while others ride all the way, without paying a composited layer per spark: each field is one box-shadow-cloned dot. */ .flair-fire::before { inset: 0; background: linear-gradient(90deg, rgba(255, 96, 0, 0.24), rgba(255, 150, 40, 0.07) 60%, transparent); animation: flairFireGlow var(--fire-glow-dur, 3.4s) ease-in-out var(--fire-glow-delay, 0s) infinite; } /* the ash haze: still a box-shadow field, because for dim slow specks behind the embers a shared cadence doesn't read. Its sway eases per waypoint so it drifts rather than jolting, and it snuffs out partway up. */ .flair-fire::after { left: var(--ash-left, 20px); top: 100%; width: 2px; height: 2px; border-radius: 50%; background: #8a7f77; box-shadow: var(--ash-field, 40px 0 #6d635c, 96px 0 #b9a89a, 158px 0 #c9762f, 226px 0 #7d726a); animation: flairAshRise var(--ash-dur, 5.5s) linear var(--ash-delay, 0s) infinite; } /* the ember layer is just a container; every spark inside it is its own element */ .flair-fire > .flairFx { inset: 0; opacity: 1; } /* One ember. Two animations compose into its transform: `translate` carries the rise (linear - steady climb) and `transform` carries the sway (ease-in-out + alternate - a smooth oscillation with no corners). Their periods are unrelated and independently phase-shifted, so the path never repeats and the field never marches in step. */ .flair-fire .ember { position: absolute; bottom: -2px; left: var(--e-x, 20%); width: var(--e-size, 2px); height: var(--e-size, 2px); border-radius: 50%; background: var(--e-tint, #ffb057); opacity: 0; animation: emberRise var(--e-rise, 4s) linear var(--e-rise-delay, 0s) infinite, emberSway var(--e-sway, 2s) ease-in-out var(--e-sway-delay, 0s) infinite alternate; } /* the long invisible tail is deliberate: with every ember on its own period, those dead stretches drift past each other so the shower clusters and lulls instead of streaming evenly. */ @keyframes emberRise { 0% { translate: 0 0; opacity: 0; } 6% { opacity: var(--e-peak, 0.95); } 48% { opacity: calc(var(--e-peak, 0.95) * 0.5); } 66% { translate: 0 calc(var(--e-lift, 2.2em) * -1); opacity: 0; } 100% { translate: 0 calc(var(--e-lift, 2.2em) * -1); opacity: 0; } } /* embers that burn out low: same rise, snuffed much earlier */ .flair-fire .ember.emberShort { animation-name: emberRiseShort, emberSway; } @keyframes emberRiseShort { 0% { translate: 0 0; opacity: 0; } 8% { opacity: calc(var(--e-peak, 0.95) * 0.85); } 30% { opacity: calc(var(--e-peak, 0.95) * 0.35); } 40% { translate: 0 calc(var(--e-lift, 2.2em) * -0.5); opacity: 0; } 100% { translate: 0 calc(var(--e-lift, 2.2em) * -0.5); opacity: 0; } } @keyframes emberSway { from { transform: translate3d(calc(var(--e-amp, 6px) * -1), 0, 0); } to { transform: translate3d(var(--e-amp, 6px), 0, 0); } } /* fast catch, slow settle, twice per cycle at uneven depths - a fire breathing */ @keyframes flairFireGlow { 0% { opacity: var(--fire-glow-low, 0.45); } 9% { opacity: var(--fire-glow-peak, 0.95); } 34% { opacity: calc(var(--fire-glow-low, 0.45) * 1.25); } 46% { opacity: calc(var(--fire-glow-peak, 0.95) * 0.82); } 61% { opacity: var(--fire-glow-low, 0.45); } 72% { opacity: var(--fire-glow-peak, 0.95); } 100% { opacity: var(--fire-glow-low, 0.45); } } /* ash: dim, slow, gone by ~70%. Each waypoint eases in and out of the next, so the drift is a soft serpentine instead of the hard corner a linear interpolation would put at every offset. */ @keyframes flairAshRise { 0% { transform: translate3d(0, 0, 0); opacity: 0; animation-timing-function: ease-in-out; } 20% { opacity: 0.42; animation-timing-function: ease-in-out; } 42% { transform: translate3d(var(--ash-x1, -4px), -0.5em, 0); opacity: 0.32; animation-timing-function: ease-in-out; } 60% { transform: translate3d(var(--ash-x2, 6px), -0.95em, 0); opacity: 0.18; animation-timing-function: ease-in-out; } 74% { transform: translate3d(var(--ash-x3, -3px), -1.3em, 0); opacity: 0; } 100% { transform: translate3d(var(--ash-x3, -3px), -1.45em, 0); opacity: 0; } } /* lightning: a distant thunderstorm. No moving highlight - a sliding shine reads as polished metal, not weather. Instead the row holds a slow-breathing blue haze (the storm sky) under a flash layer whose timeline is mostly DEAD AIR punctuated by sheet-lightning glows: each event is a double-tap flicker, one faint and one noticeably brighter, washing most of the line for a split second. Every value - cadence, phase, brightness, where the glow is centred - is randomized per line in flair.js, so a screenful flickers unevenly like real weather rather than pulsing in unison. Rare full strikes (bolt + whiteout) come from the ticker in app.js, the same way shooting stars do. */ .flair-lightning::before { inset: 0; background: linear-gradient(90deg, rgba(90, 150, 255, 0.2), rgba(150, 200, 255, 0.06) 60%, transparent); animation: flairStormHaze var(--lit-haze-dur, 6s) ease-in-out var(--lit-haze-delay, 0s) infinite; } .flair-lightning::after { inset: 0; /* a broad soft glow rather than a band, so a flash lights the row as a whole */ background: radial-gradient( 130% 190% at var(--lit-flash-x, 30%) 50%, rgba(226, 240, 255, 0.85), rgba(150, 200, 255, 0.28) 42%, transparent 74% ); opacity: 0; animation: flairStormFlash var(--lit-flash-dur, 9s) linear var(--lit-flash-delay, 0s) infinite; } /* the sky itself never sits still, but it never strobes either */ @keyframes flairStormHaze { 0%, 100% { opacity: 0.45; } 50% { opacity: 0.85; } } /* two flash events per cycle, both double-tapped, separated by long silence - the gap is the point: it's what makes the next one feel like weather. */ @keyframes flairStormFlash { 0%, 5% { opacity: 0; } 6.5% { opacity: var(--lit-flash-peak, 0.3); } 8% { opacity: 0.04; } 9.5% { opacity: calc(var(--lit-flash-peak, 0.3) * 0.65); } 12%, 46% { opacity: 0; } 47.5% { opacity: calc(var(--lit-flash-peak, 0.3) * 1.75); } 49% { opacity: 0.06; } 50.5% { opacity: calc(var(--lit-flash-peak, 0.3) * 1.2); } 52% { opacity: 0.03; } 53.5% { opacity: calc(var(--lit-flash-peak, 0.3) * 0.5); } 57%, 100% { opacity: 0; } } /* --- neon: the frame IS the effect ----------------------------------------------- Every other flair fills the row - embers, drops, stars, a wash. This one puts nothing inside it at all: a glass tube bent around the outline, buzzing, with a section that occasionally gives out and catches again. Three layers, all animating opacity and nothing else, so despite looking like the most expensive effect here it is the cheapest - no blur, no blend, no particles: ::before the tube: a band of colored glass ::after the filament: a thinner white line down the MIDDLE of that band .neonDead the failure, hosted in the shared fx layer The filament is the whole trick, and it is the opposite of what a first pass reaches for. Glow does not come from spread - a wide BRIGHT halo just reads as a blurred rectangle and crowds the rows either side of it. It comes from a hot white centre with color to either side of it, which is what a lit tube actually looks like: the arc is white, the gas around it carries the hue. Everything strong therefore stays within a few pixels of the glass; what reaches further out is faint enough that it never resolves as an edge, and only makes the dark less dark. The other thing that carries it is where the light GOES. Neon is the only flair with a hard closed shape - the other five are weather, and weather has no edges - so left throwing light outward only it reads as a css border with a glow bolted on. It throws the same light inward, across the row it frames and onto the text sitting there. A sign lights its own wall. A border does not. The light has to escape, because a sign's whole character is the light it throws; the base .flair clips, which exists to keep PARTICLES in, and this flair has none to lose. So y opens up - but x stays clipped, or a neon row would be the one thing in the log able to push the column sideways. Its glow still gets out sideways: the clip margin on .line reaches past the tube. */ .flair-neon { overflow-x: clip; overflow-y: visible; /* the row is inside the sign, so the sign's light is on its text too. Subtle enough not to soften the glyph edges, present enough that the words belong to the tube rather than sitting in front of it - which is what every other flair gets for free from its background wash, and what neon had no way to get. */ text-shadow: 0 0 7px color-mix(in srgb, var(--neon-halo, #ff5cb0) 38%, transparent); } /* the glass. Three stops out and three in, each wider and fainter than the last. The near stops are what you read as the tube; the far ones never resolve as an edge at all, they just make the dark around the row slightly less dark, and that is the difference between light and a stroke. The widest inward stop is the wash across the row - it is why this frame has an interior at all. */ .flair-neon::before { inset: 0; border: 3px solid var(--neon-lit, #ff2d95); border-radius: 6px; box-shadow: 0 0 2px var(--neon-lit, #ff2d95), 0 0 var(--neon-bloom, 8px) var(--neon-halo, #ff5cb0), 0 0 calc(var(--neon-bloom, 8px) * 2.6) color-mix(in srgb, var(--neon-halo, #ff5cb0) 34%, transparent), inset 0 0 2px var(--neon-lit, #ff2d95), inset 0 0 var(--neon-bloom, 8px) color-mix(in srgb, var(--neon-halo, #ff5cb0) 62%, transparent), inset 0 0 calc(var(--neon-bloom, 8px) * 4) color-mix(in srgb, var(--neon-lit, #ff2d95) 26%, transparent); animation: flairNeonHum var(--neon-hum-dur, 0.9s) linear var(--neon-hum-delay, 0s) infinite; } /* the filament, centred in that band: the tube runs 0-3px in from the edge, so its middle is at 1.5px and a 1px line at inset 1px sits exactly on it. It carries a tight white bloom of its own - the arc is the brightest thing in the assembly and blows out slightly against the gas around it. Same phase as the glass, because it is one tube: the arc and the gas do not buzz separately. */ .flair-neon::after { inset: 1px; border: 1px solid #ffffff; border-radius: 5px; box-shadow: 0 0 2px rgba(255, 255, 255, 0.65), inset 0 0 2px rgba(255, 255, 255, 0.5); animation: flairNeonHum var(--neon-hum-dur, 0.9s) linear var(--neon-hum-delay, 0s) infinite; } /* neon is the only flair whose decoration leaves its own box, so it is the only one that can collide with its neighbours. Everything else clips. */ .line.flair.flair-neon { margin-bottom: 12px; } /* The CRT glass, welded to the flairs that are ABOUT being a screen - neon and matrix - rather than to the app. The "retro terminal" setting lays scanlines over the WHOLE screen; this lays the same hairlines over those rows and nothing else, and does it whether or not that setting is on. A tube (or falling code) read through a scanline is just what those look like - it is the flair, not a preference - so it should not be something you have to go and switch on somewhere else to get. Unlike every other layer a flair owns, this one sits ABOVE the text (z-index 1, inside the row's own stacking context): a CRT overlays what it is displaying, and putting it under the glyphs would leave the words conspicuously the one thing in the row not behind glass. It is a single static gradient, so it costs one composited layer and no per-frame work - which is why, unlike .flairFx, it is never parked by the animation budget. */ .flairScan { position: absolute; inset: 0; z-index: 1; pointer-events: none; /* follows whatever the row is rounded to, so it never cuts a corner the flair underneath it didn't (neon widens both - see .flair-neon .flairScan) */ border-radius: inherit; background: repeating-linear-gradient( 0deg, var(--scanline-color) 0px, var(--scanline-color) 1px, transparent 1px, transparent 3px ); } /* with the whole-app CRT switched on, the global overlay is already drawing these exact lines over this exact row - a second pass would only make neon rows darker than everything around them. */ html.retro .flairScan { display: none; } /* neon's glass is rounded a little wider than the row it frames, so its scanlines match the tube rather than the row. */ .flair-neon .flairScan { border-radius: 6px; } /* The buzz. Shallow, fast, and deliberately NOT a sine: mains hum is a ragged thing, and evenly spaced keyframes read as a slow pulse no matter how quick you make them. The values wander within a few percent of full - enough to see, not enough to look like it is fading in and out. */ @keyframes flairNeonHum { 0% { opacity: 0.93; } 13% { opacity: 1; } 19% { opacity: 0.88; } 34% { opacity: 0.99; } 48% { opacity: 0.92; } 57% { opacity: 1; } 71% { opacity: 0.9; } 86% { opacity: 0.97; } 100% { opacity: 0.93; } } /* A tube does not switch on, it CATCHES: the starter arcs, the gas won't hold, it arcs again, and only after a few goes does it settle. So a neon row strikes up as it arrives - which is the same physics as the dead segment, played at the other end of the tube's life, and it is what gives this flair the thing the other five all have and it did not: a motion with a story in it rather than a decoration. `.arrive` is added once, to live arrivals only, and never to a rerender (see app.js), so scrolling back through history doesn't re-fire a room full of signs. The strike is listed AFTER the hum so it owns the opacity while it runs and hands back cleanly the moment it ends - a non-forwards animation stops contributing once it's done, and the hum is already there underneath. :not(.flairQuiet) so a row that arrives already parked (off screen, or over the animation budget) never strikes - it just is, which is the whole point of quiet. The reduced-motion block below has to repeat the selector to outrank this one. */ .line.arrive.flair-neon:not(.flairQuiet)::before, .line.arrive.flair-neon:not(.flairQuiet)::after { animation: flairNeonHum var(--neon-hum-dur, 0.9s) linear var(--neon-hum-delay, 0s) infinite, flairNeonStrike 1.05s linear 1; } @keyframes flairNeonStrike { 0%, 6% { opacity: 0; } 8% { opacity: 1; } 12% { opacity: 0.04; } 21% { opacity: 0; } 23% { opacity: 0.92; } 27% { opacity: 0.08; } 34% { opacity: 0.88; } 38% { opacity: 0.12; } 46% { opacity: 1; } 51% { opacity: 0.35; } 59% { opacity: 1; } 66% { opacity: 0.72; } 100% { opacity: 1; } } /* neon's fx layer is not a particle field - it is a full-row canvas the failing segment is placed on. Opacity 1 because the segment carries its own. The z-index shuffle is what makes the failure possible at all. Everything a flair draws sits at -1, and among equal z-index the paint order is tree order: ::before (glass), then .flairFx, then ::after (filament). So the segment could occlude the glass but the white core ran straight through it, which is not a tube going out, it is a smudge on one. Dropping both pseudo-elements a layer puts the fx canvas above the whole assembly - and still below the text, which is the only thing that must never be occluded. */ .flair-neon::before, .flair-neon::after { z-index: -2; } .flair-neon > .flairFx { inset: 0; opacity: 1; z-index: -1; } /* The dead segment: a patch of the page's own background laid over one rail. Occluding rather than un-lighting is the trick - there is no way to switch off part of a border, but a piece of the background sitting on top of it is indistinguishable from a length of tube that has stopped conducting. It has to swallow the BLOOM as well as the glass and the filament, or the line goes dark while its glow keeps burning around the gap, which reads as dirt on the glass. An ellipse rather than a bar, because a bar has four hard edges and every one of them announces itself as a rectangle drawn over the effect. Fading to transparent at the ends lets the dark blend back into the lit tube the way a section losing its arc actually goes: dimmest in the middle, uncertain at the boundaries. It is deliberately much taller than the tube it covers. The bloom now reaches a long way on both sides, and an occluder sized to the glass alone leaves the glow still burning in a ring around the gap - which reads as dirt on the tube rather than as a length of it going out. Whatever the tube lights, the dead section has to stop lighting, so the patch has to be as big as the light. */ .flair-neon .neonDead { position: absolute; top: var(--neon-dead-top, -9px); bottom: var(--neon-dead-bottom, auto); left: var(--neon-dead-x, 22%); width: var(--neon-dead-w, 24%); /* biased inward: it has to reach far enough across the row to kill the wash the dead length was throwing, but only far enough OUTWARD to take the near bloom with it. Sized symmetrically it would reach past the row and start eating the glow off the message above, and one sign's fault cannot dim another's. */ height: 24px; background: radial-gradient(ellipse closest-side, var(--bg) 0 45%, transparent 100%); opacity: 0; animation: flairNeonDead var(--neon-dead-dur, 15s) linear var(--neon-dead-delay, 0s) infinite; } /* A failing tube does not blink on a timer - it drops out, gropes for the arc, catches, loses it again, then holds. So the segment is dark for the overwhelming majority of the cycle and the failure itself is a short irregular burst: out, back, out longer, back, one last flutter, then steady for another fifteen seconds or so. The long quiet stretch is what keeps it an event you catch rather than a rhythm you learn. */ @keyframes flairNeonDead { 0%, 87.4% { opacity: 0; } 87.5% { opacity: 1; } 88.1% { opacity: 0; } 88.4% { opacity: 1; } 89.6% { opacity: 1; } 89.9% { opacity: 0; } 90.6% { opacity: 0.85; } 91% { opacity: 0; } 91.4% { opacity: 1; } 92.1% { opacity: 0; } 100% { opacity: 0; } } /* --- matrix: falling code behind the row -------------------------------------- The only flair made of glyphs. Everything else here is a fill; this is text, and that is the whole reason it reads differently from the rest of the list. Three layers, as usual, plus the shared CRT glass over the top (see .flairScan - matrix and neon are the two flairs that are ABOUT being a screen): ::before the phosphor wash - the green a monitor throws on its own bezel ::after a soft bloom off the bottom edge, where the code has piled up .flairFx the columns themselves Note there is deliberately NO green cast on the message text. Every other character in the row belongs to somebody, and tinting it would take that away; the code falls BEHIND what people said, it doesn't recolor it. */ .flair-matrix::before { inset: 0; background: linear-gradient(180deg, rgba(0, 255, 65, 0.15), rgba(0, 255, 65, 0.05) 55%, transparent); animation: flairMatrixWash var(--mtx-wash-dur, 6s) ease-in-out var(--mtx-wash-delay, 0s) infinite; } .flair-matrix::after { left: 0; right: 0; bottom: -1px; height: 9px; background: linear-gradient(0deg, rgba(0, 255, 65, 0.3), transparent); animation: flairMatrixWash var(--mtx-wash-dur, 6s) ease-in-out var(--mtx-wash-delay, 0s) infinite; } @keyframes flairMatrixWash { 0%, 100% { opacity: calc(var(--mtx-wash-peak, 0.7) * 0.55); } 50% { opacity: var(--mtx-wash-peak, 0.7); } } .flair-matrix > .flairFx { inset: 0; opacity: 1; overflow: hidden; } /* one falling column: a stack of glyph cells that travels the height of the row and keeps going, so it is always entering or leaving rather than sitting still. */ .flair-matrix .mtxCol { position: absolute; left: var(--m-x, 20%); top: 0; /* Height is the ROW's, not the glyph stack's, and that is load-bearing: a translateY percentage resolves against the element's own height, so a column sized to its glyphs would measure its fall in glyph-heights and spend most of the cycle out of sight above or below a 26px row. Sized to the row, the same percentages mean row-heights and the fall lands where it can be seen. The stack overflows this box freely - the fx layer is what clips. */ height: 100%; display: flex; flex-direction: column; /* anchored to the bottom so the HEAD leads: it is the lowest glyph, so it is the first thing to enter the row and the last to leave it. */ justify-content: flex-end; font-size: var(--m-size, 10px); line-height: 1; /* a stack that has CJK coverage before the ui font's fallback gets a say. The 1em cells below mean a substituted glyph can look different but cannot shift the column, so this is about quality, not correctness. */ font-family: "Hiragino Kaku Gothic ProN", "Yu Gothic", "Noto Sans CJK JP", "Noto Sans JP", "MS Gothic", monospace; white-space: nowrap; opacity: var(--m-op, 0.8); /* STEPPED, not linear. A terminal advances by whole character cells - it does not glide - and a smooth translate is the single thing that made this read as snow drifting rather than as a machine printing. Eight jumps across the travel puts each one at roughly a glyph height for the sizes in use, so a column appears to scroll a line at a time. It quantizes the fade in the same keyframes, which is no loss: a terminal's output arrives, it doesn't ease in. */ animation: flairMatrixFall var(--m-fall, 0.9s) steps(8) var(--m-delay, 0s) infinite; } /* every cell is exactly one glyph square, whatever font ends up drawing it */ .flair-matrix .mtxGlyph, .flair-matrix .mtxHead { display: block; width: 1em; height: 1em; text-align: center; overflow: hidden; } .flair-matrix .mtxGlyph { color: #22ff5e; opacity: var(--m-dim, 0.5); text-shadow: 0 0 4px rgba(0, 255, 65, 0.5); } /* the head: the bright one at the leading edge, near-white the way an over-driven phosphor goes, with the green bleeding out around it. */ .flair-matrix .mtxHead { color: #eaffef; text-shadow: 0 0 3px rgba(216, 255, 230, 0.9), 0 0 7px rgba(0, 255, 65, 0.95), 0 0 14px rgba(0, 255, 65, 0.5); } /* ...and the sprite sheet that makes it churn. The strip is MATRIX_REEL_LEN glyphs tall (see flair.js); stepping the translate by whole glyphs means the cell above only ever shows one of them, cleanly, and the character appears to change without a single byte of text being rewritten. */ .flair-matrix .mtxReel { display: block; animation: flairMatrixReel var(--m-reel, 0.8s) steps(5) var(--m-reel-delay, 0s) infinite; } .flair-matrix .mtxReel i { display: block; width: 1em; height: 1em; font-style: normal; } /* steps() and this distance are MATRIX_REEL_LEN from flair.js - see the note there. Stepping by whole glyphs is what keeps the cell showing exactly one. */ @keyframes flairMatrixReel { to { transform: translateY(-5em); } } /* Falls from clear of the top to clear of the bottom - the row clips it, so a column is only ever a slice of a longer fall you never see the whole of. It fades in and out at the ends rather than popping, which is what keeps the row's edges soft instead of looking like a marquee. */ @keyframes flairMatrixFall { 0% { transform: translateY(-140%); opacity: 0; } 9% { opacity: var(--m-op, 0.85); } 88% { opacity: var(--m-op, 0.85); } 100% { transform: translateY(115%); opacity: 0; } } /* matrix's &g is the code itself: phosphor green with the over-driven near-white heads punched through it, on the same scroll every other wildcard uses. */ .flair-matrix .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #00913a 0%, #00ff41 9%, #d8ffe6 13%, #d8ffe6 14.2%, #00ff41 18%, #00913a 27%, #00913a 33%, #00ff41 39%, #d8ffe6 42%, #d8ffe6 43.2%, #00ff41 47%, #00913a 54%, #00913a 60% ); animation-duration: var(--mtx-text-dur, 5s); animation-delay: var(--mtx-text-delay, 0s); text-decoration-color: #00ff41; } /* --- sonar: a node pinging the mesh ------------------------------------------- The first flair whose motion is radial. Everything else in this list travels along an axis, and expansion from a point is the one shape none of them can borrow - which is most of why this belongs in a chat client built on geohashes and relays rather than being one more weather effect. Two layers, plus the shared CRT glass over the top (see .flairScan - a scope is a display in the same way neon's tube and matrix's monitor are): ::before the phosphor glow the scope throws around the origin .flairFx the rings, and any contact the sweep has found Nothing is drawn AT the origin. There was a node dot there and it read as a control sitting on the row; the wavefronts arriving out of nothing is the better picture, and it costs one less animated pseudo-element. The row clips all of it, which is the point: see the note in flair.js. As with matrix, the message text is deliberately left alone. The scope is behind what people said; it doesn't recolor it. */ .flair-sonar::before { inset: 0; /* Two backgrounds in one layer, which is one composited layer and one animation either way. The pool is centred on the emitter rather than washed across the row, so the tint has a SOURCE - the same point the rings leave from - instead of being a flat cast that happens to be green. The floor under it is there because a radial glow alone left the far end of a long row completely untinted, and a row that stops reading as flaired halfway along is the one thing every other effect here manages to avoid. It is the unswept phosphor: dim, even, and the thing the pool is brighter THAN. */ background: radial-gradient( circle at var(--son-x, 30%) var(--son-y, 50%), rgba(46, 255, 160, 0.3), rgba(46, 255, 160, 0.1) 42%, transparent 78% ), linear-gradient(rgba(46, 255, 160, 0.075), rgba(46, 255, 160, 0.075)); opacity: var(--son-wash-peak, 0.75); animation: flairSonarWash var(--son-wash-dur, 7s) ease-in-out var(--son-wash-delay, 0s) infinite; } @keyframes flairSonarWash { 0%, 100% { opacity: calc(var(--son-wash-peak, 0.75) * 0.5); } 50% { opacity: var(--son-wash-peak, 0.75); } } .flair-sonar > .flairFx { inset: 0; opacity: 1; overflow: hidden; } /* one wavefront. Sized to this row's full reach and scaled up into it, so the only animated properties are a transform and an opacity - the same discipline the rest of the file keeps. Positioned by half its own size off the origin for the same reason the emitter is: it leaves the transform free. The stroke scales with the ring, so a wavefront broadens as it travels. Left as a hairline that would be a defect; at 2px with a soft glow it is the one thing about a scaled ring that happens to be right - a real wavefront disperses as it goes, and the opacity falls off faster than the width grows (see below), so it still loses ink on the way out. A ring is at its thinnest in the first instant of its life, for the same reason. It used to have a bright dot at the origin covering that instant; without one it fades up over the first few percent of its travel instead, which reads as a wavefront forming rather than as one being switched on. */ .flair-sonar .ping { position: absolute; left: calc(var(--son-x, 30%) - var(--son-reach, 170px) / 2); top: calc(var(--son-y, 50%) - var(--son-reach, 170px) / 2); width: var(--son-reach, 170px); height: var(--son-reach, 170px); border-radius: 50%; border: 2px solid rgba(125, 255, 194, 0.95); box-shadow: 0 0 6px rgba(46, 255, 160, 0.4); opacity: 0; /* the row's whole cycle, offset by this ring's index times the burst gap and by the row's phase. A SMALL gap, so the three leave close together and the rest of the cycle is silence - see the pacing note in flair.js. None of the arithmetic is written down twice: flair.js hands over the cycle, the gap and the phase, and the burst falls out of them. */ animation: flairSonarPing var(--son-ping, 10s) linear calc(var(--son-phase, 0s) - var(--son-ping, 10s) * var(--r-i, 0) * var(--son-gap, 0.09)) infinite; } /* LINEAR, and that is the whole physics of it: a wavefront travels at a constant speed, so anything eased turns the ping into a thrown object that decelerates. The fade is not linear, though - it drops off far faster than the radius grows, the way energy spread over a widening circle does. The travel is over by 45% of the cycle and the rest is a held, invisible rest. That rest is where the silence between bursts comes from, and it is the reason these offsets are what they are: the ring has to be DONE early enough that the last one of the burst still finishes with dead time to spare after it. app.js reads the expansion out of these keyframes rather than keeping its own copy of the number (see ringClock), so retuning the shape here does not put the contact quietly out of step with the wavefront that is supposed to be lighting it - and since how long a contact stays lit is derived from the same reading, the two cannot drift apart. */ @keyframes flairSonarPing { 0% { transform: scale(0.1); opacity: 0; } 4% { opacity: var(--son-lit, 0.9); } 16% { opacity: calc(var(--son-lit, 0.9) * 0.42); } 31% { opacity: calc(var(--son-lit, 0.9) * 0.14); } 45% { transform: scale(1); opacity: 0; } 100% { transform: scale(1); opacity: 0; } } /* --- the contact (see sonarBlip in app.js) ------------------------------------ A zero-size anchor at a bearing off the origin; both children hang off that point by half their own size, which is what leaves each of their transforms free to be nothing but the pop or the expansion it wants. This is geometry and color only. Everything that MOVES is driven from app.js, because a contact is lit by a wavefront arriving at it: the flash has to be scheduled against a live ring rather than started when the element happens to be inserted, its LENGTH is the wait until the sweep gets back to it, and it happens several times, at several places, over one contact's life. None of that is expressible as a fixed keyframe list. Hence the resting state below is invisible - what is on screen between one contact fading out and the next sweep finding it again is nothing at all, for about a second. */ .flair-sonar .blip { position: absolute; left: calc(var(--son-x, 30%) + var(--b-dx, 60px)); top: calc(var(--son-y, 50%) + var(--b-dy, 0px)); width: 0; height: 0; opacity: 0; } /* Far brighter than anything the ambient effect does, because a return is information and the rings are only the asking. Hung off the anchor by half its own size, which leaves its transform free to be nothing but the pop. A dot and nothing else. It used to have a small ring expanding out of it as it lit, and that was one idea too many - radial expansion is what the sweep does, and a second source of it on the same row read as a second emitter rather than as something the first one had found. */ .flair-sonar .blipDot { position: absolute; left: -3px; top: -3px; width: 6px; height: 6px; border-radius: 50%; background: radial-gradient(circle, #ffffff 0%, #b6ffdd 38%, rgba(46, 255, 160, 0) 75%); box-shadow: 0 0 8px rgba(125, 255, 194, 0.9), 0 0 16px rgba(46, 255, 160, 0.45); } /* sonar's &g is the sweep, and it is the only wildcard here that isn't a color cycle: the run sits at its decayed floor, a hot line crosses it, and behind the line the phosphor falls back down to that floor again. Which is why the stops are a cliff followed by a ramp rather than a smooth loop. The shared scroll animates background-position to 200% against a 200%-wide image, which slides the image LEFT - so a fixed glyph samples the gradient left to right in TIME. Time order is therefore stop order: the line first, its persistence after. Writing the ramp before the cliff instead would give a screen that brightens ahead of its own sweep, which is a thing no scope has ever done. The floor is a readable green rather than the near-black an honest unswept scope would be, for the reason matrix's floor is: half a message is going to be sitting in it, and a wildcard run that can only be read twice a cycle is a worse idea than a slightly overexposed phosphor. Only the gradient and its pace are overridden, so the shared scroll keyframes and the reduced-motion switch-off both still apply as they are. */ .flair-sonar .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #f2fff9 0%, #f2fff9 0.5%, #9dffd2 2%, #45f2a8 6%, #1cc47c 12%, #12a06a 20%, #0e8256 30%, #0c7049 40%, #0c7049 50% ); animation-duration: var(--son-text-dur, 9s); animation-delay: var(--son-text-delay, 0s); text-decoration-color: #2ee39a; } /* --- fireflies: a few of them over the row ------------------------------------ The simplest flair in the list, and the one closest to fire - which is where its particles come from. It borrows the construction (see the note in flair.js: one element per insect, because a cloned field is one animation and lights as one) and does the opposite thing with it. An ember travels; it rises, and everything else decorates the rise. A firefly has nowhere to be, so its two axes are slow oscillations on unrelated periods and its glow is on a third - a path that wanders without closing, lit from somewhere new each time. Two layers, and no CRT glass: this is the one recent flair that is not a screen. ::before the warm dark the insects are seen against .flairFx the insects The wash is not decoration. Every insect is dark for about half its cycle, so there are moments when none of them is lit - and a PARKED row has its fx layer hidden outright. Without something behind them a row would blink out of reading as flaired at all, which is the one thing every effect here manages to avoid. */ .flair-fireflies::before { inset: 0; /* HORIZONTAL, as fire's and lightning's are, and for the reason written down over at .flair-fire::before: a wash that runs top-to-bottom reads as a BEVEL once rows stack up, and turns the whole log into a column of extruded 3d buttons. This started out vertical - a bright bottom edge, meant to read as a lit meadow - and that is exactly what it did. The flat look is worth more than the meadow, and it is what every other flair here already does. Two backgrounds in one layer, which costs the same as one. The flat floor under the gradient is what stops the far end of a long row going properly black, which had it not reading as flaired at all whenever the insects were between glows. Being flat, it adds no shading in either direction. */ background: linear-gradient(90deg, rgba(154, 224, 74, 0.26), rgba(126, 196, 66, 0.09) 58%, transparent), linear-gradient(rgba(122, 192, 62, 0.07), rgba(122, 192, 62, 0.07)); opacity: var(--fly-wash-peak, 0.65); animation: flairFlyWash var(--fly-wash-dur, 8s) ease-in-out var(--fly-wash-delay, 0s) infinite; } @keyframes flairFlyWash { 0%, 100% { opacity: calc(var(--fly-wash-peak, 0.6) * 0.55); } 50% { opacity: var(--fly-wash-peak, 0.6); } } .flair-fireflies > .flairFx { inset: 0; opacity: 1; overflow: hidden; } /* One insect: a hot little core inside a soft halo of its own color. The halo is a GRADIENT, not a blurred shadow, and that distinction is the whole reason this is visible at all. `box-shadow: 0 0 11px` on a two-pixel dot does not add light - it smears the same two pixels' worth of color over eleven, so the first cut of this rendered as almost nothing on a dark row. A radial gradient across a box the size the glow should actually BE paints the whole area. It is still one static rasterization and still costs nothing per frame; only opacity and transforms animate. So --f-size is the halo, not the insect - the bright part is the inner quarter of it. `currentColor` lets one custom property drive core, halo and falloff together, and the opacity animation dims all three as one, the way a real one dims. */ .flair-fireflies .fly { position: absolute; left: var(--f-x, 40%); top: var(--f-y, 50%); width: var(--f-size, 11px); height: var(--f-size, 11px); /* pulled back by half its own size so the halo is centred on the point, not hung off it - the box is now big enough for that to be visible */ margin: calc(var(--f-size, 11px) / -2) 0 0 calc(var(--f-size, 11px) / -2); border-radius: 50%; color: var(--f-tint, #d4ff6a); /* The core HOLDS before it falls away. A stop that is full alpha at 0% and gone by 25% is bright at one mathematical point and faint everywhere else, so the insect came out as a smudge with no centre; keeping it solid through the first tenth gives it something to actually be. Same reason the tint holds to 22% before its falloff starts. */ background: radial-gradient(circle, rgba(255, 255, 250, 0.98) 0%, rgba(255, 255, 250, 0.92) 9%, rgba(255, 255, 250, 0) 30%), radial-gradient(circle, currentColor 0%, currentColor 22%, transparent 70%); opacity: 0; animation: flairFlyDrift var(--f-drift, 6s) ease-in-out var(--f-drift-delay, 0s) infinite alternate, flairFlyBob var(--f-bob, 4s) ease-in-out var(--f-bob-delay, 0s) infinite alternate, flairFlyGlow var(--f-glow, 4.5s) ease-in-out var(--f-glow-delay, 0s) infinite; } /* The two axes, on separate PROPERTIES rather than in one keyframe set holding both. Sharing a set would mean sharing a period, and two oscillations on one period trace a line or an ellipse - a closed shape, and a shape you can see repeating. On unrelated periods the same two produce a figure that never quite returns to where it started, which is the difference between meandering and pacing. */ @keyframes flairFlyDrift { from { translate: calc(var(--f-ax, 16px) * -1) 0; } to { translate: var(--f-ax, 16px) 0; } } @keyframes flairFlyBob { from { transform: translate3d(0, calc(var(--f-ay, 5px) * -1), 0); } to { transform: translate3d(0, var(--f-ay, 5px), 0); } } /* Gradual, and dark for about half of it. The rise is quicker than the fall, which is what keeps it from reading as a sine - a firefly comes up and then lingers on the way out. The long dark tail does the same job it does for fire's embers: with every insect on its own period those stretches drift past each other, so the row is never all lit or all dark and a handful reads as many more than a handful. */ @keyframes flairFlyGlow { 0% { opacity: 0; } 11% { opacity: calc(var(--f-peak, 0.9) * 0.28); } 21% { opacity: var(--f-peak, 0.9); } 27% { opacity: calc(var(--f-peak, 0.9) * 0.82); } 40% { opacity: calc(var(--f-peak, 0.9) * 0.17); } 52% { opacity: 0; } 100% { opacity: 0; } } /* fireflies' &g is the glow itself: the dark green of the field swelling up through yellow-green to the near-white an insect goes at its brightest, and back down. Only the gradient and its pace are overridden, so the shared scroll keyframes and the reduced-motion switch-off both still apply as they are. */ .flair-fireflies .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #4d7a24 0%, #7fbf2f 10%, #b6f542 20%, #e4ff9b 27%, #f7ffd6 31%, #d4ff6a 36%, #8fcc38 46%, #4d7a24 56% ); animation-duration: var(--fly-text-dur, 8s); animation-delay: var(--fly-text-delay, 0s); text-decoration-color: #c8ff5a; } /* --- aurora: curtains, and nothing else ---------------------------------------- The only flair here with no particles in it, and the point of it. Every other effect in this file is made of THINGS - sparks, drops, insects, bubbles, glyphs - so the one motion the set was missing is the one with no objects in it at all: something large and soft that changes shape without ever being a shape. Two layers, which is the whole flair. No fx layer, no nodes, nothing appended by a ticker. It is the cheapest effect in the file by a distance. ::before the near curtain - green through teal, brighter, drifting one way ::after the far curtain - teal through violet, dimmer, drifting the other WHY IT IS STILL A 90deg GRADIENT, given it is described as vertical curtains. Those are two different axes and it is worth being precise, because getting it wrong here is the bevel THE ONE RULE up at .flair warns about. A curtain HANGS vertically; what varies from one curtain to the next is horizontal position. So a sky full of them is a horizontal ramp through vertical bands - exactly linear-gradient(90deg, ...) - and there is no top-to-bottom component anywhere in it to put a light edge and a shadow edge on the row boundaries. The lean is a skew rather than a gradient angle, and that is the same decision twice over: an angled gradient would reintroduce the vertical component the rule forbids, and a baked-in angle cannot move. As a transform it is free, it stays on the compositor, and it can BREATHE - which is what turns two sliding sheets into something that undulates. THE INTERFERENCE IS THE EFFECT. Two banded sheets crossing in opposite directions at unrelated speeds produce bands that widen, narrow, brighten and part - motion no single animated layer can imitate, and none of it drawn. Give them the same period and it collapses into one sheet sliding. flairVars holds their ratio well away from 1 for that reason. */ .flair-aurora::before { /* far wider and taller than the row, so a drifting sheet never uncovers an edge and a skew never exposes a corner. Costs nothing: it is one gradient, and the part outside the row is clipped by .flair's overflow. */ inset: -70% -130%; /* THE WHOLE RIBBON IN ONE TILE, and the tile is a known width. Both halves of that matter and each fixes something. The whole ribbon, because a curtain that runs green to teal and stops is one colour with a gradient in it. A real aurora - and the &g wildcard right below, which had the variety this did not - travels green, spring, teal, cyan, azure, violet. One tile carries all of it, so any given stretch of row shows two or three hues rather than one. A known width, because that is what makes the drift LOOP. This was a repeating-linear-gradient with percentage stops, whose repeat length is some fraction of a box sized in percentages of the row - a number nothing here knows. The drift then translated by an unrelated pixel distance and snapped back at the end of every cycle. A background-size tile is an exact pixel length, the keyframes below travel exactly one of them, and the pattern at the end of a cycle is the pattern at the start. It is seamless by construction rather than by luck. Both ends of the tile are transparent so the tile joins itself invisibly - the dark sky between ribbons IS the join. */ background-image: linear-gradient( 90deg, transparent 0%, rgba(61, 255, 168, 0.24) 8%, rgba(124, 255, 212, 0.19) 15%, rgba(47, 230, 208, 0.22) 24%, rgba(49, 199, 255, 0.17) 34%, rgba(111, 155, 255, 0.14) 44%, rgba(139, 108, 255, 0.19) 54%, rgba(180, 108, 255, 0.13) 63%, rgba(76, 160, 255, 0.1) 72%, transparent 86%, transparent 100% ); background-size: var(--aur-near-band, 240px) 100%; background-repeat: repeat; opacity: var(--aur-near-peak, 0.8); animation: flairAurNear var(--aur-near-dur, 20s) linear var(--aur-near-delay, 0s) infinite, flairAurLean var(--aur-lean-dur, 15s) ease-in-out var(--aur-lean-delay, 0s) infinite alternate, flairAurBreatheNear var(--aur-breathe-dur, 12s) ease-in-out var(--aur-breathe-delay, 0s) infinite; } .flair-aurora::after { inset: -70% -130%; /* the far sheet: the same ribbon walked in the other order, so where the near curtain is green this one is violet and the pair never resolve into a single sequence of hues. Dimmer and on a narrower tile - it is further away. */ background-image: linear-gradient( 90deg, transparent 0%, rgba(180, 108, 255, 0.2) 9%, rgba(139, 108, 255, 0.15) 17%, rgba(76, 160, 255, 0.16) 28%, rgba(47, 230, 208, 0.13) 40%, rgba(61, 255, 168, 0.15) 50%, rgba(124, 255, 212, 0.1) 60%, transparent 78%, transparent 100% ); background-size: var(--aur-far-band, 170px) 100%; background-repeat: repeat; opacity: var(--aur-far-peak, 0.5); animation: flairAurFar var(--aur-far-dur, 13s) linear var(--aur-far-delay, 0s) infinite, /* leaning the OTHER way, and on the near sheet's clock: the two curtains are one sky, so they sway together even though they drift apart */ flairAurLeanBack var(--aur-lean-dur, 15s) ease-in-out var(--aur-lean-delay, 0s) infinite alternate; } /* The drift, on `translate` - so the skew below can own `transform` outright and neither has to know about the other. Opposite directions, which is what makes the two sheets cross rather than travel together. EXACTLY ONE TILE, which is the whole seam fix: after travelling one background-size the pattern is bit-for-bit where it began, so the loop point does not exist. Any other distance snaps, and it snaps once every cycle forever. */ @keyframes flairGlitchWash { 0%, 100% { opacity: calc(var(--gl-wash-peak, 0.75) * 0.55); } 38% { opacity: var(--gl-wash-peak, 0.75); } 62% { opacity: calc(var(--gl-wash-peak, 0.75) * 0.72); } } /* Off the row for most of the cycle, across it quickly, and gone again - a hold that slips now and then rather than a bar sweeping on a beat. The pauses are what make it read as a fault; a constant crossing would be a scanner. */ @keyframes flairGlitchTrack { 0%, 54% { transform: translateY(-115%); } 72% { transform: translateY(0%); } 86%, 100% { transform: translateY(115%); } } @keyframes flairAurNear { from { translate: 0 0; } to { translate: calc(var(--aur-near-band, 240px) * -1) 0; } } @keyframes flairAurFar { from { translate: 0 0; } to { translate: var(--aur-far-band, 170px) 0; } } /* the undulation. A curtain does not slide rigidly - it leans, and the lean travels along it. A slow alternating skew is that, at the cost of nothing. */ @keyframes flairAurLean { from { transform: skewX(calc(var(--aur-lean, 7deg) * -1)); } to { transform: skewX(var(--aur-lean, 7deg)); } } @keyframes flairAurLeanBack { from { transform: skewX(var(--aur-lean, 7deg)); } to { transform: skewX(calc(var(--aur-lean, 7deg) * -1)); } } /* an aurora brightens and fades over minutes, not seconds. Long, shallow, and never all the way out - the sky is still lit at the trough. */ @keyframes flairAurBreatheNear { 0%, 100% { opacity: calc(var(--aur-near-peak, 0.8) * 0.55); } 50% { opacity: var(--aur-near-peak, 0.8); } } /* &g in an aurora line: the ribbon running THROUGH the words rather than behind them - the same shared scroll keyframes every other flair's wildcard uses, with the sky's own colours and a pace to match. */ .flair-aurora .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #1fd98a 0%, #3dffa8 8%, #7cffd4 15%, #2fe6d0 23%, #31c7ff 32%, #6f9bff 40%, #8b6cff 48%, #b46cff 55%, #6f9bff 63%, #2fe6d0 72%, #1fd98a 82% ); animation-duration: var(--aur-text-dur, 11s); animation-delay: var(--aur-text-delay, 0s); text-decoration-color: #7cffd4; } /* --- bitcoin --------------------------------------------------------------------- A circuit board etched behind the row, dark until power runs through it, ending on a coin. See the note over circuitBoardMarkup in flair.js for how a board is drawn and why it is spans rather than svg. THIS IS THE ONE FLAIR WITH NO AMBIENT STATE. Every other effect here is always doing something - a wash breathing, particles drifting - and this one is a flat near-black field that shows nothing at all until a surge crosses it. That is the whole idea (a pod lit only by what is running through it) and it is also the one thing that could read as broken, so the surge is rolled per row and often: see CIRCUIT_CHANCE in app.js. A board nobody ever sees light up is just a dark bar - which is exactly what the /flair swatch was, and why it is carved out below. The palette is bitcoin's, and the core is deliberately not the logo orange: at 1px #f7931a reads brown on a black row. The core runs pale gold, the halo carries the orange, and the two together read as the orange the logo is. */ .flair-bitcoin { /* The core is deliberately SEMI-TRANSPARENT while the shadows around it are not, which is the whole reason a lit trace reads as a glowing wire rather than as a rule drawn on the text. Opacity animates the element as a whole, so this is the only way to hold the halo brighter than the line inside it. */ --cir-core: rgba(255, 212, 105, 0.55); --cir-glow: rgba(247, 179, 43, 0.75); --cir-halo: rgba(247, 147, 26, 0.4); } /* The board itself: a grey so near black that on the default theme it is barely a surface at all, which is what was asked for. It is a FLAT fill rather than a wash, so it has no direction to read as a bevel (see THE ONE RULE above) - and being opaque is what lets it be the board on a light theme too, where the row underneath is cream. */ .flair-bitcoin::before { inset: 0; /* Nearly black, and it has to stay ON the near side of black rather than at it: the plate is the only thing this flair shows between surges, so a row with the power off still has to read as a board sitting there rather than as a gap in the log. Two points of lift is what does that on the default theme, and it is also what makes the flair work on a light one, where the row underneath is cream. */ background: #08080a; } /* holds the traces, the pads and the coin. opacity:1 because the base .flairFx is 0 (that suits stars, where the layer IS the effect); every piece inside starts invisible on its own account instead. */ .flair-bitcoin > .flairFx { inset: 0; opacity: 1; } /* One run of trace. The 1px side comes from the markup rather than from here: which of the two is the hairline depends on whether the run is horizontal or vertical, and that is known where the run is generated. */ .flair-bitcoin .cirSeg { position: absolute; left: var(--c-x, 0%); top: var(--c-y, 6px); width: var(--c-w, 10%); height: var(--c-h, 1px); background: var(--cir-core); /* the bloom, as two static shadows rather than a filter: a filter re-rasterizes the layer, and this rasterizes once and then costs nothing for the rest of the row's life. Only the opacity ever animates. */ box-shadow: 0 0 4px var(--cir-glow), 0 0 12px var(--cir-halo); opacity: 0; } /* The coin, anchored right and sized to the row - so a five-line message carries a bigger seal than a one-line one, which is the behaviour asked for and comes free from a percentage height. The wrapper exists for the halo: box-shadow on the would draw a square glow around its border box, and a round wrapper of the same size gives the disc the round one it wants. It is also the element the surge animates, so the svg itself never has an animation on it at all. */ .flair-bitcoin .cirCoinWrap { position: absolute; right: 6px; top: 50%; /* nearly the row's own height: it is a seal stamped on the message, so it grows with a five-line one. Held under 100% so it never touches the rounded corners of the plate it sits on. */ height: 84%; aspect-ratio: 1; transform: translateY(-50%); border-radius: 50%; box-shadow: 0 0 6px var(--cir-glow), 0 0 16px var(--cir-halo); opacity: 0; } .flair-bitcoin .cirCoin { display: block; width: 100%; height: 100%; fill: var(--cir-core); } /* A SWATCH HAS TO SHOW SOMETHING. Every other flair is doing something between its one-shots, so its chip and its /flair preview show the effect just by existing. This one is a flat dark plate until a surge crosses it, and a surge crosses a given board about every five seconds - so the swatch a reader glances at while choosing was blank, which reads as the flair being broken rather than as it being subtle. That was the report. So in those two places only, the board is parked lit. It is not a reproduction of the flair's timing and is not meant to be: a swatch's job is to show what the thing looks like, and "invisible until pulsed" cannot be shown in a 96x24 box. The surge still runs over both - it is driven by Web Animations, which overrides these while it plays and hands the element back afterwards - so the preview gets the motion too, on top of a board you can actually see. Dimmer than a surge's peak on purpose, so the lit pulse still reads as brighter than the resting board underneath it. */ .flairChip.flair-bitcoin .cirSeg, .fmtPreviewLine.flair-bitcoin .cirSeg { opacity: 0.42; } .flairChip.flair-bitcoin .cirCoinWrap, .fmtPreviewLine.flair-bitcoin .cirCoinWrap { opacity: 0.5; } /* --- glitch ----------------------------------------------------------------------- A signal with a fault in it. Two pseudo-elements carry the idle - a chromatic wash and a tracking bar crossing the row - and the tear itself is a one-shot in the fx layer, built out of clones of the row's own content (see glitchTear in app.js). The palette is chromatic aberration: the cyan and magenta a picture separates into when the channels stop lining up. It is the one thing that says "signal" without drawing anything, which matters here because between tears there is nothing else to look at. */ .flair-glitch { --gl-cyan: #37e8ff; --gl-magenta: #ff3ba7; } /* the wash: the two channels pulling apart across the row and easing back together. Horizontal, per THE ONE RULE above. */ .flair-glitch::before { inset: 0; background: linear-gradient(90deg, rgba(55, 232, 255, 0.16), rgba(255, 59, 167, 0.07) 46%, rgba(55, 232, 255, 0.13) 100%); opacity: var(--gl-wash-peak, 0.75); animation: flairGlitchWash var(--gl-wash-dur, 7s) ease-in-out var(--gl-wash-delay, 0s) infinite; } /* The tracking bar: a bright line crossing the row, the way a picture that has lost its hold rolls. This is a VERTICAL gradient, which the rule above forbids, and it is allowed here for the reason the rule itself names: it is not a ramp, it MOVES. The two failures the rule exists to prevent are a light edge along the top of every row and a dark one along the bottom, and a thin band that is transparent at both ends of its own box and spends most of its cycle off the row entirely produces neither. Travelling by 100% of its own height rather than of the row's is what makes it independent of how tall the row is: the element IS the row, so one of its heights is one row either way, on a one-line message and on a five-line one. */ .flair-glitch::after { inset: 0; background: linear-gradient( 180deg, transparent 44%, rgba(55, 232, 255, 0.1) 47%, rgba(255, 255, 255, 0.16) 50%, rgba(255, 59, 167, 0.1) 53%, transparent 56% ); animation: flairGlitchTrack var(--gl-track-dur, 9s) linear var(--gl-track-delay, 0s) infinite; } /* --- the tear ------------------------------------------------------------------- Each band is a whole copy of the row, clipped to one horizontal slice of it. The clip is written once by the markup and never animated - only the transform moves, so a band lives its whole short life on the compositor. Absolutely positioned to sit exactly over the original, which is invisible for as long as these exist. The padding comes from the row itself at build time rather than from here: these have to line up to the pixel, and .line.flair is free to change its padding without this file being told. */ /* The layer the tear is built in. All three declarations are load-bearing and two of them are the base .flairFx being turned back off. It is `opacity: 0` with no geometry of its own, which suits stars - where the layer IS the streak and the js animates the layer itself - and every flair that puts CONTENT in the layer has to undo both. Missing them, the bands were laid out in a 0x0 box at zero opacity: present in the dom, correct in every other respect, and drawing nothing. visibility is the third, and it is this flair's own: the row is held hidden while the bands stand in for it, and visibility - unlike opacity - is a property a descendant can take back. */ .flair-glitch > .flairFx { inset: 0; opacity: 1; visibility: visible; } .flairFx .tear { position: absolute; inset: 0; pointer-events: none; } .flairFx .tearBand { position: absolute; inset: 0; /* the channels separating, which is what a torn band looks like in a picture that has lost registration. Static, so it costs a rasterisation and not a frame. */ text-shadow: 1.5px 0 rgba(255, 59, 167, 0.55), -1.5px 0 rgba(55, 232, 255, 0.55); } /* the &g wildcard, in the signal's own two colours */ .flair-glitch .fmtRainbow { background-image: repeating-linear-gradient(90deg, #37e8ff 0%, #b9f4ff 16%, #ff3ba7 34%, #ffd0e8 52%, #37e8ff 74%, #7de6ff 88%, #37e8ff 100%); animation-duration: var(--gl-text-dur, 8s); animation-delay: var(--gl-text-delay, 0s); text-decoration-color: #ff3ba7; } /* the &g wildcard, in the board's own gold */ .flair-bitcoin .fmtRainbow { background-image: repeating-linear-gradient(90deg, #b8791a 0%, #ffd469 22%, #fff0c2 38%, #ffb63d 58%, #a5670f 78%, #b8791a 100%); animation-duration: var(--cir-text-dur, 9s); animation-delay: var(--cir-text-delay, 0s); text-decoration-color: #ffd469; } /* --- bubbles: glub ------------------------------------------------------------ The one the client is named after, built on fire's machinery and reading as its opposite. See the note over bubbleMarkup in flair.js for why an ember and a bubble come apart at a glance; the short version is that a bubble is a ring with a highlight, and it GROWS on the way up. Three layers: ::before the tank - a slow wash of aquarium light ::after the fizz - fine carbonation, one cloned field, far behind .flairFx the bubbles, one element each The rare pop is a one-shot fired by the shared ticker (see bubblePop in app.js), not a CSS loop: a loop pops on a beat and always in the same place. */ .flair-bubbles::before { inset: 0; /* HORIZONTAL - see THE ONE RULE at .flair above. This was a vertical surface-lit gradient first, which is precisely the bevel that note describes. Two backgrounds in one layer, as fireflies does: the flat floor under the ramp keeps the far end of a long row from going black, and being flat it shades in neither direction. */ background: linear-gradient(90deg, rgba(79, 200, 216, 0.22), rgba(110, 232, 234, 0.08) 62%, transparent), linear-gradient(rgba(95, 224, 216, 0.06), rgba(95, 224, 216, 0.06)); opacity: var(--bub-wash-peak, 0.66); animation: flairBubWash var(--bub-wash-dur, 10s) ease-in-out var(--bub-wash-delay, 0s) infinite; } /* light moving on water: a long, shallow swell rather than a pulse. Nothing in a tank flashes. */ @keyframes flairBubWash { 0%, 100% { opacity: calc(var(--bub-wash-peak, 0.66) * 0.62); } 50% { opacity: var(--bub-wash-peak, 0.66); } } /* the fizz: specks a pixel across, rising fast and far behind the bubbles. A cloned box-shadow field is right here and wrong for the bubbles themselves - at this size nobody can see that they share a cadence, and the whole field is one layer. */ .flair-bubbles::after { left: var(--fizz-left, 20px); top: 100%; width: 1px; height: 1px; border-radius: 50%; background: rgba(168, 247, 240, 0.75); box-shadow: var(--fizz-field, 44px 0 #7ef0e6, 104px 0 #5fe0d8, 166px 0 #a8f7f0, 232px 0 #4fc8d8); opacity: 0.55; animation: flairFizzRise var(--fizz-dur, 4.6s) linear var(--fizz-delay, 0s) infinite; } @keyframes flairFizzRise { 0% { translate: 0 0; opacity: 0; } 14% { opacity: 0.5; } 70% { translate: var(--fizz-x2, 4px) -1.6em; opacity: 0.28; } 100% { translate: var(--fizz-x3, 7px) -2.4em; opacity: 0; } } /* the bubble layer is just a container; every bubble inside it is its own element */ .flair-bubbles > .flairFx { inset: 0; opacity: 1; overflow: hidden; } /* One bubble: a hairline ring with almost nothing inside it. The border is 1px at every size on purpose - a bubble is a film, and film has no thickness to scale. That is also why the swell is a `scale` on the BOX rather than an animated width: scaling the element would thicken its own outline as it grew, and a bubble whose edge fattens on the way up reads as a balloon. Barely-there fill: enough to separate it from the row behind, not enough to hide the text it passes over. currentColor drives ring and fill together, so one custom property tints the whole thing. */ .flair-bubbles .bubble { position: absolute; bottom: -3px; left: var(--b-x, 30%); width: var(--b-size, 7px); height: var(--b-size, 7px); box-sizing: border-box; border-radius: 50%; color: var(--b-tint, #7ef0e6); border: 1px solid currentColor; background: radial-gradient(circle at 32% 30%, rgba(255, 255, 255, 0.1), rgba(255, 255, 255, 0.02) 55%, transparent 72%); opacity: 0; /* THREE properties, three clocks. translate is the rise, transform is the sway, scale is the swell - separate longhands, so none of them clobbers another and all three stay on the compositor. Fire needs two of these; the third axis is free. */ animation: bubbleRise var(--b-rise, 6s) linear var(--b-rise-delay, 0s) infinite, bubbleSway var(--b-sway, 3s) ease-in-out var(--b-sway-delay, 0s) infinite alternate, bubbleSwell var(--b-grow-dur, 6s) linear var(--b-rise-delay, 0s) infinite; } /* the specular highlight - the single detail that stops a ring reading as a puff of smoke. Up and to the left, always, because a tank is lit from above: a highlight that wandered per bubble would read as several light sources in one aquarium. */ .flair-bubbles .bubble::before { content: ""; position: absolute; left: 18%; top: 14%; width: 34%; height: 34%; border-radius: 50%; background: rgba(255, 255, 255, 0.85); } /* the long invisible tail is deliberate, as fire's is: with every bubble on its own period those dead stretches drift past each other, so the stream clusters and lulls instead of running evenly. */ @keyframes bubbleRise { 0% { translate: 0 0; opacity: 0; } 8% { opacity: var(--b-peak, 0.8); } 62% { opacity: calc(var(--b-peak, 0.8) * 0.72); } 78% { translate: 0 calc(var(--b-lift, 2.2em) * -1); opacity: 0; } 100% { translate: 0 calc(var(--b-lift, 2.2em) * -1); opacity: 0; } } /* bubbles that never reach the surface - the small ones caught in the current */ .flair-bubbles .bubble.bubbleShort { animation-name: bubbleRiseShort, bubbleSway, bubbleSwell; } @keyframes bubbleRiseShort { 0% { translate: 0 0; opacity: 0; } 10% { opacity: calc(var(--b-peak, 0.8) * 0.85); } 38% { opacity: calc(var(--b-peak, 0.8) * 0.4); } 50% { translate: 0 calc(var(--b-lift, 2.2em) * -0.45); opacity: 0; } 100% { translate: 0 calc(var(--b-lift, 2.2em) * -0.45); opacity: 0; } } /* wider and slower than an ember's sway: an ember is pushed by draught, a bubble by water */ @keyframes bubbleSway { from { transform: translate3d(calc(var(--b-amp, 12px) * -1), 0, 0); } to { transform: translate3d(var(--b-amp, 12px), 0, 0); } } /* pressure drops as it climbs, so it swells - and it is back at its starting size for the next cycle, which is invisible because the bubble is transparent by then */ @keyframes bubbleSwell { 0% { scale: 1; } 78% { scale: var(--b-grow, 1.18); } 100% { scale: var(--b-grow, 1.18); } } /* the pop: appended by the ticker, driven by the Web Animations API, and removed when it finishes - so between pops this costs nothing and leaves nothing behind. */ .flair-bubbles .bubblePop { position: absolute; left: var(--p-x, 50%); top: var(--p-y, 25%); width: var(--p-size, 8px); height: var(--p-size, 8px); margin: calc(var(--p-size, 8px) / -2) 0 0 calc(var(--p-size, 8px) / -2); box-sizing: border-box; border-radius: 50%; color: var(--p-tint, #a8f7f0); border: 1px solid currentColor; opacity: 0; pointer-events: none; } /* the ring the burst leaves - a hairline expanding out of where the bubble was. Sized off the pop rather than fixed, so a big bubble leaves a big ring. */ .flair-bubbles .bubblePop .popRing { position: absolute; left: 50%; top: 50%; width: 100%; height: 100%; margin: -50% 0 0 -50%; border-radius: 50%; border: 1px solid currentColor; opacity: 0; } /* &g in a bubbles line: aquarium teal through pale cyan and back, at a slow watery pace - the same shared scroll keyframes every other flair's wildcard uses, with only the gradient and its period swapped. */ .flair-bubbles .fmtRainbow { background-image: repeating-linear-gradient( 90deg, #2f9fb5 0%, #4fc8d8 10%, #7ef0e6 20%, #c9fdfa 28%, #eaffff 32%, #a8f7f0 38%, #5fe0d8 48%, #2f9fb5 58% ); animation-duration: var(--bub-text-dur, 9s); animation-delay: var(--bub-text-delay, 0s); text-decoration-color: #7ef0e6; } /* stars: two dot fields twinkling out of phase. Every value that shapes the sky - the field itself, its position, its period, its phase - comes from a custom property randomized per line in flair.js, so no two messages share a pattern and nothing beats in unison. The fallbacks here keep a var-less element (e.g. the /flair preview chip) looking right. */ .flair-stars::before { left: var(--star-a-left, 8px); top: var(--star-a-top, 32%); width: 2px; height: 2px; border-radius: 50%; background: #ffffff; box-shadow: var( --star-a-field, 34px -5px #cfe6ff, 79px 9px #ffffff, 124px -11px #a8ccff, 181px 5px #ffffff, 238px -8px #dbe9ff, 296px 7px #ffffff, 351px -4px #bcd8ff ); animation: flairTwinkleA var(--star-a-dur, 2.6s) ease-in-out var(--star-a-delay, 0s) infinite; } .flair-stars::after { left: var(--star-b-left, 20px); top: var(--star-b-top, 62%); width: 2px; height: 2px; border-radius: 50%; background: #e9f2ff; box-shadow: var( --star-b-field, 47px -12px #ffffff, 99px 6px #b9d5ff, 152px -7px #ffffff, 214px 10px #d6e7ff, 271px -10px #ffffff ); animation: flairTwinkleB var(--star-b-dur, 3.4s) ease-in-out var(--star-b-delay, 0s) infinite; } /* Each field fades through a couple of uneven peaks, blinks fully out, and is MOVED while invisible (the --star-*-d* offsets) so it returns somewhere new - the "twinkle out here, twinkle in over there" effect. The offset is held constant to 99% and snapped back at 100% while opacity is still 0, so the loop restarts invisibly instead of sliding the field back across the row. */ @keyframes flairTwinkleA { 0% { opacity: 0; transform: translate3d(0, 0, 0); } 9% { opacity: 1; } 28% { opacity: 0.18; } 44% { opacity: 0.85; } 49% { opacity: 0; transform: translate3d(0, 0, 0); } 51% { opacity: 0; transform: translate3d(var(--star-a-dx, 7px), var(--star-a-dy, -5px), 0); } 63% { opacity: 1; } 81% { opacity: 0.2; } 92% { opacity: 0.7; } 99% { opacity: 0; transform: translate3d(var(--star-a-dx, 7px), var(--star-a-dy, -5px), 0); } 100% { opacity: 0; transform: translate3d(0, 0, 0); } } @keyframes flairTwinkleB { 0% { opacity: 0; transform: translate3d(0, 0, 0); } 14% { opacity: 0.9; } 33% { opacity: 0.15; } 41% { opacity: 1; } 47% { opacity: 0; transform: translate3d(0, 0, 0); } 49% { opacity: 0; transform: translate3d(var(--star-b-dx, -9px), var(--star-b-dy, 6px), 0); } 58% { opacity: 0.75; } 72% { opacity: 1; } 88% { opacity: 0.22; } 99% { opacity: 0; transform: translate3d(var(--star-b-dx, -9px), var(--star-b-dy, 6px), 0); } 100% { opacity: 0; transform: translate3d(0, 0, 0); } } /* rain: the first flair that moves DOWNWARD. The overcast wash fades horizontally like the others - the motion is what carries the direction here, and a vertical wash would bevel every row - while individual drops fall through on their own timings. Each drop is also its own ripple: at the end of its fall it flattens and spreads from its foot, so every splash belongs to a real drop instead of being a decorative ring on the edge. Rare squalls come from the ticker in app.js. */ .flair-rain::before { inset: 0; background: linear-gradient(90deg, rgba(120, 160, 195, 0.22), rgba(90, 130, 165, 0.07) 60%, transparent); animation: flairRainHaze var(--rain-haze-dur, 7s) ease-in-out var(--rain-haze-delay, 0s) infinite; } /* `container-type: size` turns the layer into a query container, so a drop can fall `100cqh` - the row's own height - and land on the bottom edge whether the message is one line or wrapped to four. (Safe here: the stylesheet already requires color-mix(), which shipped later than container query units.) */ .flair-rain > .flairFx { inset: 0; opacity: 1; container-type: size; } /* a drop is a thin streak, TILTED to match the direction it's actually travelling - a vertical dash drifting sideways reads as sliding rather than falling. The fall itself is eased IN, so it accelerates the way gravity does instead of gliding at a constant speed. */ .flair-rain .drop { position: absolute; top: 0; left: var(--d-x, 40%); width: 1.4px; height: var(--d-len, 7px); border-radius: 1px; background: linear-gradient(180deg, transparent, var(--d-tint, #cfe4f5)); opacity: 0; rotate: var(--d-tilt, 7deg); animation: rainFall var(--d-fall, 0.5s) cubic-bezier(0.36, 0, 0.78, 0.34) var(--d-delay, 0s) infinite; } /* the ripple: the drop's OWN pseudo-element, so it costs no extra node and lands exactly where its drop does (it rides the same translate). Counter-rotated so the ring lies flat on the ground even though the streak above it is tilted, and timed to bloom at 80% - the instant the fall keyframe puts the drop on the bottom edge. */ .flair-rain .drop::after { content: ""; position: absolute; left: 50%; /* centred ON the foot (half the ellipse's own height), so the ring expands symmetrically around the impact point rather than hanging below it */ bottom: calc(var(--d-ring, 9px) * -0.18); width: var(--d-ring, 9px); height: calc(var(--d-ring, 9px) * 0.36); margin-left: calc(var(--d-ring, 9px) / -2); border: 1px solid var(--d-tint, #cfe4f5); border-radius: 50%; rotate: calc(var(--d-tilt, 7deg) * -1); opacity: 0; animation: rainRipple var(--d-fall, 0.5s) ease-out var(--d-delay, 0s) infinite; } @keyframes rainFall { 0% { translate: 0 -12px; opacity: 0; } 10% { opacity: var(--d-op, 0.8); } /* the translate moves the streak's TOP, so its own length is subtracted to put its FOOT on the ground - otherwise the ring lands below the row and clips. */ 80% { translate: var(--d-lean, 3px) calc(100cqh - var(--d-len, 7px) - 6px); opacity: var(--d-op, 0.8); } /* the streak dies on impact so what you see next is the ring, not a dash sitting on the floor */ 87% { translate: var(--d-lean, 3px) calc(100cqh - var(--d-len, 7px) - 6px); opacity: 0; } 100% { translate: var(--d-lean, 3px) calc(100cqh - var(--d-len, 7px) - 6px); opacity: 0; } } @keyframes rainRipple { 0%, 80% { transform: scale(0.2); opacity: 0; } 85% { transform: scale(0.55); opacity: 0.9; } 100% { transform: scale(2.1); opacity: 0; } } @keyframes flairRainHaze { 0%, 100% { opacity: calc(var(--rain-haze-peak, 0.8) * 0.6); } 50% { opacity: var(--rain-haze-peak, 0.8); } } /* plume: violet exhaust lit from the LEFT and dying to black toward the right, the same direction the other flairs fade and the same direction the eye already reads. Where they're made of particles you could count, this one is made of volume - a handful of very large, very soft blobs drifting past each other behind the text. Two things carry it, and neither is the blobs. `mix-blend-mode: screen` on the puffs: where two overlap their light ADDS, which is what a camera does when it can't hold the highlights - lit evenly, but wherever the volume is densest the value clips and blows out toward white. Painting those hot spots directly would mean deciding up front where they go; letting overlap decide means they move as the plume moves and land somewhere different on every line, for free. `isolation` keeps that blending among the puffs - it must not reach the text sitting above them. And the EDGE BURN: the light pools where the plume meets the row's top and bottom and thins through the middle, rather than washing the row evenly. That's the detail that makes it read as a lit volume seen edge-on instead of a colored rectangle. Bright at BOTH edges is also why it doesn't bevel - a bevel is light at one edge and dark at the other, which is the trap that sent fire and rain horizontal in the first place. Symmetry reads as glow. */ .flair-plume::before { inset: 0; background: linear-gradient(90deg, rgba(168, 85, 247, 0.3), rgba(124, 58, 237, 0.1) 20%, transparent 46%); transform-origin: left center; animation: flairPlumeWash var(--plume-wash-dur, 9s) ease-in-out var(--plume-wash-delay, 0s) infinite, flairPlumeReach var(--plume-reach-dur, 22s) ease-in-out var(--plume-reach-delay, 0s) infinite; } /* the edge burn, masked by the same left-to-right falloff as everything else so it dies out with the plume rather than ringing the whole row. */ .flair-plume::after { inset: 0; /* The bands need thickness to survive antialiasing on a 22px row - a stop at exactly 0% puts the highlight on one pixel and it vanishes - but only just. Reaching further in leaves no dim middle, and the middle is what the text is read against: the falloff from bright edge to dark centre happens inside the first and last EIGHTH, so the middle 60% of the row stays genuinely dark and the bands stay the brightest thing in it. Defined rather than fused. */ background: linear-gradient( 180deg, rgba(233, 213, 255, 0.3) 0%, rgba(240, 224, 255, 0.44) 5%, rgba(196, 148, 250, 0.2) 12%, rgba(139, 92, 246, 0.05) 22%, rgba(124, 58, 237, 0.03) 50%, rgba(139, 92, 246, 0.05) 78%, rgba(196, 148, 250, 0.21) 88%, rgba(240, 224, 255, 0.43) 95%, rgba(233, 213, 255, 0.28) 100% ); -webkit-mask-image: linear-gradient(90deg, #000 0%, rgba(0, 0, 0, 0.34) 19%, transparent 47%); mask-image: linear-gradient(90deg, #000 0%, rgba(0, 0, 0, 0.34) 19%, transparent 47%); /* scaled from the lit edge, so "reach" grows and shrinks the plume's LENGTH without touching the height of the bands. Done with a transform rather than an animated mask-size: the mask would have to be re-rasterized every frame, where a scale is handed straight to the compositor. */ transform-origin: left center; animation: flairPlumeLamp var(--plume-lamp-dur, 13s) ease-in-out var(--plume-lamp-delay, 0s) infinite alternate, flairPlumeReach var(--plume-reach-dur, 22s) ease-in-out var(--plume-reach-delay, 0s) infinite; } .flair-plume > .flairFx { inset: 0; opacity: 1; isolation: isolate; /* confine the screen blending to the puffs */ /* The fog builds up instead of arriving. `display: none` cancels animations on a parked row, so un-parking restarts this one from the top for free - no JS, no class to add and remove. Fading the WRAPPER rather than the puffs is what makes it compose: group opacity multiplies with whatever each puff's own density animation is doing, so they keep churning while the layer as a whole comes up. The implicit `to` resolves to the element's own opacity, which is how the preview chip's damped 0.5 keeps working without restating it. */ animation: flairPlumeWake 900ms ease-out; /* ...and the same in reverse when the slot is handed to a newer row. `display` is what actually stops the puffs animating, so it has to be the LAST thing to change - `allow-discrete` holds it at block until the opacity transition has finished, which is the difference between the fog thinning out and it being switched off. The puffs keep churning through those 700ms, which is the point: a layer that freezes and then vanishes reads as a glitch, not a fade. Out is quicker than in on purpose - arriving is the part worth watching. */ transition: opacity 700ms ease, display 700ms allow-discrete; /* deliberately NOT masked, unlike the wash and the edge burn. A mask here would also hide the motes, which exist precisely to be seen out in the dark before they reach the glow - they'd fade in halfway across instead of arriving from nowhere. The puffs don't need it either: they're radial gradients that already fade to nothing inside their own box, and they're sized and positioned so the furthest one stops around 40% of the row on its own. */ } /* a puff is sized to fill a message row, so in the ~40px preview chip a single one covers everything and the label disappears into its hot core. Damping the layer there makes the swatch READ like a row rather than being one, which is what a preview is for. */ .flairChip.flair-plume > .flairFx { opacity: 0.5; } /* one puff. Three animations compose: translate (drift), transform (swell) and opacity (density) - each on its own unrelated period and phase, all eased and alternating, so the field churns instead of looping and never shows a corner. */ .flair-plume .puff { position: absolute; left: var(--p-x, 40%); top: var(--p-y, 50%); width: var(--p-size, 110px); height: var(--p-size, 110px); margin: calc(var(--p-size, 110px) / -2) 0 0 calc(var(--p-size, 110px) / -2); border-radius: 50%; background: radial-gradient( circle, var(--p-core, #f3e8ff) 0%, var(--p-core, #f3e8ff) 5%, var(--p-tint, #a855f7) 26%, color-mix(in srgb, var(--p-tint, #a855f7) 45%, transparent) 56%, transparent 74% ); /* blur is static - only opacity/transform/translate animate, so the expensive part is rasterized once and the motion stays on the compositor */ filter: blur(var(--p-blur, 12px)); mix-blend-mode: screen; opacity: var(--p-op, 0.7); animation: plumeDrift var(--p-drift-dur, 11s) ease-in-out var(--p-drift-delay, 0s) infinite alternate, plumeSwell var(--p-swell-dur, 7s) ease-in-out var(--p-swell-delay, 0s) infinite alternate, plumeBreathe var(--p-breathe-dur, 8s) ease-in-out var(--p-breathe-delay, 0s) infinite alternate; } @keyframes plumeDrift { from { translate: 0 0; } to { translate: var(--p-dx, 18px) var(--p-dy, 6px); } } @keyframes plumeSwell { from { transform: scale(1); } to { transform: scale(var(--p-swell, 1.28)); } } @keyframes plumeBreathe { from { opacity: calc(var(--p-op, 0.7) * 0.62); } to { opacity: var(--p-op, 0.7); } } @keyframes flairPlumeWake { from { opacity: 0; } } @keyframes flairPlumeWash { 0%, 100% { opacity: calc(var(--plume-wash-peak, 0.85) * 0.55); } 50% { opacity: var(--plume-wash-peak, 0.85); } } /* the edge burn breathes rather than travelling: the plume's brightness rises and falls, but the direction it comes from is fixed - that's what makes a row read as lit from one side rather than as something sweeping past. The swing is wide (a plume at 45% is genuinely dim) because an even glow reads as a painted shape; uneven brightness is most of what makes it read as burning. */ @keyframes flairPlumeLamp { from { opacity: var(--plume-lamp-low, 0.45); } to { opacity: var(--plume-lamp-peak, 0.9); } } /* the plume reaching out and drawing back in. The profile is deliberately UNEVEN, the same way fire's huff is: a couple of modest breaths and then, once per cycle, a long throw far past the resting range. An even oscillation between two values reads as a mechanism; occasional large excursions read as something burning. Because the period (16-30s) and the phase are both randomized per line, and the throw sits partway through the cycle, a screenful of rows throws at scattered moments rather than together - which is what makes it feel intermittent rather than scheduled. It's drawn back in slowly: a plume that snaps back reads as a glitch. */ @keyframes flairPlumeReach { 0%, 16% { transform: scaleX(var(--plume-reach-min, 0.72)); } 26% { transform: scaleX(var(--plume-reach-max, 1.15)); } 38% { transform: scaleX(var(--plume-reach-min, 0.72)); } 48% { transform: scaleX(calc(var(--plume-reach-max, 1.15) * 0.88)); } /* the throw: up fast, then a two-stage fall - most of the distance shed quickly, the last of it drifting back. Held briefly on purpose. Stretched over a third of the cycle it stops being an event and becomes the resting state. */ 58% { transform: scaleX(var(--plume-reach-far, 2.6)); } 68% { transform: scaleX(var(--plume-reach-max, 1.15)); } 82%, 100% { transform: scaleX(var(--plume-reach-min, 0.72)); } } /* motes: sparse specks that fade up out in the dark - past where the plume's glow has already tapered off - and drift LEFT into it, dying as they reach the bright edge. Arriving from the dark and never coming out the other side is what makes the plume read as drawing them IN rather than shedding them. `left` is animated rather than a transform because the travel is expressed in percentages of a row whose width isn't known here, and this is two or three 1.4px dots on a slow period - not a particle system. The vertical drift rides `translate` so the path arcs instead of tracking a ruled line. */ .flair-plume .mote { position: absolute; top: var(--m-y, 50%); left: var(--m-from, 90%); width: var(--m-size, 1.4px); height: var(--m-size, 1.4px); border-radius: 50%; background: var(--m-tint, #e9d5ff); box-shadow: 0 0 4px var(--m-tint, #e9d5ff); opacity: 0; animation: plumeMote var(--m-dur, 7s) linear var(--m-delay, 0s) infinite; } @keyframes plumeMote { 0% { left: var(--m-from, 90%); translate: 0 0; opacity: 0; } /* fades up in the dark rather than arriving at full strength - a speck that pops into existence reads as a rendering glitch, not a particle */ 18% { opacity: var(--m-op, 0.6); } /* gone before it lands: swallowed by the glow, not sitting on top of it */ 82% { opacity: var(--m-op, 0.6); } 100% { left: var(--m-to, 12%); translate: 0 var(--m-rise, 3px); opacity: 0; } } /* the plume surging: injected, swelled, removed (plumeSurge in app.js). It blends like the puffs, so while it passes it gives them something far brighter to overlap and the row briefly blows out. */ .flair-plume > .flairFx .surge { position: absolute; left: var(--ps-x, 50%); top: 50%; width: 200px; height: 200px; margin: -100px 0 0 -100px; border-radius: 50%; background: radial-gradient( circle, var(--ps-core, #f3e8ff) 0%, var(--ps-tint, #a855f7) 30%, color-mix(in srgb, var(--ps-tint, #a855f7) 38%, transparent) 55%, transparent 74% ); filter: blur(16px); mix-blend-mode: screen; opacity: 0; } /* the squall sheet: injected, swept across, removed (see rainGust in app.js) */ .flair-rain > .flairFx .gust { position: absolute; top: -20%; bottom: -20%; width: 45%; background: linear-gradient(90deg, transparent, rgba(198, 222, 240, 0.22) 45%, rgba(224, 238, 250, 0.3) 60%, transparent); rotate: var(--g-tilt, 12deg); opacity: 0; } /* the shooting star: a one-shot streak fired by a shared ticker (see app.js) at random intervals, from a random spot, so it stays a blink-and-you-miss-it event rather than a loop. Parked invisible; the ticker drives it with a short transform+opacity animation the compositor owns. */ /* the one-shot layer every fx flair shares; each flair styles its own inside it */ .flairFx { position: absolute; pointer-events: none; opacity: 0; z-index: -1; } /* stars: the streak itself IS the layer */ .flair-stars > .flairFx { left: 0; top: 0; width: 44px; height: 2px; border-radius: 2px; background: linear-gradient(90deg, rgba(255, 255, 255, 0) 0%, rgba(214, 234, 255, 0.35) 45%, #ffffff 100%); } /* lightning: the layer spans the row and holds a generated bolt + its whiteout. Empty until a strike fires, emptied again when it ends. opacity:1 is load-bearing and was missing. The base .flairFx is opacity:0 - which suits stars, where the layer IS the streak and the js animates the layer itself - and every other flair that puts CONTENT in the layer turns it back on. Lightning did not, so the bolt was built, animated and removed inside a fully transparent box: it fired exactly as designed and could not be seen. That, not the rate, is why the flair looked like it had no lightning in it, and why rain's borrowed bolt was visible when the lightning flair's own never was - rain's layer is opaque. */ .flair-lightning > .flairFx { inset: 0; opacity: 1; } .flairFx .strike { position: absolute; inset: 0; opacity: 0; } .flairFx .boltFlash { position: absolute; inset: 0; background: radial-gradient(150% 220% at 50% 50%, rgba(240, 248, 255, 0.92), rgba(160, 205, 255, 0.4) 45%, transparent 78%); } .flairFx .boltSvg { position: absolute; inset: 0; display: block; } /* wide soft stroke under a thin bright core - the cheap way to fake a glow without a filter (which would cost a repaint every frame of the strike) */ .boltGlow { fill: none; stroke: rgba(150, 200, 255, 0.85); stroke-width: 3.4; stroke-linejoin: round; stroke-linecap: round; } .boltCore { fill: none; stroke: #ffffff; stroke-width: 1.2; stroke-linejoin: round; stroke-linecap: round; } /* --- the flair budget -------------------------------------------------------- A flaired row is not free: plume alone carries two animated pseudo-elements plus a handful of blurred, screen-blended blobs and their motes, each with its own animations. A screenful is fine; a flood of them on a phone is not. So only a few rows animate at once (see FLAIR_BUDGET in app.js) and the rest are parked here - exactly the same resting state reduced-motion readers get, and for the same reason: keep the tint so the row still reads as flaired, drop everything that costs a frame. `display: none` on the fx layer rather than a paused animation, because paused blobs still cost a composited, blended layer each. The rules are spelled out twice, once here and once in the reduced-motion block below. CSS has no way to say "match this class OR this media condition", and the media query is worth keeping as a guarantee that doesn't depend on the budget pass having run. */ /* plume is carved out here rather than overridden below, because `animation: none` would zero animation-NAME, and a later rule that only sets play-state can't bring the name back. */ .flairQuiet:not(.flair-plume)::before, .flairQuiet:not(.flair-plume)::after { animation: none; } /* ...plume's two ambient layers PAUSE instead of stopping. Everything else is uncapped, so it only ever goes quiet well off screen and is running again long before you scroll to it. Plume is capped at 3, so a row wakes when a SLOT frees up - which happens in front of you, mid-scroll. Stopping and restarting can't be made seamless here: every plume row carries a large NEGATIVE animation-delay to de-sync it from its neighbours, so re-applying the animation drops it at that phase offset rather than at the first keyframe. There is no parked value that matches, because the value it wakes to is a different point on the cycle for every row. Pausing sidesteps the whole problem - the row resumes from exactly where it froze, so there is nothing to jump from, in either direction. This is affordable for precisely the reason the fx layer below isn't: these are two plain gradients whose paused animations cost a static composited layer and no per-frame work, where the puffs are blurred and blended and cost a real compositing pass each even standing still. */ .flair-plume.flairQuiet::before, .flair-plume.flairQuiet::after { animation-play-state: paused; } .flairQuiet > .flairFx { display: none; } /* plume alone fades on the way out rather than cutting. The other four drop their fx layer from off screen, where nobody is watching it go; plume's cap means a row loses its slot in plain sight, the moment a newer one takes it. Pairs with the transition on the layer itself - this is only the target it eases toward. */ .flair-plume.flairQuiet > .flairFx { opacity: 0; } .flair-fire.flairQuiet::after, .flair-lightning.flairQuiet::after { opacity: 0; } /* a quiet neon keeps the glass AND its filament lit at full - the whole flair is the tube, so parking either at anything less would look like a fault rather than a stilled effect. The failing segment lives in the fx layer, which the shared rule above already hides: a frozen gap is a broken sign, not a quiet one. */ .flair-neon.flairQuiet::before, .flair-neon.flairQuiet::after { opacity: 1; } .flair-lightning.flairQuiet .fmtRainbow, .flair-fire.flairQuiet .fmtRainbow, .flair-rain.flairQuiet .fmtRainbow, .flair-neon.flairQuiet .fmtRainbow, .flair-plume.flairQuiet .fmtRainbow { animation: none; filter: brightness(1); } /* deliberately no parked opacity/transform for plume here: it freezes on its own animated values (see the pause above), and pinning them would reintroduce exactly the jump that pausing removes. The reduced-motion block still parks it, because there the animation really is off. */ .flair-rain.flairQuiet::after { opacity: 0.4; } .flair-stars.flairQuiet::before, .flair-stars.flairQuiet::after { opacity: 0.55; transform: none; } /* a quiet matrix keeps its phosphor wash - that is the tint that says "flaired" - and loses the code, which the shared .flairQuiet rule above already hides with the rest of the fx layer. Parked bright rather than mid-breath. */ .flair-matrix.flairQuiet::before, .flair-matrix.flairQuiet::after { opacity: var(--mtx-wash-peak, 0.7); } /* a quiet sonar keeps its scope lit - the glow is the tint that says "flaired" here - and loses the rings, which the shared .flairQuiet rule above already hides with the rest of the fx layer. Parked lit rather than mid-breath. Any contact being tracked goes with the rings, and app.js drops the whole sequence when it finds the wavefronts it was timing against have stopped. */ .flair-sonar.flairQuiet::before { opacity: var(--son-wash-peak, 0.75); } /* a quiet fireflies keeps the warm dark and loses the insects, which the shared .flairQuiet rule above already hides with the rest of the fx layer. Parked lit rather than mid-breath - and this is the flair that most needs it, since on a live row the wash is often the only thing lit anyway. */ .flair-fireflies.flairQuiet::before { opacity: var(--fly-wash-peak, 0.6); } @media (prefers-reduced-motion: reduce) { /* keep each flair's ambient tint (so a flaired line still reads as flaired) but stop the motion, parking the moving parts out of sight rather than freezing them mid-sweep. */ .flair::before, .flair::after { animation: none; } .flair-fire::after, .flair-lightning::after, /* the fizz is parked below the row by its own `top: 100%` and clipped away, but said out loud rather than relied on - it is one declaration away from being a line of specks frozen against the bottom edge */ .flair-bubbles::after, /* the tracking bar's whole position comes from its keyframes: stopped, it parks across the middle of the row as a bright static line through the words, which is the one place a still frame of this effect is worse than none of it. The wash below stays, and carries the flair on its own. */ .flair-glitch::after { opacity: 0; } /* these &g overrides set animation-name at a higher specificity than the generic .fmtRainbow rule above, so they have to be switched off by name here - otherwise the storm flicker / ember huff would keep running for reduced-motion readers. */ .flair-lightning .fmtRainbow, .flair-fire .fmtRainbow, .flair-rain .fmtRainbow, .flair-neon .fmtRainbow, .flair-matrix .fmtRainbow, .flair-sonar .fmtRainbow, .flair-fireflies .fmtRainbow, .flair-bubbles .fmtRainbow, .flair-aurora .fmtRainbow, .flair-bitcoin .fmtRainbow, .flair-glitch .fmtRainbow, .flair-plume .fmtRainbow { animation: none; filter: brightness(1); } /* the wash stays, parked lit; the code is in the fx layer, which the shared rule below hides outright. Nothing falls for a reader who asked for less motion. */ .flair-matrix::before, .flair-matrix::after { opacity: var(--mtx-wash-peak, 0.7); } /* the scope stays lit; nothing pings. The rings live in the fx layer, which the shared rule below hides outright, and the ticker that starts a contact never runs under reduced motion - so a reader who asked for less gets a still scope and no motion at all from this flair. */ .flair-sonar::before { opacity: var(--son-wash-peak, 0.75); } /* aurora needs nothing here, and that is worth saying rather than leaving to be rediscovered: it is made of the two pseudo-elements the shared rule above already stills, and both carry a real opacity of their own rather than getting one from their keyframes. So a reader who asked for less motion gets the sky, lit and completely still - which is the best outcome any flair here manages. */ /* BITCOIN IS THE ONE EXCEPTION to the rule below, and it has to be. Every other flair keeps its look in the pseudo-elements and its motion in the fx layer, so hiding that layer leaves something behind. Circuit keeps its ENTIRE look in the fx layer - the board is the flair - and the surge that lights it is a one-shot the ticker never fires under reduced motion anyway. So the shared rule would leave a reader who asked for less motion with a flat dark bar and nothing else. Instead the board is shown, parked lit and completely still: no animation ever starts on it, and what you get is a circuit board with the power on. That is the same outcome aurora, matrix and sonar get here, reached the other way round. Dimmer than a surge peak, because this one does not pass. */ .flair-bitcoin > .flairFx { display: block; } .flair-bitcoin .cirSeg { opacity: 0.34; } .flair-bitcoin .cirCoinWrap { opacity: 0.42; } /* glitch needs nothing for its wash, and that is worth saying rather than leaving to be rediscovered: it carries a real opacity of its own (--gl-wash-peak) rather than getting one from its keyframes, so stopping the animation parks it lit. The tear is in the fx layer, which the shared rule hides, and the ticker that fires one never runs under reduced motion anyway - so nothing here can move the text. */ /* the field stays, parked lit; the insects are in the fx layer, which the shared rule below hides outright. Nothing wanders and nothing glows. */ .flair-fireflies::before { opacity: var(--fly-wash-peak, 0.6); } /* both tubes stay lit and the fault never happens: a sign that is simply ON. The arrival strike carries its own (higher) specificity, so switching it off takes the same selector back - the generic `.flair::before` rule above cannot reach it. */ .flair-neon::before, .flair-neon::after, .line.arrive.flair-neon:not(.flairQuiet)::before, .line.arrive.flair-neon:not(.flairQuiet)::after { animation: none; opacity: 1; } .flair-neon .neonDead { opacity: 0; } /* haze keeps its violet, parked at a readable density rather than mid-breath */ .flair-plume::after { opacity: 0.7; translate: 0 0; } /* rain's ambient layers are opacity-animated, so parking them needs a value */ .flair-rain::after { opacity: 0.4; } .flair-stars::before, .flair-stars::after { opacity: 0.55; transform: none; } /* the ticker also skips firing under reduced motion; this is the belt-and-braces */ .flairFx { display: none; animation: none; transition: none; /* gone immediately, not eased away */ } /* plume is carved out of the generic quiet rule so it can pause; nothing wakes under reduced motion, so here it stops outright like everything else. */ .flair-plume::before, .flair-plume::after { animation: none; } } /* --- the tic-tac-toe board (/tictactoe) --------------------------------------- Drawn inside a system line, so it inherits the log's monospace and sits in the flow rather than floating over it. An inline-grid because the row it lives in is text: a block would break the line it is part of. Sized in PX, not em. The board started at 1.7em, which came out around 22px a cell - fine to look at and much too small to hit with a thumb, and it would have shrunk further for anyone reading at a smaller font size. A tap target does not scale with type; it scales with fingers, so the cell is a length of its own and the glyph inside it is sized from that rather than from the log's text. clamp so it grows on the phones that need it without turning into a billboard on a desktop: 13vw is about 42px on the narrowest phones and 51px on a common one, held between a floor near the 44px tap-target guideline and a sensible ceiling. */ .tttBoard { --ttt-cell: clamp(44px, 13vw, 58px); display: inline-grid; grid-template-columns: repeat(3, var(--ttt-cell)); grid-auto-rows: var(--ttt-cell); gap: 4px; margin-top: 4px; } /* Every cell is a button, including the ones nobody may press. Keeping them all as the same element means the grid cannot go crooked as cells fill in, and `disabled` is doing real work rather than being decorative - a spectator's board, or one waiting on the other player, is genuinely inert instead of clickable-and-ignored. */ .tttCell { font: inherit; /* from the cell, not from the log - see the note above */ font-size: calc(var(--ttt-cell) * 0.5); font-weight: var(--font-mid-weight); line-height: 1; display: flex; align-items: center; justify-content: center; padding: 0; border: 1px solid var(--chrome-border); border-radius: 4px; background: transparent; color: var(--muted); /* not `pointer`: most of these are not buttons you may press, and a hand cursor over a dead cell is a promise the board does not keep */ cursor: default; } /* the cells you may actually play. Only ever yours, only ever on your turn */ .tttCell.tttOpen { cursor: pointer; border-color: var(--muted); } .tttCell.tttOpen:hover, .tttCell.tttOpen:focus-visible { background: rgba(255, 255, 255, 0.09); } /* the three that ended it */ .tttCell.tttWin { border-color: currentColor; background: rgba(255, 255, 255, 0.07); } /* --- the connect four board (/connectfour) ------------------------------------- Seven COLUMNS, each one button holding six discs - the column is the control, not the disc. You do not choose where a disc lands, so clickable cells would offer a precision the game does not have; and a column button is a tap target the full height of the board, which on a phone is a far easier thing to hit than any single cell. It also means hovering lights the whole column, which no amount of per-cell styling can do. The disc is smaller than a noughts-and-crosses cell because there are seven of them across instead of three - about 38px on a common phone, for a board around 290px. That is under the 44px tap guideline for a CELL and comfortably over it for a COLUMN, which is what is actually being pressed. */ .c4Board { --c4-disc: clamp(30px, 9.4vw, 42px); /* the rim of an empty slot; see the note on .c4Disc for why it is not --chrome-border. Scoped to the board so it cannot drift into the chrome. */ --c4-hole: color-mix(in srgb, var(--accent) 30%, transparent); display: inline-flex; gap: 3px; margin-top: 4px; } .c4Col { display: flex; flex-direction: column; gap: 3px; padding: 3px; border: 1px solid transparent; border-radius: 6px; background: transparent; /* not `pointer`: most columns are not yours to press, and a hand cursor over a dead one is a promise the board does not keep */ cursor: default; } .c4Col.c4Open { cursor: pointer; border-color: var(--chrome-border); } .c4Col.c4Open:hover, .c4Col.c4Open:focus-visible { background: rgba(255, 255, 255, 0.07); border-color: var(--muted); } /* An empty slot is a hole in the board, so it is drawn as one - outlined and dark - rather than as a disc that happens to have no color. A filled one gets its player's color as a background from the renderer, the same color their handle and their message body wear. The outline is NOT --chrome-border, which the rest of the chrome uses. That is 14% of the accent, which is right for a panel edge sitting next to a solid background but too faint for this: forty-two 1px circles, each enclosing nothing, on a screen turned down in a bright room. They disappeared into the background and the board stopped reading as a grid. This is roughly double, still short of the 38% reserved for a hover/focus edge - those have to out-shout the resting state, and the resting state here is what needed the help. */ .c4Disc { /* border-box so a disc is the same size whatever its rim is doing - an empty hole has a 1px outline, a disc carrying a photo has a 2px one, and without this the grid would shift by a pixel as the board filled up */ box-sizing: border-box; width: var(--c4-disc); height: var(--c4-disc); border-radius: 50%; border: 1px solid var(--c4-hole); background: transparent; } .c4Disc.c4Filled { border-color: transparent; } /* A player's own picture on their discs, when profiles are on and they have one. The color does not go away: it is the background under the image (what you see while it loads, and what is left if it never arrives) and the rim around it (what still tells two players apart when their photos are similar, or when only one of them has a photo at all). */ .c4Disc.c4Face { border-width: 2px; overflow: hidden; } .c4Photo { display: block; width: 100%; height: 100%; object-fit: cover; border-radius: 50%; } /* The four that ended it. A static ring is easy to miss on a board you were not staring at, so they pulse - and then stop. A burst is what makes the moment obvious; a permanent strobe on a row that sits in the log for the next eight minutes is just noise, and the reader who looks over after it has finished still needs to see which four won. So the animation runs a fixed number of times and settles onto a ring thicker than the hairline this used to be. The pulse is a HALO rather than a growing ring: the discs sit 3px apart, so a ring wide enough to notice would collide with its neighbours, while a blurred glow overlapping them reads as light. Both keyframes name the same color and differ only in blur and spread, which interpolates cleanly - fading a shadow to transparent instead can leave a grey fringe mid-transition. */ .c4Disc.c4Win { box-shadow: 0 0 0 3px var(--fg); /* ~1.1 flashes a second, well under the three-per-second that makes flashing content a seizure risk, for about seven seconds */ animation: c4WinFlash 900ms ease-in-out 8; } @keyframes c4WinFlash { 0%, 100% { box-shadow: 0 0 0 3px var(--fg), 0 0 0 0 var(--fg); } 50% { box-shadow: 0 0 0 3px var(--fg), 0 0 14px 4px var(--fg); } } /* Motion off, by preference or by the settings toggle. The win still has to be obvious without it, so the ring it would have settled on is drawn straight away with the halo already on - the same information, held still. */ @media (prefers-reduced-motion: reduce) { .c4Disc.c4Win { animation: none; box-shadow: 0 0 0 4px var(--fg), 0 0 12px 2px var(--fg); } } html.fxOff .c4Disc.c4Win { animation: none; box-shadow: 0 0 0 4px var(--fg), 0 0 12px 2px var(--fg); } /* The disc that was just dropped. A dot in the middle rather than a ring around the outside, because c4Win is already a ring and the two need to be told apart at a glance - including on the disc that is both, when the last move is the one that won. Inside the disc also means it never grows the footprint, on a board whose columns are 3px apart. Drawn in the overlay white with a dark halo rather than in a theme color: it has to read on top of an arbitrary per-pubkey hue and on top of a profile photo, which between them can be any color at all. */ .c4Disc.c4Last { position: relative; } .c4Disc.c4Last::after { content: ""; position: absolute; left: 50%; top: 50%; width: 32%; height: 32%; transform: translate(-50%, -50%); border-radius: 50%; background: var(--overlay-fg); box-shadow: 0 0 0 1px rgba(0, 0, 0, 0.5); } /* --- dots and boxes ----------------------------------------------------------- A 9x9 grid whose tracks alternate: dots get a small track, the gaps between them get a large one. So a cell's role follows from its row/column parity and the markup is one flat list of spans. The DOTS are the controls here and the edges are inert, which is what lets the dots have such generous hit areas - they grow into the edge tracks around them, and there is nothing there any more to steal a tap from. */ .dbBoard { --db-dot: 12px; /* Generous on purpose. The gap is the distance between two controls, so it sets how far apart the tap targets can sit - and with only four of them across there is room to spend. This puts the board at about the width of a c4 board on the same screen. */ --db-gap: clamp(38px, 13vw, 60px); --db-line: 4px; display: inline-grid; grid-template-columns: var(--db-dot) repeat(4, var(--db-gap) var(--db-dot)); grid-template-rows: var(--db-dot) repeat(4, var(--db-gap) var(--db-dot)); align-items: center; justify-items: center; margin-top: 4px; } /* A dot reads as the thing you press: the theme's ink rather than the muted grey the lattice used to be drawn in. One that can start no line at all is dimmed instead of hidden - the lattice should still look like a lattice. */ .dbDot { width: var(--db-dot); height: var(--db-dot); padding: 0; border: 0; border-radius: 50%; background: var(--fg); opacity: 0.45; position: relative; cursor: default; } .dbDot.dbDotLive { opacity: 0.9; cursor: pointer; } /* The tap target, grown well past the dot into the edge tracks either side. At the largest gap this is about 50px across on a ~70px pitch, so two neighbouring dots never overlap. */ .dbDot::before { content: ""; position: absolute; inset: calc(var(--db-gap) * -0.32); border-radius: 50%; } .dbDot.dbDotLive:hover, .dbDot.dbDotLive:focus-visible { opacity: 1; box-shadow: 0 0 0 3px color-mix(in srgb, var(--fg) 30%, transparent); } /* the dot you are holding, and the ones it can still be joined to. Two different marks because they mean different things: one is a choice you have made, the others are the choices it leaves you. */ .dbDot.dbDotHeld { opacity: 1; background: var(--accent); box-shadow: 0 0 0 4px color-mix(in srgb, var(--accent) 45%, transparent); } .dbDot.dbDotTarget { opacity: 1; box-shadow: 0 0 0 3px color-mix(in srgb, var(--accent) 55%, transparent); } /* An undrawn edge is a faint groove that shows the lattice; a drawn one is its player's color. Inert either way - it is drawn TO, never pressed. */ .dbEdge { background: var(--chrome-border); border-radius: 2px; } .dbH { width: 100%; height: var(--db-line); } .dbV { width: var(--db-line); height: 100%; } /* a line the held dot could still make. Shown so the second tap is a choice between things you can see rather than a guess about what will happen. */ .dbEdge.dbCand { background: color-mix(in srgb, var(--accent) 45%, transparent); } /* a won box carries its owner's color, dimmed so the lines stay the loudest thing on the board - the edges are what you are reading when you plan a move */ .dbBox { width: 100%; height: 100%; border-radius: 3px; background: transparent; opacity: 0.34; } .dbBox.dbOwned { opacity: 0.42; } /* the boxes that won it, once there is nothing left to draw */ .dbBox.dbWin { opacity: 0.72; } /* The score, which the shared game header has no slot for. Two swatches and two numbers: whose color is already how the board says who is who, so naming the players again here would only repeat the line above. */ .dbScores { display: flex; gap: 14px; align-items: center; margin-top: 6px; flex-wrap: wrap; } .dbScore { display: inline-flex; align-items: center; gap: 5px; font-variant-numeric: tabular-nums; } .dbSwatch { width: 10px; height: 10px; border-radius: 2px; border: 1px solid var(--chrome-border); } /* --- sudoku -------------------------------------------------------------------- Nine by nine, with the 3x3 blocks marked by borders on the cells that sit on their edges rather than by nesting nine sub-grids - one flat list of buttons is far easier to index against an 81-character board. */ .suBoard { --su-cell: clamp(26px, 8.2vw, 34px); display: inline-grid; grid-template-columns: repeat(9, var(--su-cell)); grid-auto-rows: var(--su-cell); gap: 0; margin-top: 4px; border: 2px solid var(--chrome-border-strong); border-radius: 4px; overflow: hidden; } .suCell { /* border-box so the block edges below do not push the grid out of square */ box-sizing: border-box; width: var(--su-cell); height: var(--su-cell); padding: 0; border: 1px solid var(--chrome-border); background: transparent; color: var(--fg); font: inherit; font-size: 0.95em; line-height: 1; text-align: center; cursor: default; } .suCell:not(:disabled) { cursor: pointer; } /* the block edges: a heavier rule where a 3x3 begins */ .suCell.suEdgeL { border-left-color: var(--chrome-border-strong); border-left-width: 2px; } .suCell.suEdgeT { border-top-color: var(--chrome-border-strong); border-top-width: 2px; } /* A given is the puzzle, not somebody's answer, so it reads as printed: the theme's own ink, heavier. Everything else wears whoever wrote it. It IS tappable, though - holding one lights every other cell with that digit, which is the question you ask of a 7 far more often than "can I change it". The held and same-digit rules below sit after this one deliberately, so they paint over a given rather than under it. */ .suCell.suGiven { font-weight: var(--font-bold-weight); color: var(--fg); background: color-mix(in srgb, var(--fg) 7%, transparent); } /* the cell you are holding, and the row, column and block it answers to - the three groups you are actually reading when you decide what can go in it */ .suCell.suPeer { background: color-mix(in srgb, var(--fg) 5%, transparent); } .suCell.suSame { background: color-mix(in srgb, var(--accent) 20%, transparent); } .suCell.suHeld { background: color-mix(in srgb, var(--accent) 34%, transparent); box-shadow: inset 0 0 0 2px var(--accent); } /* a digit that repeats one of its peers. Both offenders are marked, because the grid cannot know which of them is the mistake. */ .suCell.suBad { background: color-mix(in srgb, var(--danger) 26%, transparent); color: var(--danger); } .suBoard.suSolved { border-color: var(--accent); } /* the picker */ .suKeys { display: flex; flex-wrap: wrap; gap: 4px; margin-top: 6px; max-width: calc(var(--su-cell, 34px) * 9); } .suKey { min-width: 30px; min-height: 32px; padding: 0 8px; border: 1px solid var(--chrome-border); border-radius: 5px; background: transparent; color: var(--fg); font: inherit; cursor: pointer; } .suKey:disabled { opacity: 0.4; cursor: default; } /* used nine times already: still shown, because "there are no more of these" is worth knowing, but no longer offered */ .suKey.suKeyDone { opacity: 0.28; text-decoration: line-through; } .suKey:not(:disabled):hover, .suKey:not(:disabled):focus-visible { border-color: var(--accent); } .suHint { display: block; margin-top: 5px; } /* --- polls ------------------------------------------------------------------- A poll row is a button with the tally drawn behind it: the bar is an absolutely positioned span sized by percentage, so the count and the label sit on top of it rather than being pushed around by it. */ .pollQ { display: block; margin-top: 4px; font-weight: var(--font-mid-weight); } .pollOpts { display: flex; flex-direction: column; gap: 4px; margin-top: 6px; max-width: 420px; } .pollOpt { position: relative; display: flex; align-items: center; gap: 8px; width: 100%; padding: 7px 10px; border: 1px solid var(--chrome-border); border-radius: 6px; background: transparent; color: inherit; font: inherit; text-align: start; cursor: pointer; /* the row is a tap target on a phone, so it gets a real one */ min-height: 34px; overflow: hidden; } .pollOpt:hover, .pollOpt:focus-visible { border-color: var(--muted); } /* the one you chose. A border rather than a fill, so it reads as "selected" without competing with the bar behind it for the same visual channel. */ .pollOpt.pollPicked { border-color: var(--accent); } .pollBar { position: absolute; inset-inline-start: 0; top: 0; bottom: 0; background: color-mix(in srgb, var(--accent) 16%, transparent); /* width is set inline from the tally; a change animates rather than jumping, which is the one moment a poll has any motion in it */ transition: width 220ms ease; pointer-events: none; } .pollLabel, .pollCount { position: relative; /* above the bar */ } .pollLabel { flex: 1; min-width: 0; overflow-wrap: anywhere; } .pollCount { flex: none; color: var(--muted); font-variant-numeric: tabular-nums; } .pollTally { display: block; margin-top: 5px; } @media (prefers-reduced-motion: reduce) { .pollBar { transition: none; } } /* the whole message line is a tap target for the per-user action popup */ .msgTap { cursor: pointer; } /* a reply renders the quoted message in a bordered block beneath the sender's handle, then the reply body below it. The rule is on the inline-start edge, so it moves to the right of the block when the ui is rtl. */ .replyBlock { display: block; margin: 2px 0 0; margin-inline-start: 6px; padding-inline-start: 8px; border-inline-start: 1px solid var(--chrome-border); } .replyQuote { display: block; color: var(--muted); word-break: break-word; } .replyBody { display: block; word-break: break-word; white-space: pre-wrap; } /* a translated message: its own accent-bordered block beneath the original, with a small uppercase label and the translation at full legibility (not the dim timestamp styling the old prototype used). */ .translationBlock { display: block; margin: 3px 0 1px; margin-inline-start: 6px; padding-inline-start: 8px; border-inline-start: 2px solid var(--accent); } .translationLabel { display: block; color: var(--accent); font-size: 0.72em; letter-spacing: 0.08em; text-transform: uppercase; opacity: 0.85; margin-bottom: 1px; } .translationText { display: block; color: var(--fg); word-break: break-word; white-space: pre-wrap; } /* the #xxxx pubkey suffix is dimmed to 60% of the name color, matching native bitchat (it renders the suffix run as baseColor.opacity(0.6)). */ .tag { opacity: 0.6; } /* Deliberately no weight rule for .line.mine. Native bitchat renders your own messages fully bold, but the orange already says "this one is yours" on its own, and bolding every glyph of it on top made your side of a conversation read as shouted - the more so in pure-client mode, where profiles are off and every one of your lines takes that color. Your rows now carry exactly the weights everyone else's do; only the color marks them. */ .ts { color: var(--muted); font-size: 0.8em; } /* a text-censored message: reads like a muted system aside, tap to reveal. inherits .ts sizing/color; italic + pointer signal it's a placeholder. */ .censoredMsg { font-style: italic; cursor: pointer; -webkit-tap-highlight-color: transparent; } .censoredMsg:hover { text-shadow: var(--glow); } /* the same placeholder in the quiet-channels digest. Italic like the feed's, but NOT a tap target: that list is a live summary that rewrites itself, so there is no message behind this to reveal. */ .censoredQuiet { font-style: italic; } /* "(edited)" - the same muted weight as the timestamp, because it is the same kind of thing: a fact about the message rather than part of it. */ .editedMark { color: var(--muted); font-size: 0.85em; } /* send-latency badge on your own messages - same look as the timestamp */ .ack { margin-left: 2px; } /* a send past its quick rebroadcasts, still without a confirmed echo: a soft red "unverified" that's visible without shouting - it's still quietly retrying in the background, not a dead end, so it stays unbolded. */ .ackFail { color: var(--danger); } .toggleMore { color: var(--muted); font-size: 0.8em; text-decoration: underline; cursor: pointer; margin-left: 8px; user-select: none; -webkit-tap-highlight-color: transparent; transition: color 0.12s ease; } .toggleMore:hover { color: var(--fg); } /* payment chip: a detected lightning invoice / lnurl / cashu token, rendered as a compact tap-to-copy pill instead of a raw blob. sits inline in the message body, styled like the app's other bordered chrome so it reads as a control. */ .payChip, .uiChip { display: inline-flex; align-items: baseline; gap: 5px; margin: 0 1px; padding: 1px 8px; font: inherit; font-size: 0.86em; line-height: 1.5; color: var(--accent); /* A chip is chrome, not message text, so it has to stay legible wherever it lands. "&g" paints glyphs with a gradient by setting -webkit-text-fill-color to transparent, and that inherits - so a chip inside a gradient run (every message, if your /format template wraps {msg} in &g) drew its border and fill around an invisible label. currentColor re-anchors the fill to the chip's own color, whichever variant is in play. */ -webkit-text-fill-color: currentColor; background: color-mix(in srgb, var(--accent) 8%, transparent); border: 1px solid var(--chrome-border-strong); border-radius: 5px; cursor: pointer; vertical-align: baseline; user-select: none; -webkit-tap-highlight-color: transparent; transition: background 0.12s ease, border-color 0.12s ease; } .payChip:hover { background: color-mix(in srgb, var(--accent) 16%, transparent); border-color: var(--accent); } /* in-chat ui buttons ("{{map}}" etc) take the channel-link color rather than the payment accent, so "this opens something in the app" reads differently at a glance from "this is money you can copy". */ .uiChip { color: var(--geo); background: color-mix(in srgb, var(--geo) 9%, transparent); } .uiChip:hover { background: color-mix(in srgb, var(--geo) 18%, transparent); border-color: var(--geo); } .payChipIcon { font-size: 0.95em; } .payChip.copied { color: var(--fg); border-color: var(--accent); background: color-mix(in srgb, var(--accent) 20%, transparent); } /* "beginning of chat" / "beginning of this guild's history" divider. The rules either side are drawn here rather than typed as em-dashes in the string. As text they were part of the same run as the label, so a label wide enough to fill the view took the dashes with it onto a second line and the whole thing stopped reading as centered. As flex children they shrink to nothing instead, which keeps the label on one line at any width - and keeps it centered, since both rules always split whatever the label leaves. */ .barrier { display: flex; align-items: center; gap: 0.7em; color: var(--muted); opacity: 0.7; letter-spacing: 0.06em; } .barrier::before, .barrier::after { content: ""; flex: 1 1 0; /* basis 0, so the two are always equal however long the label is */ min-width: 0; border-top: 1px solid currentColor; } .barrierLabel { flex: 0 1 auto; min-width: 0; /* the point of the exercise. #terminal sets pre-wrap; this line opts out. */ white-space: nowrap; /* a backstop for a translation longer than the whole view: clip it rather than let it wrap, since wrapping is the thing being fixed. */ overflow: hidden; text-overflow: ellipsis; /* "beginning of this guild's history" is 33 characters of monospace, which at a flat 0.85em still needs more than a 320px phone has once the rules and gaps take their share. Scale with the viewport below that, and cap at 0.85em so it stops shrinking the moment there's room. */ font-size: clamp(0.62em, 2.9vw, 0.85em); } /* --- link preview card ---------------------------------------------------------- A bordered strip under the message: small square thumbnail, title, host. Kept deliberately short - it's a hint about where a link goes, not a reader. */ /* A quoted note, drawn where its "nostr:nevent1..." was. Borrows the link card's shape on purpose - both are "something from elsewhere, standing inside this message" - but takes the accent edge rather than the link blue, because what is inside came from a person here rather than from the web. */ .quoteCard { display: block; margin: 6px 0 2px; padding: 6px 8px; /* 420px is the comfortable reading width, but never past the container - the notes panel is narrower than that on a phone, and a fixed 420 hung the card's right edge off the side of the sheet */ max-width: min(420px, 100%); box-sizing: border-box; border: 1px solid var(--chrome-border); border-inline-start: 2px solid var(--accent); background: var(--field-bg); } .quoteHead { display: flex; align-items: baseline; gap: 8px; margin-bottom: 3px; cursor: pointer; } .quoteWho { font-weight: var(--font-bold-weight); overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .quoteHead:hover .quoteWho { filter: brightness(1.35); } .quoteTime { flex: none; color: var(--muted); font-size: 0.72em; } .quoteBody { display: block; color: var(--muted); font-size: 0.92em; /* a quote is a glimpse, and a long one must not out-shout the message quoting it */ overflow-wrap: anywhere; white-space: pre-wrap; } .linkCard { display: flex; align-items: center; gap: 10px; margin: 6px 0 2px; padding: 6px 8px; max-width: 420px; border: 1px solid var(--chrome-border); border-inline-start: 2px solid var(--geo); /* the same blue links already use */ background: var(--field-bg); text-decoration: none; color: inherit; } .linkCard:hover { border-color: var(--chrome-border-strong); border-inline-start-color: var(--geo); } .linkThumb { flex: none; width: 56px; height: 56px; overflow: hidden; background: var(--chrome-bg); display: block; position: relative; } .linkThumb img { width: 100%; height: 100%; object-fit: cover; display: block; } /* same treatment inline images get: a preview picture is exactly the "surprise image from a stranger" case the blur setting exists for, and being small doesn't change what it can be. */ .linkThumbCensored img { filter: blur(12px); } .linkCardText { min-width: 0; display: flex; flex-direction: column; gap: 2px; } .linkCardTitle { color: var(--fg); font-weight: var(--font-bold-weight); /* two lines and then stop: a long headline shouldn't push the next message off */ display: -webkit-box; -webkit-line-clamp: 2; -webkit-box-orient: vertical; overflow: hidden; } .linkCardSite { color: var(--muted); font-size: 0.85em; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .mediaPreview { position: relative; display: block; overflow: hidden; border-radius: 8px; margin-top: 6px; } .mediaPreview[data-img-toggle] { cursor: pointer; } .chatImagePreview { display: block; /* auto/auto so the width+height ATTRIBUTES supply the intrinsic size, which is what lets the browser claim the row's full height before the bytes land (see imageSizeAttrs in app.js). The max-* pair still does the actual sizing, and a replaced element resolves both of them preserving the ratio - so a small picture is still drawn small and nothing is stretched. */ width: auto; height: auto; max-width: min(100%, 420px); max-height: 420px; object-fit: contain; border-radius: 8px; border: 1px solid var(--chrome-border); } .chatImagePreviewCensored { filter: blur(18px) brightness(0.55); transform: scale(1.04); } .mediaCensorOverlay { position: absolute; inset: 0; display: flex; align-items: center; justify-content: center; pointer-events: none; font-size: 0.85em; font-weight: var(--font-mid-weight); letter-spacing: 0.04em; color: var(--overlay-fg); text-shadow: var(--overlay-shadow); background: var(--field-bg); } #composerWrap { position: relative; /* the "+" menu anchors here; #inputbar's border + top padding, and its side padding, are what sit between this box's edges and the button */ --menuAnchorTop: 7px; --menuAnchorRight: 14px; } /* the mirror of #newMessagesBar at the other end of the feed: a quiet strip over the top of the terminal while a page of older history is being fetched. Same neutral fill and blur, so the two read as one family. */ #historyHint { /* absolute rather than a flex row: taking layout space would shrink the feed the moment it appears, moving the very content the scroll restore works to hold still. `top` is set from the terminal's own offset when shown, so it lands just under the topbar without anything hardcoded. */ position: absolute; left: 0; right: 0; padding: 6px 12px; background: var(--field-bg); backdrop-filter: blur(3px); -webkit-backdrop-filter: blur(3px); color: var(--muted); font-size: 0.85em; text-align: center; pointer-events: none; z-index: 5; } #historyHint[hidden] { display: none; } /* The column both foot-of-feed notices live in. They used to be two absolutes at the same `bottom: 100%`, i.e. on top of each other - fine while only one existed. THE FILL AND THE BLUR LIVE HERE, not on the two children. Two stacked elements each with their own backdrop-filter each blur what is behind THEMSELVES, and two translucent fills compose differently from one - so over anything but a flat colour the boundary between them showed as a visible line. One surface, one blur, one border, and the two notices are transparent text sitting on it. */ #bottomBars { position: absolute; left: 0; right: 0; bottom: 100%; display: flex; flex-direction: column; z-index: 5; background: var(--field-bg); backdrop-filter: blur(3px); -webkit-backdrop-filter: blur(3px); border-top: 1px solid var(--chrome-border); } /* ...and with neither notice up there is nothing to paint. Without this the border alone draws a hairline across the foot of the feed at all times. */ #bottomBars:not(:has(> :not([hidden]))) { background: none; backdrop-filter: none; -webkit-backdrop-filter: none; border-top: 0; } /* Unfolded, the list is a block of text rather than a line and needs the feed to stop reading through it - but it must still be FROSTED, not a black panel. So the work is done by the blur rather than by opacity: a much heavier blur destroys the legibility of whatever is behind while keeping the surface translucent and alive. Applied to the whole surface so it stays ONE surface - a denser panel with a lighter strip under it would be the seam again, in a different place. */ #bottomBars:has(> #quietBar.open) { background: color-mix(in srgb, var(--chrome-bg) 46%, transparent); backdrop-filter: blur(22px) saturate(0.7); -webkit-backdrop-filter: blur(22px) saturate(0.7); } #newMessagesBar { padding: 8px 12px; /* the fill moved to #bottomBars so the two notices share one seamless surface; what is left here is the text. Neutral rather than an accent tint over there for the same old reason: the label is already the accent color, and a green bar under green text reads as one solid block instead of a notice sitting over the feed. */ background: none; color: var(--accent); font-size: 0.9em; font-weight: var(--font-bold-weight); text-align: start; cursor: pointer; user-select: none; } #newMessagesBar:not([hidden]) { animation: barIn 0.18s ease-out; } @keyframes barIn { from { opacity: 0; transform: translateY(4px); } } #newMessagesBar[hidden] { display: none; } /* generic autocomplete popup (mentions now, local commands later): sits above the composer and grows upward, so the best/nearest match is at the bottom by the keyboard. blurred backdrop, just a hairline separator - no heavy borders. */ #suggestBox { position: absolute; left: 0; right: 0; bottom: 100%; z-index: 6; display: flex; flex-direction: column-reverse; /* size against the MEASURED visual viewport (--vvh, see fitViewport): plain vh is the LAYOUT viewport, which on mobile ignores the on-screen keyboard, so a long list could be given more room than is actually visible above it. */ max-height: calc(var(--vvh, 100vh) * 0.42); overflow-y: auto; -webkit-overflow-scrolling: touch; overscroll-behavior: contain; background: color-mix(in srgb, var(--chrome-bg) 60%, transparent); backdrop-filter: blur(10px); -webkit-backdrop-filter: blur(10px); border-top: 1px solid var(--chrome-border); padding: 4px 0; font-size: 14px; } #suggestBox[hidden] { display: none; } .suggestRow { /* flex children shrink by default: in a max-height flex column an over-long list would squash every row (padding collapsing, text clipped by the overflow below) instead of letting the box scroll. Pin the natural height so the rows stay legible and the overflow becomes a scroll. */ flex: none; padding: 7px 14px; cursor: pointer; white-space: nowrap; overflow: hidden; text-overflow: ellipsis; -webkit-tap-highlight-color: transparent; } /* the active row samples its own --row-accent (e.g. a user's assigned color) so the highlight never clashes with the label; --accent (terminal green) is the fallback for accent-less items like future /command hints. */ .suggestRow.active { background: color-mix(in srgb, var(--row-accent, var(--accent)) 16%, transparent); } .suggestRow:hover:not(.active) { background: color-mix(in srgb, var(--fg) 5%, transparent); } .suggestRow .sfx { opacity: 0.6; } /* optional dim secondary label (e.g. a command description); unused by mentions */ .suggestMeta { color: var(--muted); margin-left: 8px; font-size: 0.85em; } /* active-reply indicator: a slim bar above the composer showing who you're replying to, with an x to cancel. sending clears it; so does the x. */ .replyBanner { display: flex; align-items: center; gap: 8px; padding: 6px 14px; background: var(--chrome-bg); border-top: 1px solid var(--chrome-border); border-inline-start: 2px solid var(--accent); font-size: 13px; color: var(--muted); } .replyBanner[hidden] { display: none; } .replyBannerArrow { color: var(--accent); } /* the tappable half of the banner: handle on the left, ping state on the right. Borderless and font-inherited so it still reads as the banner's own text rather than a control bolted onto it - the whole strip is the switch. */ .replyBannerToggle { flex: 1; min-width: 0; display: flex; align-items: baseline; justify-content: space-between; gap: 10px; border: 0; background: transparent; color: inherit; font: inherit; text-align: start; padding: 0; cursor: pointer; -webkit-tap-highlight-color: transparent; } .replyBannerText { flex: 1; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } /* Reads as the live state, not decoration: lit in the accent while the reply will ping, dimmed to the banner's own muted grey when it won't. Color alone never carries it - the words say "on" or "off" either way. */ .replyBannerPing { flex: none; font-size: 11px; letter-spacing: 0.04em; white-space: nowrap; color: var(--muted); } .replyBannerToggle[aria-pressed="true"] .replyBannerPing { color: var(--accent); } .replyBannerToggle:hover .replyBannerText { color: var(--fg); } .replyBannerX { border: 0; background: transparent; color: var(--muted); font: inherit; cursor: pointer; padding: 2px 6px; -webkit-tap-highlight-color: transparent; } .replyBannerX:hover { color: var(--fg); } /* flat, borderless composer to match native bitchat: just the input text and a "send" label sitting low above the home indicator, no boxes or separator. */ #inputbar { display: flex; /* flex-end, not center: the composer grows upward as lines are added, and the prompt glyph and send button belong on the last line rather than floating in the middle of a five-line block. Identical to center at one row. */ align-items: flex-end; gap: 12px; padding: 6px 14px calc(6px + var(--inset-b)); background: var(--chrome-bg); border-top: 1px solid var(--chrome-border); } /* the classic shell prompt: dim at rest, lit (with a touch of phosphor) while the composer has focus - a quiet "the terminal is yours" signal. */ .prompt { flex: none; color: var(--muted); font-size: 15px; font-weight: var(--font-bold-weight); margin-right: -4px; /* tuck the input's text closer to the glyph */ transition: color 0.15s ease, text-shadow 0.15s ease; user-select: none; /* Same vertical metrics as the composer beside it. The row bottom-aligns its items (the composer grows upward), so a glyph with no padding lands on the box floor while the composer's text is held 6px above it by its own - which sat the ">" 7.8px below the line it introduces. Matching the padding and the line box puts it back on the baseline, and on the LAST line once the composer has several. */ padding: 6px 0; line-height: 1.3; } #inputbar:focus-within .prompt { color: var(--accent); text-shadow: var(--glow); } /* a one-row textarea dressed as the single-line prompt it used to be. It is a textarea because an and have no rule in this stylesheet - they have never needed one, because the browser's own says `font-weight: bolder`. And `bolder` is not a number: it is one step up the *inherited* weight, and the step from 500 is 700. So the moment the body went to 500 for the webfont, every in the app quietly settled at 700 - +14% ink over its surroundings instead of +31% - and that is most of the bold chrome there is: [EXIT], the channel name, RELAYS, GLUB.CHAT, every panel heading. The 35 rules that name a weight were converted; these two dozen elements were never covered by any of them. Named explicitly now, so "bold" is one decision in one place. */ strong, b { font-weight: var(--font-bold-weight); } /* bracketed text toggle in the terminal style ([ on ] / [ off ]) - the real checkbox is hidden and driven by the label; the visual reflects its state. */ .assistCheck { position: absolute; width: 1px; height: 1px; opacity: 0; pointer-events: none; } .toggleVisual { flex: none; font-weight: var(--font-bold-weight); letter-spacing: 0.06em; } .toggleVisual::after { content: var(--label-toggle-off); color: var(--muted); } .assistCheck:checked ~ .toggleVisual::after { content: var(--label-toggle-on); color: var(--accent); } /* identity section in settings: your (censored) nsec + reveal/copy/paste. kept out of the public composer on purpose - a secret key has no business in a broadcast box. sits right under the toggles (no divider) on the same rhythm. */ .idSection { /* match the field->buttons gap (.idButtons margin-top) so the button row sits the same distance above "done" as it does below the nsec field. */ margin-bottom: 8px; } .idHeading { color: var(--fg); font-size: 14px; margin-bottom: 8px; } .idFieldWrap { position: relative; } .idField { width: 100%; box-sizing: border-box; border: 1px solid var(--chrome-border); background: var(--field-bg); color: var(--fg); font: inherit; font-size: 14px; padding: 9px 12px; outline: 0; /* keys are bech32/hex, never prose - so they read left-to-right no matter which way the ui runs. Left to inherit rtl, the masking asterisks and the "nsec1" prefix swap ends and the field looks corrupted. */ direction: ltr; text-align: start; } /* action feedback (copied / imported / errors) rides inside the field on the right, over the empty tail of the censored key - frees the row below. */ .idStatus { position: absolute; right: 12px; top: 50%; transform: translateY(-50%); padding-left: 10px; /* Opaque, so it hides whatever it sits over - the masked nsec, or the keys going past during a vanity search. --field-solid is the recess colour composited rather than translucent, which is what makes it match the box it is inside; the panel background it used before was a shade off against the field's own inset. */ background: var(--field-solid); font-size: 12px; color: var(--muted); pointer-events: none; } .idStatus.ok { color: var(--accent); } .idStatus.err { color: var(--danger); } .idButtons { display: flex; gap: 8px; margin-top: 8px; } .idBtn { flex: 1; border: 1px solid var(--chrome-border); background: transparent; color: var(--accent); font: inherit; font-weight: var(--font-bold-weight); padding: 9px 8px; cursor: pointer; } /* Your #tag and the control that mints a new one (settings > nostr). The nsec section's parts laid on one line: the tag field takes the room, the button keeps its own width so it does not resize as its label swaps between `mint` and `stop`. */ .idRotateRow { display: flex; gap: 8px; align-items: stretch; margin-bottom: 8px; } .idRotateWrap { flex: 1; min-width: 0; } .idRotateBtn { flex: 0 0 auto; min-width: 96px; } /* The "#" is a LABEL sitting in the field's padding, not a character in the value. That is the whole implementation of "undeletable": there is no caret position in front of it, no keystroke that can reach it, and nothing to put back afterwards - where a sentinel character inside the value has to be defended against backspace, select-all, paste and the caret being clicked in front of it, and loses eventually. Left where the field's own text would start, with the input's start padding moved over by exactly one character. 1ch is that width, and this font is monospace. */ .idTagHash { position: absolute; inset-inline-start: 12px; top: 50%; transform: translateY(-50%); font-size: 14px; line-height: 1; color: var(--muted); pointer-events: none; } /* --- the patron's nip-05 field -------------------------------------------------- The mirror image of .idTagHash: a label the field cannot delete, on the other end because a nip-05 reads name@domain and the half you own is the half in front. Its width is not knowable from here - "@glub.chat" and "@some-longer.example" are the same element with different text, and the instance decides which - so the input is padded from the label's measured width at runtime (see syncPatronRow) rather than from a number typed in this file. */ .idTagSuffix { position: absolute; inset-inline-end: 12px; top: 50%; transform: translateY(-50%); font-size: 14px; line-height: 1; color: var(--muted); pointer-events: none; white-space: nowrap; } .idPatronField { /* a fallback only, until the measurement lands: enough room for a short domain, so the very first paint is never text sitting underneath the label */ padding-inline-end: 92px; } .patronStatus { margin-top: 8px; font-size: 12px; line-height: 1.45; color: var(--muted); min-height: 1.45em; /* holds its line, so a message appearing moves nothing below it */ } .patronStatus.bad { color: var(--danger); } .patronStatus.good { color: var(--accent); } .idTagField { padding-inline-start: calc(12px + 1ch); /* four hex characters, and only ever four - so it can be spaced like the tag it is rather than like prose */ letter-spacing: 0.06em; } /* The hint is the tag you have NOW, so it reads as a statement of what you are until you type over it - and it wears the colour that tag wears in chat, which is what makes it a statement rather than an instruction. --own-color is set from pubkeyColor on every identity change (see syncRotateTag); the muted fallback is what it looks like for the instant before that runs. */ .idTagField::placeholder { color: var(--own-color, var(--muted)); opacity: 1; } /* ...and the "#" goes with it, but ONLY while the hint is what is showing: `#a1b2` is one label and half of it in another colour would read as broken. The moment you type, the label is prefixing a REQUEST rather than stating a fact, and it drops back to the muted voice. :has because .idTagHash precedes the input, so no sibling combinator can reach it from :placeholder-shown. */ .idRotateWrap:has(.idTagField:placeholder-shown) .idTagHash { color: var(--own-color, var(--muted)); } /* while a search runs the field shows the keys going past, which is not something you are editing */ .idTagField:disabled { color: var(--accent); opacity: 1; -webkit-text-fill-color: var(--accent); /* ios greys a disabled field out regardless */ } /* ---- nostr profile editor (settings > nostr) ------------------------------ */ .profileEditSection { margin-bottom: 12px; } /* banner: a short full-width strip. the "+ banner" control fills it and, once an image is set, the preview lays over the button so the tap target stays. */ .profileEditBanner { position: relative; width: 100%; height: 72px; margin-bottom: 8px; border: 1px solid var(--chrome-border); background: var(--field-bg); overflow: hidden; } .profileEditBannerImg { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; } /* Why "+ banner" looked shaved off down its right-hand side. The control filled the strip EXACTLY - a