RSS

Nested Tables From Confluence to SharePoint

How WikiTraccs handles nested tables - what is kept, what is denested, and why.
By Heinrich Ulbricht |

Note: Nested-table support is available as of WikiTraccs v1.30.25, released in late September 2025.

Confluence lets editors put tables inside table cells. SharePoint pages, on the surface, do not. This post explains what WikiTraccs does about that, and the tradeoffs behind it.

TL;DR

  • WikiTraccs keeps small nested tables nested where it can, and denests large ones where it has to.
  • The behavior is gated by the Use non-standard table transformation Gray Setting (on by default).
  • Denested tables are moved below the parent table and the original location gets a numbered marker so the relationship stays readable.

Background

Confluence supports nested tables out of the box. Migrating those was a long-standing pain point.

The SharePoint Pages browser editor does not expose nested tables in its toolbar - users cannot create them by clicking buttons. But the SharePoint Text web part can store and render nested tables correctly. Word also produces them when you paste nested tables to SharePoint.

WikiTraccs makes use of that gap: it creates nested tables that SharePoint saves and shows correctly, even though a user could not build the same thing by clicking around in the editor. That is the Gray Setting idea.

What Counts as a Nested Table

  • A <table> element living inside a <td> of another table.
  • Common sources in Confluence:
    • Tables an author actually nested by hand.
    • Section / Column macros - WikiTraccs maps those to tables, which can put the user’s own tables inside.
    • Panel / Info / Note / Warning / Tip macros - the macro is rebuilt as a table, and any table content inside lands nested.
    • Any custom macro that wraps content into a table-shaped layout.

When WikiTraccs Keeps a Table Nested

WikiTraccs decides per nested table whether keeping it in place would still produce a readable SharePoint page.

The decision weighs a handful of factors: how many columns the nested table has, how much text and how many images sit in its cells, how wide the parent table already is, and how deep the overall nesting goes.

Small, narrow tables with little content tend to stay nested. Wide tables, content-heavy tables, and tables that pile up inside an already wide parent tend to be moved out so the parent table’s columns don’t get squeezed into unreadable widths.

The exact thresholds are tuned over time and may shift between releases. The intent is stable, though: keep the structure where SharePoint can render it cleanly, denest where it cannot.

When WikiTraccs Denests

A nested table gets denested when:

  • The Use non-standard table transformation setting is off.
  • The thresholds above are exceeded, in which case denesting prevents a layout collapse.

What that looks like on the page:

  • The nested table is moved out so it sits right after the table it used to live inside.
  • In the original cell, a short note like “Nested table 1 moved here:” is left behind, so it’s clear where the moved table came from.
  • If several tables are moved out from the same area, they are numbered, so the notes and the tables below match up.

Configuration

  • Settings -> Migration tab -> Use non-standard table transformation (Gray Setting, on by default). Off means everything is denested, like the pre-v1.30 behavior.
  • Skip table size optimization (Misc tab) is independent. It controls browser-based column width measurement; nesting decisions still apply either way.

Wrap

Nested tables used to always be denested. Today, small ones stay nested and only the ones that don’t fit get moved out.

The behavior is on by default, gated by a Gray Setting, and you can fall back to the old always-denest behavior by turning that setting off.

If you want to trace which tables were moved where after migration, watch for the placeholder markers in the cells they used to live in.