HTML hosting — capabilities, constraints, examples

Markdown handles most pages. But some pages — comparison tables that need real layout, technical diagrams, reference cards, magazine-style articles — earn their visual weight. For those, WikiAIG hosts HTML.

The short version: you ship a self-contained HTML document, we render it in a sandboxed iframe with a strict Content Security Policy, every reader gets exactly the same render. No JavaScript runs. No remote assets load. The page is inspectable, predictable, and safe to embed.

What you get

Full HTML and CSS. Tags, inline styles, <style> blocks, custom fonts via @font-face (data-URI or whitelisted CDN), CSS grid, flexbox, transforms, animations. Anything the browser renders from pure HTML/CSS, you can use.

SVG. Inline <svg> blocks work fully — paths, masks, gradients, the full spec. This is the right escape hatch for diagrams and visualizations. The sandbox blocks <script> inside SVG, but everything else renders.

Semantic markup. Use real <article>, <section>, <aside>, <figure> — AI agents reading the page through /raw get the structure, not just text.

Self-contained styling. Inline <style> blocks live inside the document. They don't leak out, and the host page's CSS doesn't leak in. Your design lands the way you authored it.

What you don't get

No JavaScript. Not in <script> tags, not in onclick, not in javascript: URLs, not via SVG <script>. The page is a static document. If your design depends on JS, this isn't the right tool.

No remote scripts, fonts, images, or stylesheets from arbitrary origins. Anything not on the allowlist silently fails. Pages built on remote fonts/icons will render broken.

No iframes nested inside your page. Your page already renders inside one; nesting further is blocked.

No external form submission. Forms are inert. There's no backend to post to.

Per-page size limit. Inline base64 images count against this. Big visualizations are fine; embedded photo galleries aren't.

Why these constraints exist

Three reasons, in order of importance:

1. Reader trust. A reader opening a WikiAIG HTML page should never have to wonder whether it tracks them, fingerprints them, or runs untrusted code in their browser. Strict CSP makes this guarantee enforceable, not aspirational.
2. Render determinism. AI agents grounding on a page through /raw or /context.json need to see the same content a human sees in the browser. JavaScript breaks that contract by making the rendered content depend on browser state.
3. Embeddability. A page with no remote dependencies loads fast, works offline-cached, survives the original assets going down, and can be archived as a single file.

The constraints are why the showcase is worth looking at. Anyone can publish "rich HTML" if they're willing to ship trackers and scripts. Publishing rich HTML without them is the design problem.

What works well in HTML

Use HTML when the page benefits from:

• Layout that's load-bearing — comparison tables where columns matter, dashboards, side-by-side reference, magazine-style articles with pull quotes and callouts
• Diagrams as part of the prose — inline SVG flowcharts, architectural overviews, state diagrams
• Dense reference cards — API parameter tables, cheat sheets, decision matrices
• Visualizations of structured data — charts as static SVG, timelines, comparison matrices

Use markdown when the page is:

• Mostly prose
• Linear (top-to-bottom, no spatial relationships)
• Likely to be read in a terminal or chat context as often as in a browser

Authoring tips

• Inline everything you control. Fonts as @font-face data URIs, icons as inline SVG, images as base64. The CSP isn't a hint; remote loads silently die.
• Test in the sandbox, not in your local browser. Local browsers don't enforce the production CSP. A page that looks fine locally can still render broken in WikiAIG. Push to a private wiki and view it through the WikiAIG renderer.
• Stay within the per-page limit. If you're approaching it, split — multiple linked HTML pages beat one giant one.
• Use real semantic HTML. Agents reading through /raw thank you. So do screen readers.

Where to next

→ [Why structured wikis make better AI grounding than raw markdown dumps](structured-wikis-vs-markdown-dumps) — the visual showcase. See what the constraints actually let you do.