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.

2

The API does actually allow read/write with 3 formats (markdown, html or json) and we are working to improve MCP so that it can work more effectively with rich text. Keep your eyes peeled for releases related to this in the coming weeks