This file is meant to exercise the Markdown viewer as a reader, not as a blog post. When you open it, check spacing, typography, tables, math, code blocks, and small interactive HTML elements.
- headings keep a clear visual hierarchy
- inline code stays readable in both themes
- task lists and nested bullets align cleanly
- tables keep borders and spacing on narrow screens
- block quotes do not collapse into the page background
- code fences show language labels and copy affordances
- footnotes render at the end instead of leaking raw syntax
Tip: switch between light and dark themes while this file is open. The goal is not perfect publishing output. The goal is calm, readable technical notes.
- Bold, italic, strike, and
inline code - Ordered lists and nested bullets
- Table layout
- Footnotes
- KaTeX inline math such as
$E = mc^2$ - KaTeX block math
- HTML details block
- Relative document links
| Area | What this sample checks | Why it matters |
|---|---|---|
| Typography | heading rhythm, paragraph width, quote contrast | long docs must stay comfortable to scan |
| Structure | lists, tables, horizontal rules | README and ADR files lean on these heavily |
| Technical content | math, code, inline tokens | developer docs mix prose with symbols |
| Navigation | relative links and footnotes | repo docs should stay connected |
export function summarizeDocument(name: string, sections: number) {
return `${name} contains ${sections} sections and is ready for review.`
}Why keep this file small?
A feature demo should be easy to skim. Once the viewer behavior feels right, larger docs such as release notes and runbooks cover the long-form reading case.A realistic reader demo should not feel synthetic.1 Relative links are more useful than filler paragraphs.2