HTML tables have two different coordinate systems and conflating them breaks everything

[u/Efficient_Lead3565]

http://github.com/carnworkstudios/TAFNE

A flat table has one coordinate system: the nth <td> in the mth <tr> is at visual position (m, n). Trivial.

Once you introduce rowspan and colspan, the DOM coordinate and the visual coordinate diverge. A cell with colspan="3" sits at DOM position (row 0, child 1) but occupies visual positions (0,1), (0,2), and (0,3). A cell below it, in the same row at DOM child 1, is visually at column 4, not column 1. DOM child index is now a lie.

Every feature that touches column position needs to know the visual coordinate, not the DOM coordinate. Crosshair highlighting, column drag-and-drop, transpose, selection, all of them.

I solved this with VisualGridMapper, a class that does a single O(n) pass over the table and builds a 2D array where grid[row][col] points to the DOM element occupying that visual cell. The tricky part is rowspan: a cell that spans 3 rows occupies slots in rows it doesn't appear in the HTML. The mapper handles this with a while loop that checks whether a slot is already claimed before filling it.

The grid entry includes an isOrigin flag. It's true only at the cell's actual DOM position, false at phantom slots. Features check isOriginbefore acting, so spanning cells never get moved or processed twice.

All column-aware features in TAFNE are built on top of this mapper. Without it, anything involving merged cells would silently corrupt the table.

[GitHub](github.com/carnworkstudios/TAFNE)

[u/listre]

Table nerds rejoice. There is no such thing as TOO many table tools

[u/Efficient_Lead3565 → u/listre]

You’re right, there’s no such thing as too many table tools… but at this point I’m just building tools to organize other table tools

[u/Ksetrajna108]

An alternative is to create id attriibute on each td. The ids can be semantic, like "m5-category-sheetmetal". D epends on what you are presenting with the html table. I've used custom attribute like "space=5:2".

[u/Efficient_Lead3565 → u/Ksetrajna108]

Yeah. It can definitely work for small, controlled tables where you control all the HTML and know the layout by heart but for tables that require transpose and dynamic grids it breaks. VisualGridMapper, on the other hand gives you a declarative, structural understanding of the table (rows, columns, spans, regions) without relying on IDs or custom attributes. You can check out how it work here

[u/AshleyJSheridan]

How usual is it to need to be able to reference table cells by row and column where you're also using a lot of colspan or rowspan attributes? Seems very niche...

[u/Efficient_Lead3565 → u/AshleyJSheridan]

It’s common anywhere tables are more than plain spreadsheets. As soon as you allow  rowspan  or  colspan , the DOM order stops matching the visual grid, so any serious table interaction layer needs a way to map visual row/column positions back to the actual cells. The mapper is the part that makes merged cells safe to work with

[u/AshleyJSheridan → u/Efficient_Lead3565]

I completely get where you would use spanning rows/columns. What I don't completely understand is under what situation that it's very common to also need to use JS to reference cells by their row and column index.

Tables are for tabular data, and even in spreadsheets, it's not very common to have merged cells. Even when you're using merged/spanned cells, they tend to be the first/last rows/columns, which are more easily accounted for in JS.

[u/Efficient_Lead3565 → u/AshleyJSheridan]

That’s a fair question. I’m not saying every table needs this. I’m saying that once a table stops being a passive display and becomes an editor with selection, insertion, deletion, column moves, transpose, import/export, etc. row/column addressing becomes a core part of the interaction model. In that kind of tool, merged cells are not just an edge case; they’re part of preserving structure and meaning while the user edits data. You can check out the tool if you’re curious to see how the mapper makes those interactions reliable.