Problem / current situation

Component documentation is one of the main things a developer reads when deciding whether to adopt a Forge component, so its quality directly affects component discovery and adoption. Today the documentation editor is too limited to express real technical documentation. Its toolbar only supports bold, italic, underline, lists and links, with no headings, code blocks or tables.

As a result, structured content collapses at authoring time. A parameter-mapping table (Parameter / Source in JSON / Description) is flattened into a single run-on line of bold text, section titles become plain bold text with no real hierarchy, and code samples lose their formatting. The published page faithfully reflects the editor, so this is not a rendering bug; the editor simply cannot hold the structure that good documentation needs.

The authoring editor: no headings, tables or code blocks available.

The published result: faithful to the editor, but flattened.

Proposed solution

Let publishers author documentation in Markdown. A minimal first step already solves most of the pain:

       1. Upload a .md file, rendered directly as the documentation.

And, building on that:

       2. A Markdown editing mode in the editor, with raw input and live preview.

Why this matters

• Better, more consistent documentation lowers the barrier to adopting Forge components, which is the whole point of the Forge.
• Markdown provides the structural elements the current editor lacks (headings, tables, fenced code blocks), which are exactly what documentation depends on.
• Markdown is the de facto standard for technical documentation, so most publishers already have content in that format and think in it natively.

Nice-to-haves

• If the component has a linked repository, read its README.md as the documentation.
• Keep the current rich editor available, with Markdown as an additional option rather than a replacement.