Markdown viewer: support common raw-HTML subset (img sizing, tables, details, anchors)

[fbartho]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

Warp's Markdown Viewer should support the common subset of raw inline HTML that real-world repo markdown relies on (this is standard practice under GitHub Flavored Markdown, and is what GitHub, GitLab, and most other markdown renderers already support). Today the viewer renders plain Markdown syntax reasonably well, but silently drops or ignores raw HTML tags, which breaks a lot of READMEs, docs, and notes that use HTML for layout control that Markdown syntax alone can't express.

Prioritized list of tags, most important first:

1. <img> with width / height / align — sizing control for images. This is the one that bit me directly (see repro below).
2. <a href="…"> and <a id="…"> — links, plus named anchors used as deep-link targets for hand-built tables of contents.
3. Tables: <table> / <thead> / <tbody> / <tr> / <th> / <td> — needed for cells that require a line break (<br>) or a colspan/rowspan, which Markdown table syntax cannot express at all.
4. <details> / <summary> — collapsible sections, extremely common in READMEs, changelogs, and bug-report templates (including this repo's own issue templates elsewhere on GitHub).
5. <br> — explicit line breaks, most often needed inside table cells.
6. <kbd> — keyboard-shortcut styling. Feels especially on-brand for a terminal app's own markdown viewer.
7. <sub> / <sup> — subscript/superscript.
8. <p align="center"> / <div align="center"> — centered "hero" headers, very common at the top of README files.
9. <picture> / <source media="(prefers-color-scheme: …)"> — light/dark logo variant swapping, standard pattern for README badges/logos.

I'd be happy to see this land as "the common subset above," even if full arbitrary-HTML rendering (with all its sanitization complexity) is out of scope.

Is your feature request related to a problem? Please describe.

I'm always frustrated when I write locally-generated SVG dashboards into my Markdown notes and Warp's viewer won't let me size them.

Concretely, today in Warp's Markdown Viewer (verified on this build):

Works, but not usefully — renders the image at a small fixed width that ignores the SVG's intrinsic width/height, and does not scale when the pane or document is resized:

![Pipeline Funnel](assets/chart.svg)

Does not render at all (expected: image displayed at 90% of the pane width):

<img src="assets/chart.svg" alt="Pipeline Funnel" width="90%">

Since the Markdown-image renderer ignores the SVG's own intrinsic dimensions, the HTML width attribute is the only author-controllable sizing signal available — and Warp currently drops it, so there is no way to control image size at all short of re-encoding the SVG itself.

Two more everyday examples that currently don't render, both very common in repo docs:

<details>
<summary>Click to expand</summary>

Hidden content here, only shown when expanded.

</details>

Press <kbd>Cmd</kbd>+<kbd>K</kbd> to open the command palette.

Additional context

• Motivating use case: I generate SVG dashboards locally (charts, funnels, etc.) and embed them in Markdown notes for later reference. Without HTML width/height support, there's no way to size these embedded charts sensibly inside the viewer.
• This is a distinct request from "render a full embedded browser/webview" (e.g. Feature Request: Integrated Browser Panel (WebView) in Warp #8548, Built-in browser panel inside Warp #9194) — I'm not asking for arbitrary script execution or a browser engine, just for the Markdown renderer to handle the same safe, static HTML subset that GitHub's own Markdown renderer supports.
• Environment: Warp 0.2026.07.01.09.21.01 on macOS 27.0.

Operating system (OS)

macOS

How important is this feature to you?

3

[oz-for-oss]

@fbartho

Here's what I found while triaging this issue:

This looks like a Markdown Viewer enhancement rather than a macOS-specific regression. The report includes enough examples and environment detail for initial triage; the remaining work is defining a safe supported HTML subset and rendering behavior.

Maintainer details

I concluded that feature request for Warp's Markdown Viewer to support a safe raw-HTML subset used by common repository Markdown, especially HTML image sizing..

Triage summary

This is an enhancement request for the Markdown Viewer to support a scoped, safe subset of raw HTML commonly used in repository Markdown. The strongest motivating case is HTML <img> support with sizing attributes (width, height, and align), because the current Markdown-image path gives the user no author-controlled sizing for the SVG dashboard example.

Evidence and current behavior

• The reporter provided concrete examples for Markdown image syntax, HTML <img width="90%">, <details>/<summary>, and <kbd>.
• Current code supports block-level Markdown images via parse_image in crates/markdown_parser/src/markdown_parser.rs, which becomes FormattedTextLine::Image / BufferBlockItem::Image and is rendered by crates/editor/src/render/element/image.rs.
• The image layout path creates an ImageBlockConfig from the viewport width and a default height in crates/editor/src/content/edit.rs; it does not receive HTML-derived width/height/align attributes.
• The Markdown inline parser handles Markdown syntax, HTML entities, and a narrow special-case <u> token, but does not parse general raw HTML tags into renderable Markdown Viewer structures.
• crates/markdown_parser/src/html_parser.rs is a separate HTML-to-FormattedText parser used for rich HTML-style input and supports only a limited set of text/list/code/header/link styles. It explicitly skips or flattens several top-level elements, and does not model <img>, <details>, <summary>, <kbd>, <picture>, or table attributes such as colspan/rowspan.

Likely implementation area

This likely needs a product/technical scope decision rather than a narrow bug fix: define the supported and sanitized raw-HTML subset, extend the parser/model where needed, and add renderer support for the requested tags/attributes. The main implementation areas are the markdown parser/model (crates/markdown_parser/src/markdown_parser.rs, crates/markdown_parser/src/lib.rs), any reusable safe HTML parser behavior (crates/markdown_parser/src/html_parser.rs), buffer conversion (crates/editor/src/content/core.rs, crates/editor/src/content/text.rs), layout (crates/editor/src/content/edit.rs, crates/editor/src/render/model/mod.rs), and render elements such as images/tables/details/KBD styling.

Duplicate check

I scanned open issues across the repository and found related requests, but not enough likely duplicates to mark this as a duplicate. The closest partial overlap is #10259, which only covers <details>/<summary>. Broader markdown-rendering requests such as #9024 and #10574 overlap in surface area but do not request the same raw-HTML subset, especially HTML image sizing.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[fbartho]

Cross-referencing the sibling reports filed alongside this one: #13658 (markdown viewer serves stale embedded local images — root-cause analysis included) and #13657 (rendered SVG/image viewer panel). Spec PR for this issue's top-priority <img> slice: #13656.

[fbartho]

Disclaimer: This is my first time contributing to Warp with Oz involved.

Please let me know if you would have preferred a single Spec PR that covered all the tag types, or if I have other defects that I can improve going forwards.

Assuming my <img> Spec PR gets approved, I would follow-on with Spec PRs for each of the additional tags, and then PRs to implement every tag?

What is the next step here?