Adding Markdown to a long-running catalog sounds like a single decision: install a parser and turn plain text into HTML, but in a mature database, “Notes” isn’t one place. In the Grand Comics Database (GCD), there are notes on issue records, creator biographies, brand groups, reprint relationships, and character appearances. Some notes sit in a wide detail panel with room for lists and headings, while other notes live inside a table row or tucked beside a comma-separated list of names.
If you treat every note field the same, layout bugs show up immediately. A Markdown processor usually wraps its output in paragraph tags. Drop block-level <p> tags inside an inline table cell or an inline list and the browser splits your layout. But strip everything down to plain text and catalog editors lose the links, lists, and formatting they needed in the first place.
Supporting rich text across a legacy catalog requires separate rendering contracts:
- Block display belongs on full detail pages. Major sections can handle complete block formatting: paragraphs, bulleted lists, and tables.
- Inline display is for compact annotations. Related links, small parenthetical notes, and table columns need phrasing-level markup. They can allow emphasis, italics, and links, but block paragraphs have to be stripped or converted so they don’t fracture the surrounding markup.
Sanitization has to be fail-closed across both display and preview. Both editor preview and public display need to share the exact same allowlist. If an editor previews formatting that the public page strips, the editor gets confused; if the public page displays something preview didn’t sanitize, you have a security hole.
Raw source belongs in the database and exports. If you convert Markdown to HTML on save, search indexing, plain-text exports, and source revision diffs turn into a noisy mess of tags. The database should store the text the user actually wrote.
I worked on unifying Notes formatting for the GCD using a shared renderer and nh3 sanitization. The implementation distinguishes full block text from phrasing annotations, shares editor preview and display rules, and keeps stored source and tabular exports untouched. (The Pull Request)
A shared renderer makes formatting consistent; it doesn’t mean every note should accept every tag. Define the contract for each place a field appears before choosing how to render it.
—jhunterj