The mechanism
Why a description rather than HTML.
Handing a plugin a web view would make previews easy and make three other things impossible: theme fidelity, a reading position that survives the switch, and the guarantee that a document cannot reach the network while being read.
01The toolbar button appears only when something can render
The Preview toggle (⇧⌘V, or View ▸ Preview) is live for a document some installed plugin has claimed by extension or language, and disabled otherwise. It never offers a rendering nobody can produce.
02Every block carries its source offset
Which is what keeps your place across the switch, in both directions: rendered from the paragraph you were editing, back to the line the block you were reading began at.
03Preview belongs to the pane, not the file
So the same file can be source in one split and rendered in the other, which is the arrangement most people actually want while writing.
04The theme is the app’s theme
Because the blocks are drawn by the same views the built-in panels use. There is no second stylesheet to keep in step with Light, Dark, and the five themes.
05A preview cannot fetch anything
There is no document, no script engine and no stylesheet loader in the rendering path. A Markdown file that references a remote image cannot cause a request.
06Rendering is capped, not unbounded
The parser runs interpreted in JavaScriptCore, so the example Markdown renderer caps itself at 256 KB rather than stall the editor on every keystroke of a very large document.