Writing documents via API: no way to control table column widths (and embedded views are lost)

Ideas & Features
1

Context

We generate and maintain Fibery documents programmatically — project profiles, customer briefs, status docs — from data that lives partly in Fibery and partly outside. That works well, with two exceptions that both come down to the same root cause: the document write path only accepts Markdown, while the document model itself is richer than Markdown.

1. Table column widths cannot be set

Reading a document as HTML shows that column widths are part of the stored model:

<td data-colwidth="314"><p><strong>Name</strong></p></td>
<td data-colwidth="611"><p>Role</p></td>

But writing accepts Markdown only, and a Markdown table produces <td> elements without data-colwidth. Columns then size to their content, so a single cell with a long sentence stretches that column and the table overflows horizontally.

In a document we generated this week, 14 of 142 table cells were longer than 120 characters (the worst was 783). Those cells are legitimate content — an ERP integration description, a project goal — and shortening them just to keep the layout intact means degrading the document to fit the tooling.

Passing HTML into the write path does not help: it is escaped and stored as a literal text paragraph rather than parsed.

The practical consequence is worse than the layout itself: column widths fixed by hand in the UI are destroyed the next time the document is regenerated. So a generated document can never be regenerated idempotently without a human redoing the layout every time. For anyone automating document upkeep, that turns a one-off cost into a recurring one.

2. Embedded views and column layouts don’t survive a write

Same root cause, bigger impact for us. We have a document template whose sections embed live views:

<div class="fibery-columns-node">
  <div class="fibery-column-node">
    <h3>Milestones</h3>
    <div contenteditable="false" data-view-id="62a31789-..."></div>
  </div>
</div>

Reading the document returns those embeds as [???] in Markdown. Writing Markdown back removes them permanently — the two-column layout and all four embedded views are gone, and there is no Markdown representation to preserve them.

This makes the natural pattern impossible: design a template once in the UI, fill it programmatically per customer. Today, filling a template via API means destroying the template.

What would help

In rough order of preference:

  1. Accept HTML on the write path, i.e. round-trip parity with format=html on read. Then data-colwidth, data-view-id embeds and column nodes all survive, and no new API surface is needed — the format already exists on the read side.
  2. Or: preserve non-Markdown nodes on a Markdown write — treat view embeds, column layouts and existing column widths as structure to keep rather than content to replace.
  3. Or, as a much smaller step for the table case alone: support explicit column widths in the Markdown we send (a colgroup-style directive or a per-table comment marker), or let a document table be set to wrap/fit rather than size-to-content.

Even option 3 alone would remove the recurring manual step.

Happy to share the exact documents and payloads if that’s useful. One caveat: we drive the API through an MCP server, so if any of the above is a limitation of that wrapper rather than of the API itself, I’d be glad to be corrected.