description: "Gradient titles, dark code panels, amber callouts — we gave the Tinqs blog a visual refresh borrowing our internal team guide aesthetic. Two template files, one Node script, no framework."
og_description: "Blog restyle: gradient titles, dark code panels, amber callouts — two template files, zero deps."
excerpt: "We gave the Tinqs blog a visual refresh — gradient titles, dark code panels, date pills, amber accent bars. Two template files, one build step, zero external dependencies."
Our blog looked fine. Readable, semantic, proper typography. But it didn't have much personality. Code blocks were unstyled. Headings sat flat. The design said "competent" more than "intentional."
Then we looked at our internal team guide — a self-contained HTML doc with gradient titles that clip to transparent, dark code panels, and callout boxes with coloured borders. It radiated a "well-maintained developer doc" energy. We wanted the blog to feel like it came from the same shop.
This means we never touch a generated `.html` file by hand. Every visual change flows through the templates. The site-wide CSS — nav, footer, base typography, brand accent — lives in `../style.css`, served by Git Studio from outside the repo. We didn't touch it.
Instead, we injected a self-contained `<style>` block at the end of `<head>` in both templates, after the `../style.css` link. Cascade order handles the overrides. No `!important`. No external font loads. No CDN dependencies.
**Gradient titles.** Post `h1` gets `linear-gradient(90deg, #c9935a, #f59e0b 40%, #38bdf8)` via `background-clip: text; color: transparent`. Underlying text preserved for screen readers and SEO.
**Code blocks.** The site CSS only styled inline `<code>`. Fenced blocks got a dark panel (`#0a0e14`, `#2a3340` border, `10px` radius, monospace, `overflow-x: auto`). A reset rule on `pre code` prevents inline-code styles from doubling up inside the panel.
**Blockquote callouts.** Amber-tinted background, 4px amber left border, rounded right corners. The CSS is written and waiting — `build.js` doesn't emit `<blockquote>` yet, but the rules activate the moment we add `>` syntax support.
Zero errors. Every regenerated HTML file now carries the inline `<style>`. Confirmed with `grep -l "background-clip" *.html` — all pages ship the gradient.
**Inline styles beat separate CSS files when you don't control the server.** The blog repo is standalone — it can't modify `../style.css`. Inline `<style>` blocks ship inside the generated HTML, so the blog is fully self-contained. One `git push` and it's live.
**Cascade order is the cleanest specificity hack.** Putting the `<style>` block after the external stylesheet link means same-selector rules win by position. No `!important`, no selector wars, no unexpected regressions.
**Build systems make CSS changes safe.** Because we never hand-edit `.html`, every style change is tested by regenerating all pages and grepping for the new selectors. If a rule doesn't ship, you know immediately.
Two gaps we'll fill later: blockquote support in `build.js` (the callout CSS is waiting) and ordered lists (same story). In the meantime, the blog already looks intentional — and it took two template files, one build step, and zero dependencies.
*The blog is generated by [build.js](https://tinqs.com/tinqs/blog) and served by [Tinqs Studio](https://tinqs.com). All styling is self-contained in the templates.*
