Hi! Thanks for html-anything — the 60 source prompts and 17 style systems are a great foundation. Two enhancements I'd love to see in the project; wanted to feel out interest before drafting PRs.
1. Built-in dark mode toggle
Idea: Each generated artifact ships with a small sun / moon toggle button (fixed top-right by default). Honours OS prefers-color-scheme: dark on first load, persists user choice in localStorage, no flash-of-light on subsequent loads.
Why:
- Users open these artifacts on any device, often at night.
- Universally requested across HTML output skills.
- Pure inline implementation — no new dependencies, vanilla JS only, ~50 lines total.
- Aligns with the project's offline-first principle.
Three pieces working together:
- No-flash init script in
<head> (right after <title>) — runs synchronously to set data-theme on <html> before the body renders.
[data-theme="dark"] palette override per style — each style declares its dark variant (or doesn't, in which case it stays light — graceful fallback).- Toggle button with sun / moon inline SVG and a vanilla
onclick handler that flips the attribute and saves to localStorage.
Working reference implementation in andrewkobzev/html-reports/templates/base.html — search for theme-toggle. Each of the 6 templates there carries the same pattern, so it's battle-tested across slightly different layouts (status report, slide deck, explainer, etc.).
For the existing 17 styles, the migration can be gradual: a style without a declared dark palette continues to render light (no breakage). The most-used styles can ship dark first; the rest get added over time.
2. Syntax highlighting for code blocks
Idea: When an artifact contains <pre><code class="language-X"> blocks, syntax highlighting is applied automatically — no extra setup required from the user.
Why: Code appears across many of the existing use cases (developer, terminal-cli, document / markdown styles with embedded snippets, teaching studios). Plain-text code in an otherwise beautifully designed page looks jarring.
A concrete example: your own examples/pr-review/output.html renders the diff as plain monospace. Of all artifact types, a PR-review diff is the one where syntax highlighting matters the most — and it's currently absent. Same goes for CI logs, stack traces, source-file views.
Library options I considered:
| Library |
Size (minified) |
Languages |
Notes |
| highlight.js |
~25 KB common subset |
190+ |
Mature, auto-detects language. Recommended. |
| Prism.js |
~6 KB core + ~3 KB per lang |
200+ |
Smaller core but needs explicit language loading |
| Shiki |
~1 MB |
TextMate-grade |
Beautiful but heavy — breaks offline-first feel |
My recommendation: highlight.js with the common-language subset, inlined into the output to preserve the offline-first principle. Auto-detect language when the class attribute is missing. The highlight colour palette can reference the same CSS custom properties as the rest of the artifact, so syntax colours respect dark mode automatically without a second theme switch.
Questions before I open PRs
- Is there interest in these as first-party features, or would you prefer they stay as community add-ons?
- Any preference between highlight.js / Prism / Shiki for syntax highlighting?
- For dark mode — should the toggle button always be present in the artifact, or be opt-in via a render flag (
--dark-mode-toggle)?
- Would you prefer one combined PR, or one per feature?
Happy to draft either or both at whatever scope works for you. Have working reference implementations ready to adapt to your structure.
Thanks for the project!
Hi! Thanks for
html-anything— the 60 source prompts and 17 style systems are a great foundation. Two enhancements I'd love to see in the project; wanted to feel out interest before drafting PRs.1. Built-in dark mode toggle
Idea: Each generated artifact ships with a small sun / moon toggle button (fixed top-right by default). Honours OS
prefers-color-scheme: darkon first load, persists user choice inlocalStorage, no flash-of-light on subsequent loads.Why:
Three pieces working together:
<head>(right after<title>) — runs synchronously to setdata-themeon<html>before the body renders.[data-theme="dark"]palette override per style — each style declares its dark variant (or doesn't, in which case it stays light — graceful fallback).onclickhandler that flips the attribute and saves tolocalStorage.Working reference implementation in
andrewkobzev/html-reports/templates/base.html— search fortheme-toggle. Each of the 6 templates there carries the same pattern, so it's battle-tested across slightly different layouts (status report, slide deck, explainer, etc.).For the existing 17 styles, the migration can be gradual: a style without a declared dark palette continues to render light (no breakage). The most-used styles can ship dark first; the rest get added over time.
2. Syntax highlighting for code blocks
Idea: When an artifact contains
<pre><code class="language-X">blocks, syntax highlighting is applied automatically — no extra setup required from the user.Why: Code appears across many of the existing use cases (
developer,terminal-cli, document / markdown styles with embedded snippets, teaching studios). Plain-text code in an otherwise beautifully designed page looks jarring.A concrete example: your own
examples/pr-review/output.htmlrenders the diff as plain monospace. Of all artifact types, a PR-review diff is the one where syntax highlighting matters the most — and it's currently absent. Same goes for CI logs, stack traces, source-file views.Library options I considered:
My recommendation: highlight.js with the common-language subset, inlined into the output to preserve the offline-first principle. Auto-detect language when the
classattribute is missing. The highlight colour palette can reference the same CSS custom properties as the rest of the artifact, so syntax colours respect dark mode automatically without a second theme switch.Questions before I open PRs
--dark-mode-toggle)?Happy to draft either or both at whatever scope works for you. Have working reference implementations ready to adapt to your structure.
Thanks for the project!