ozan
f01036c646
Merged overlapping posts: - forking-gitea + fork-dont-build → one post about the fork philosophy - fal-image-generation + image-generation-fal → one post about AI art pipeline Rewrote all posts with external/public voice: - Stronger hooks, concrete examples, punchier language - agentic-workflow: restructured around soul files + skills + numbers - agent-harness: clearer framing of 'what an agent harness is' - cloud-harness: tighter narrative about overnight agents - godot-optimisation: same depth, sharper opening - pre-commit-agent: clearer architecture, cost breakdown - studio-cli: reframed around identity/cold-start problem - blog-visual-upgrade: tightened the restyle story 10 posts total (9 markdown + 1 hand-authored HTML)
5.1 KiB
title, slug, date, description, og_description, og_image, excerpt, author, author_initials, author_role
| title | slug | date | description | og_description | og_image | excerpt | author | author_initials | author_role |
|---|---|---|---|---|---|---|---|---|---|
| How We Restyled Our Blog with Two Template Files and Zero Dependencies | blog-visual-upgrade | 2026-06-03 | 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. | Blog restyle: gradient titles, dark code panels, amber callouts — two template files, zero deps. | https://www.tinqs.com/img/og-cover.jpg | 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. | Ozan Bozkurt | OB | CTO & Developer, Tinqs |
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.
Two template files, one build step, zero external dependencies. Here's what we changed.
The build system (why it mattered)
The blog is generated by build.js — a zero-dependency Node script that converts markdown to HTML:
posts/*.md + _template.html / _index_template.html → *.html
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.
The palette
Four accent colours, borrowed from our team guide:
| Role | Colour | Where |
|---|---|---|
| Brand amber | #c9935a |
Gradient start, h2 left bar, card hover |
| Warm gold | #f59e0b |
Gradient midpoint, bold text |
| Blue | #38bdf8 |
Gradient endpoint, links, date pills |
| Purple | #a855f7 |
h3 colour, link hover |
Tasteful. Not a rainbow.
What we styled
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.
Date pills. Monospace chip — blue text, 999px border-radius, uppercase, tight letter-spacing. Sits before the title like a kicker.
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.
Section cues. h2 gets a 4px amber left border as visual anchor. h3 gets a purple tint — enough to signal a section break without pulling focus.
Links. Blue #38bdf8, purple #a855f7 on hover. Bold text picks up amber.
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.
Index page. Same gradient on the listing title. Date pills on cards. Amber border on card hover. Blue/purple read links.
The rebuild
node build.js
Building blog...
11 posts built + index.html
Done.
Zero errors. Every regenerated HTML file now carries the inline <style>. Confirmed with grep -l "background-clip" *.html — all pages ship the gradient.
What we didn't touch
Navigation, footer, site chrome, responsive behaviour — all unchanged. This was a CSS-only change. No markup altered beyond the <style> injection.
What we learned
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 and served by Tinqs Studio. All styling is self-contained in the templates.