Intuitive Table Cell Merging Syntax using `<` and `>` (Spreadsheet-like UX)

Feature requests
, ,
1

Use case or problem

Currently, Markdown tables do not support cell merging (colspan/rowspan) in the standard GFM/CommonMark spec. While some workarounds exist (including community plugins), they often use unintuitive syntax, break the visual structure of raw text, or rely on complex HTML tags that are difficult to write and maintain, especially on mobile devices.

I believe table cell merging should be a core feature with an intuitive, spreadsheet-like syntax that makes the merge range immediately visible in the raw markdown.

Proposed solution

Syntax: Visual Range Markers (< and >)

I propose a “Visual Range-based Merging” syntax using simple < and > symbols within standard table cells. This mimics the “selection range” experience of spreadsheets.

Logic: Place < at the start of the first cell of the range, and > at the end of the last cell.

Example 1: Horizontal merge (colspan)

|< Header spans | two columns >| Column 3 |
|----------------|--------------|----------|
| Cell 1         | Cell 2       | Cell 3   |

Example 2: Vertical merge (rowspan)

|< Start |
| Middle  |
| End >|

(Cells in the same column between < and > markers merge vertically)

Example 3: 2D area merge

|< Top-left    | Top-right    |
| Bottom-left   | Bottom-right >|

Real-world Example: Product Comparison Table

| Feature      |< Free Tier        >| Premium |
|--------------|---------------------|---------|
| Storage      | 5GB                 | 100GB   |
|< Support    | Email Only          |         |
| Response Time| 48h                 | 1h >|

Key Advantages:

  1. Backward Compatibility: Standard parsers see these symbols as plain text. It doesn’t break existing notes or non-Obsidian viewers.
  2. Data Integrity: Users can keep text in each cell within the markers; the renderer simply combines them.
  3. Intuitive UX: It visually represents the “boundary” of the merged area, making the raw markdown readable at a glance.
  4. Lightweight Parsing: The start-to-finish logic is computationally efficient for real-time rendering.
  5. Mobile-friendly: Much easier to type < and > than complex HTML or special markdown extensions.

Parsing Rules:

  1. Find matching < and > pairs in table cells
  2. Horizontal: Same row → colspan
  3. Vertical: Same column index → rowspan
  4. 2D: Rectangle defined by top-left < and bottom-right >
  5. Cell content from all merged cells is concatenated

Edge case handling:

  • Unmatched markers are treated as plain text
  • Overlapping ranges: First match wins (left-to-right, top-to-bottom)

Current workaround (optional)

  • Using raw HTML <table>, <tr>, <td> tags with colspan and rowspan (Extremely tedious, especially on mobile)
  • Using community plugins like “Sheets Basic” or “Advanced Tables” - while functional, these use less intuitive syntax and remain as plugin-only solutions rather than core functionality

Related feature requests (optional)

  • Mini Plugin Sheets Basic: Merge Markdown Table Cells - Existing plugin with table merge functionality. This proposal offers an alternative syntax that is more intuitive and suitable for core feature implementation.
2

To avoid any ambiguity with normal text (like “A < B”), I’ve refined the syntax to use |< and >|.

By leveraging the existing pipe boundaries, this becomes a clear table-scoped marker. It keeps the same range-based logic while ensuring the parser can instantly distinguish formatting from data.

Example 2 (Vertical Merge):

| Header |
| :---: |
||< Vertical |  <-- Start
|   Merge  >||  <-- End

It’s cleaner, safer, and follows the “One Symbol, One Role” rule. What do you think?