public/galaxy
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

Initial public release of Warp.

Browse Source 
Repo-Sync-Origin: warpdotdev/warp-internal@12af1d983b
This commit is contained in:
David Stern
2026-04-28 08:43:33 -05:00
commit 0dbd3d567a
4982 changed files with 1431549 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
specs/zachlloyd/markdown-table-consistency/PRODUCT.md
+212
View File
@@ -0,0 +1,212 @@
# Markdown Table Styling Consistency — Product Spec
Linear: none provided
Figma: House of Agents — https://www.figma.com/design/CsBdBW4YoLgSAbr5eSkwV6/House-of-Agents?node-id=7451-99490&t=NvrWl7bhDEC5kpKF-1
Reference styling baseline: PR #23908 — https://github.com/warpdotdev/warp-internal/pull/23908
## Summary
Make rendered Markdown tables use the same blockless visual treatment across every Warp surface that renders Markdown tables.
The block list styling introduced in PR #23908 should become the visual baseline for Markdown tables everywhere they render in Warp, including Markdown notebooks and the Markdown editor. This is a consistency and presentation change, not a redesign of Markdown table semantics or editing behavior.
## Problem
Warp currently renders the same Markdown table with noticeably different visual treatments depending on where the user sees it.
After PR #23908, AI block list tables use a lighter, blockless presentation based on the House of Agents design: no outer container, no full border, no vertical dividers, no filled header row, and more typography-driven hierarchy. Other Markdown-rendering surfaces still use the older table treatment, which creates visible inconsistency in:
- border and container chrome
- row density
- header emphasis
- background fills
- overall visual weight
This makes the same Markdown content feel like different components in different parts of the product. Users moving between notebooks, the Markdown editor, AI documents, comment editors, file notebooks, and AI output should not have to mentally re-parse the same table because Warp styled it differently in each surface.
## Goals
- Make rendered Markdown tables in every current Warp Markdown-rendering surface match the visual treatment now used in the AI block list.
- Treat the merged block list styling from PR #23908 as the visual source of truth for this work.
- Preserve existing Markdown table semantics, supported inline formatting, alignment rules, and editability.
- Preserve existing selection, cursor, link, copy, and scrolling behavior unless a change is required to achieve the styling consistency.
- Ensure the same Markdown table feels like the same component across all Warp Markdown-rendering surfaces.
- Ensure future Warp surfaces that adopt Markdown table rendering inherit this same style by default rather than introducing another table treatment.
## Non-goals
- Changing Markdown table parsing rules or supported syntax.
- Introducing new Markdown table editing capabilities.
- Changing block list table styling again as part of this work.
- Redesigning non-table Markdown blocks.
- Converting non-table text into tables.
- Broadly restyling every table-like UI in Warp outside Markdown-rendered tables.
## Figma / design references
- Figma: House of Agents — https://www.figma.com/design/CsBdBW4YoLgSAbr5eSkwV6/House-of-Agents?node-id=7451-99490&t=NvrWl7bhDEC5kpKF-1
- PR baseline: https://github.com/warpdotdev/warp-internal/pull/23908
- Existing related spec: `specs/blocklist-markdown-table-rendering/PRODUCT.md`
The Figma node shows the blockless table treatment that now exists in the AI block list and should be reused for Markdown tables across Warp.
## User experience
### Scope
This feature applies to rendered GitHub Flavored Markdown tables in:
- Markdown notebooks
- the Markdown editor
- file notebooks and other rendered Markdown file views
- AI documents and other notebook-backed planning/editor surfaces
- Markdown comment editors and other lightweight rendered Markdown editors
- any other current or future Warp surface that renders Markdown tables through the shared Markdown rendering stack or through a dedicated Markdown table renderer
If a Warp surface renders a valid Markdown table as a table, it should adopt the updated styling described here.
This feature does not change the appearance of raw Markdown source when the user is viewing or editing literal source text rather than a rendered table presentation.
### Visual consistency rule
The user-visible rule is simple:
The same valid Markdown table should look materially the same in the AI block list and in every other Warp surface that renders Markdown tables.
The goal is not approximate similarity. The goal is one shared visual treatment for Markdown-rendered tables across these surfaces.
### Styling invariants
Rendered Markdown tables in all Warp Markdown-rendering surfaces should adopt the same structural styling introduced for block list tables in PR #23908.
That means:
- the table renders directly in the Markdown flow rather than inside a card-like or boxed container
- the table does not show a rounded outer container
- the table does not show a full perimeter border
- the table does not show vertical divider lines between columns
- the header row does not use a filled background distinct from the table body
- body rows do not use alternating zebra-striping backgrounds
- the header row uses stronger typography than body rows
- header text uses primary text color
- body text uses secondary text color
- row separators are thin horizontal dividers only
- row spacing matches the block list treatment, with a more open vertical rhythm than the older notebook/editor style
- the table should feel visually lighter and less boxed-in than the previous notebook/editor treatment
The blockless Figma version is the intended design target.
### Typography and spacing
The table should continue to use the surrounding Markdown typography system for font family and sizing, but with the same hierarchy used in the block list treatment:
- headers are bold or semibold and visually prominent
- body cells are regular weight
- body text uses the same size as surrounding Markdown body text
- vertical padding should match the block list style closely, approximately 12px per row
If theme-specific token values differ across surfaces, the relationship must still remain the same:
- header text is visually stronger than body text
- divider lines are subtle
- the table has no filled container or boxed background treatment
### Functional behavior that must remain unchanged
This restyle should not change what Markdown tables mean or how users interact with them.
The following behaviors should remain unchanged unless a specific implementation constraint requires an adjustment:
- valid table detection
- column alignment behavior
- inline Markdown rendering inside cells
- text selection within a cell
- text selection across cells and rows
- cursor placement and text editing behavior in editable contexts
- link rendering and interaction
- copy behavior
- horizontal overflow handling for wide tables
- surrounding Markdown flow before and after the table
This is a styling consistency feature, not a behavior change feature.
### Alignment and inline formatting parity
All currently supported Markdown table content should continue to render correctly after the restyle.
At minimum, every affected Markdown-rendering surface must continue to support:
- left, center, and right column alignment
- bold text
- italic text
- bold-italic text
- inline code
- strikethrough
- links
- escaped pipe characters rendered as literal pipes
- multiline cell content, if already supported today
Changing the visual style must not collapse centered or right-aligned columns back to left alignment.
### Editing contexts
Some Markdown table surfaces are editable and some are read-only. The restyle must not make editing feel worse anywhere editing is supported today.
If a user can place a cursor in a rendered table cell today, they should still be able to do so after the change.
If a user can:
- click into a cell
- move the cursor with keyboard navigation
- select text across table content
- type, delete, or paste within the table
those interactions must continue to work with the new styling.
The visual update must not reduce hit targets, make selections harder to read, or create ambiguity about which cell is active.
### Wide tables
Wide tables should remain readable and usable.
If a table requires horizontal overflow handling, the updated styling must preserve the user’s ability to:
- access off-screen columns
- read header and cell content clearly
- select text after horizontally scrolling
- edit content in editable surfaces if that behavior is supported today
This feature should not introduce clipping, truncation, or layout breakage that did not exist before.
### Invalid or unsupported table-like content
This feature does not change fallback behavior.
If content is not a valid Markdown table and currently falls back to normal Markdown text rendering, it should continue to do so. Likewise, table-looking content inside code blocks should continue to render as code, not as a table.
### Existing and newly rendered content
The updated style should apply consistently to:
- newly created notebooks and documents
- existing notebooks and documents when reopened
- tables already present in saved content
- new tables inserted after the feature ships
- any current or future surface that renders Markdown tables once it adopts the shared renderer or shared style source
Users should not have to migrate or rewrite table Markdown to get the new treatment.
## Success criteria
- A Markdown table rendered in any current Warp Markdown-rendering surface uses the same blockless styling pattern as the AI block list table from PR #23908.
- Warp no longer shows two competing visual treatments for rendered Markdown tables across its current Markdown surfaces.
- Other Markdown-rendering surfaces no longer show the older table chrome such as a full outer border, vertical dividers, zebra striping, or a filled header background.
- Header rows remain visually distinct through typography and text color rather than heavy background treatment.
- Body rows use secondary text color and subtle horizontal separators, matching the block list treatment.
- The same Markdown table shown in the AI block list and in other Warp Markdown-rendering surfaces looks materially identical aside from surface-specific typography or layout constraints.
- Alignment behavior remains correct for left-, center-, and right-aligned columns.
- Inline Markdown inside cells continues to render correctly.
- Editing and selection behavior in editable Markdown surfaces does not regress.
- Wide tables remain usable and readable.
- Invalid Markdown table input continues to fall back to existing non-table behavior.
## Validation
- Manual validation with the same Markdown table rendered in the AI block list and in multiple editor-backed surfaces, including:
- AI block list
- Markdown notebook
- Markdown editor
- Spot-check validation in other current Markdown-rendering surfaces that use the shared rich-text Markdown renderer, such as AI documents, file notebooks, and comment editors where practical.
- Visual comparison against the Figma node and the current AI block list implementation from PR #23908.
- Manual validation that affected Markdown-rendering surfaces no longer show an outer border, vertical dividers, zebra striping, or a filled header row.
- Manual validation that header typography, body text color, divider treatment, and row spacing match the block list treatment closely.
- Manual validation of left-, center-, and right-aligned columns.
- Manual validation of inline formatting inside cells: bold, italic, bold-italic, inline code, strikethrough, links, and escaped pipes.
- Manual validation of cursor placement, selection, typing, deletion, and paste behavior in editable contexts.
- Manual validation of wide tables that require horizontal scrolling.
- Regression validation that malformed table-like content and fenced code blocks continue to avoid table rendering.
- Screenshot-based review confirming that the editor-backed result is visually consistent with the merged block list result.
## Open questions
None currently. New Warp surfaces that render Markdown tables should inherit this style by default.
specs/zachlloyd/markdown-table-consistency/TECH.md
+255
View File
@@ -0,0 +1,255 @@
# Markdown Table Styling Consistency — Tech Spec
Product spec: `specs/zachlloyd/markdown-table-consistency/PRODUCT.md`
## Problem
PR #23908 updated AI block list Markdown tables to the new blockless visual treatment, but the rest of Warp’s Markdown table renderers still use the older boxed table styling. On the current branch, Markdown table appearance is owned by two separate rendering paths:
- editor-backed Markdown surfaces use `RichTextStyles.table_style`
- AI block list tables build a separate WarpUI `TableConfig` inline
That split creates two technical problems:
1. the shared editor-backed renderer still paints outer borders, vertical dividers, filled header backgrounds, and alternating row backgrounds
2. future surfaces can drift again because there is no single shared source for Markdown table chrome
The implementation should make every current Markdown table renderer inherit the same structural style while preserving surface-specific typography and existing editing/selection behavior.
## Relevant code
- `specs/zachlloyd/markdown-table-consistency/PRODUCT.md` — approved product behavior
- `specs/blocklist-markdown-table-rendering/TECH.md` — prior AI block list table implementation plan
- `app/src/notebooks/editor/mod.rs (145-215)` — `rich_text_styles`; current shared editor-backed table style source
- `crates/editor/src/render/model/mod.rs (424-568)` — `RichTextStyles` and `TableStyle`
- `crates/editor/src/render/element/table.rs:1-220` — editor-backed Markdown table painting path
- `app/src/ai/blocklist/block/view_impl/common.rs (1140-1270)` — `render_table_section`; current AI block list table renderer and inline `TableConfig`
- `crates/warpui_core/src/elements/table/mod.rs (117-239)` — shared `TableConfig`, `RowBackground`, and `TableVerticalSizing`
- `crates/warpui_core/src/elements/table/mod.rs (537-759)` — intrinsic width measurement logic
- `crates/warpui_core/src/elements/table/mod.rs (1013-1211)` — viewported row layout and painting behavior
- `app/src/notebooks/file/mod.rs (230-278)` — file notebook view using `rich_text_styles`
- `app/src/ai/ai_document_view.rs (292-321)` — AI document view fallback editor using `rich_text_styles`
- `app/src/ai/document/ai_document_model.rs (783-801)` — AI document model creating notebook-backed editors with `rich_text_styles`
- `app/src/code/editor/comment_editor.rs (505-544)` — comment editor using `rich_text_styles`
- `app/src/code/editor/view.rs (2357-2381)` — `code_text_styles`; clones `rich_text_styles` before overriding non-table text settings
## Current state
### Editor-backed Markdown tables
Most rendered Markdown surfaces in the app are backed by `NotebooksEditorModel` and the shared editor renderer. Their table appearance comes from `rich_text_styles()` in `app/src/notebooks/editor/mod.rs`, which currently sets:
- `border_color = theme.surface_3()`
- `header_background = theme.surface_2()`
- `cell_background = theme.background()`
- `alternate_row_background = Some(theme.surface_2())`
- `cell_padding = 6.`
That style is then consumed by `RenderableTable` in `crates/editor/src/render/element/table.rs`. The renderer currently always paints:
- row backgrounds for header and body
- an outer top/bottom/left/right border
- horizontal row dividers
- vertical column dividers
This is the old notebook/editor table treatment that the new product spec wants to replace.
### Surfaces that inherit the editor-backed table style
The old table style is not limited to notebooks. The same `rich_text_styles()` entry point is reused by multiple surfaces:
- notebooks
- file notebooks
- AI documents / planning docs
- Markdown comment editors
In addition, `code_text_styles()` starts from `rich_text_styles()` before overriding paragraph-level settings, so any code-editor surface that ends up rendering Markdown tables also inherits the same table style unless it explicitly overrides it.
This means a change to the shared editor-backed style source will propagate to multiple surfaces automatically.
### AI block list tables
The AI block list no longer uses the old style. `render_table_section()` in `app/src/ai/blocklist/block/view_impl/common.rs` builds a WarpUI `Table` with an inline `TableConfig` that already matches the desired structural treatment:
- `outer_border: false`
- `column_dividers: false`
- `row_dividers: true`
- transparent header/background fills
- `cell_padding: 12.`
- `TableVerticalSizing::ExpandToContent`
- `measure_body_cells_for_intrinsic_widths: true`
That renderer is already the visual baseline from PR #23908, but it is defined inline inside the block list path rather than shared with editor-backed renderers.
### Ownership problem
Today there is no shared “Markdown table appearance” abstraction. The editor-backed path and block list path both describe the same visual decisions in different structures:
- `TableStyle` for the editor renderer
- `TableConfig` plus per-cell text styling for WarpUI `Table`
As a result:
- the two renderers can drift
- future surfaces may pick one path and forget to copy the latest style
- structural decisions like “no outer border” or “no column dividers” are not represented in the editor-backed style model yet
## Proposed changes
### 1. Introduce a shared Markdown table appearance helper
Add a small shared helper at the app layer that defines the canonical Markdown table chrome for the new blockless treatment.
The helper should represent the structural and color decisions that must stay aligned across renderers:
- divider color
- header text color
- body text color
- transparent vs filled backgrounds
- whether outer borders are shown
- whether column dividers are shown
- whether row dividers are shown
- row striping behavior
- cell padding
Typography should remain surface-specific. The helper should define the table chrome and text-color hierarchy, not force every surface to use the same font family or font size.
This gives us one source of truth that both renderers can map from.
### 2. Extend `TableStyle` so the editor renderer can express the blockless treatment
`crates/editor/src/render/model/mod.rs` currently cannot represent some of the structural choices already used by the block list renderer.
Extend `TableStyle` with the missing structural controls needed by the product spec:
- `outer_border: bool`
- `column_dividers: bool`
- `row_dividers: bool`
Keep the existing color and typography fields. The important change is letting the editor-backed renderer express “only horizontal separators, no outer border, no vertical dividers” directly instead of baking those assumptions into painting logic.
### 3. Update the editor-backed table painter to honor the expanded style model
Update `crates/editor/src/render/element/table.rs` so painting follows `TableStyle` rather than hardcoded table chrome assumptions.
Specifically:
- `paint_backgrounds()` should respect transparent header/body backgrounds and the absence of alternating row backgrounds
- `paint_borders()` should paint only the borders/dividers enabled by `TableStyle`
- the renderer should continue using the existing text layout, selection, cursor, and alignment logic unchanged
This keeps the behavioral parts of the editor renderer stable while changing only the visual treatment.
### 4. Make `rich_text_styles()` produce the new Markdown table style
Update `app/src/notebooks/editor/mod.rs` so `rich_text_styles()` returns the blockless Markdown table style from the new shared helper.
That means the shared editor-backed path should move from the current boxed style to:
- no outer border
- no column dividers
- row dividers only
- transparent header background
- transparent body background
- no alternating row backgrounds
- header/body text colors matching the block list hierarchy
- cell padding aligned with the block list treatment
This change is the main propagation point for notebooks, file notebooks, AI documents, comment editors, and any other surface using the shared editor-backed Markdown renderer.
### 5. Refactor the block list table renderer to consume the same shared appearance helper
Update `app/src/ai/blocklist/block/view_impl/common.rs` so the block list no longer constructs its structural table chrome entirely inline.
The block list should still keep its surface-specific text settings where needed:
- AI font family
- AI font size
- AI font weight
- AI selection color
But the structural table configuration should come from the same shared appearance helper used by `rich_text_styles()`. That keeps the existing block list result visually unchanged while preventing future drift.
### 6. Preserve surface-specific typography
The product goal is shared styling, not identical typography across unrelated surfaces.
The shared appearance helper should therefore be mapped differently by each renderer:
- editor-backed surfaces continue using their surface’s `font_family` / `font_size` in `TableStyle`
- block list continues using its AI-output text settings
What must remain shared is the blockless table chrome and the text hierarchy relationship, not every literal font token.
### 7. Treat the shared helper as the default for future Markdown table renderers
Document in the code by naming and placement that this helper is the default source for Markdown table appearance in Warp.
The goal is that a new Markdown-rendering surface should not invent its own `TableConfig` or `TableStyle` values for tables unless it has a clear product reason to diverge.
## End-to-end flow
1. A surface creates a rendered Markdown editor or table view.
2. If it is editor-backed, it obtains `RichTextStyles` from `rich_text_styles()` or `code_text_styles()`.
3. `rich_text_styles()` builds `table_style` from the shared Markdown table appearance helper.
4. The editor renderer lays out and paints table content using the updated `TableStyle`, which now supports the blockless chrome.
5. If it is the AI block list path, `render_table_section()` builds its WarpUI `Table` using the same shared appearance helper, while keeping block-list-specific typography and selection settings.
6. The user sees the same structural Markdown table treatment across surfaces, with existing interaction behavior preserved.
## Risks and mitigations
### Risk: editor-backed behavior regressions
Changing `RenderableTable` painting could accidentally affect selection visibility, cursor readability, or perceived cell hit areas.
Mitigation:
- keep layout, selection, cursor, and alignment code unchanged
- scope the change to styling and border/background painting
- validate editable surfaces manually after the visual update
### Risk: block list drifts again later
If the block list keeps hand-authoring its own `TableConfig`, the two renderers can diverge again even after this change.
Mitigation:
- refactor both paths to read from the same shared appearance helper
- avoid leaving structural table chrome duplicated inline
### Risk: future surfaces bypass the shared style
Even after current surfaces are fixed, a new renderer could hardcode another table style.
Mitigation:
- make the helper discoverable and clearly named as the canonical Markdown table appearance
- reference it directly from both existing rendering paths so future work sees the pattern
### Risk: typography becomes unintentionally identical everywhere
If the shared helper carries too much font data, it could flatten legitimate surface-specific typography differences.
Mitigation:
- keep the helper focused on chrome and text hierarchy
- let each renderer keep its own font family, size, and weight choices where appropriate
## Testing and validation
### Shared-style tests
- Add focused tests for the shared Markdown table appearance helper so its structural defaults are explicit:
- no outer border
- no column dividers
- row dividers enabled
- transparent backgrounds
- no alternating row striping
- updated padding
### Editor-backed renderer coverage
- Add or update tests around editor-backed Markdown tables to ensure table rendering still occurs and existing Markdown table behavior does not regress.
- Keep existing geometry/selection-oriented table tests in `crates/editor/src/render/element/table_tests.rs` passing after the style changes.
### Surface propagation checks
- Manual validation in:
- Markdown notebook
- Markdown editor
- file notebook
- AI document / planning document
- Markdown comment editor
- AI block list
- Confirm these surfaces all show the same blockless table chrome.
### Behavior regression checks
- Manual validation of:
- left/center/right alignment
- inline formatting inside cells
- cursor placement in editable contexts
- selection within and across cells
- link rendering and interaction
- wide-table overflow handling
### Visual validation
- Screenshot-based comparison against the Figma node and the AI block list implementation from PR #23908
- Manual confirmation that the older notebook/editor chrome is gone everywhere in scope
## Follow-ups
- If additional Markdown table renderers appear outside the current editor-backed path and block list path, route them through the shared appearance helper rather than creating another table style definition.
- If we later want stricter visual parity between surfaces, we can consider a deeper shared text-style adapter, but that should be a follow-up after the chrome is unified.