Inline Cell Bulk-Edit Table — contenteditable Cells with a Floating Save Bar

Most editable-table patterns fall into two camps: a full "edit mode" toggle that locks the whole row, or a modal that opens per-row for editing one record at a time. This snippet takes a third approach that scales better for quick multi-field corrections: every cell is directly editable via contenteditable, and a floating save bar tracks how many cells have changed across the *entire table* — not just one row — letting a user fix several fields in several different rows and commit them all as one batch.

Tracking dirty state per cell, not per row

On load, every .cell element's original text is captured into a Map keyed by the DOM node itself: originalValues.set(cell, cell.textContent). On every input event, the current text is compared back against that stored original — if they differ, the cell gets a .dirty class (a small amber dot and background tint); if a user types something and then types it back to the original value, the dirty state clears automatically, since the comparison is against the *original* value, not "has this cell ever been touched."

Why the save bar counts cells, not rows

updateBar() queries .cell.dirty across the whole table and shows that count in the floating bar — "3 unsaved changes" might mean three fields in one row, or one field each in three different rows. This framing matches how someone actually works through a spreadsheet-like table: fixing individual field values here and there rather than deciding to edit specific whole rows.

Committing vs discarding

"Save changes" copies every dirty cell's current text back into the originalValues map and clears its dirty flag — in a real integration, this is also where a batched PATCH request to a backend would fire before clearing the flags. "Discard" does the reverse: it resets every dirty cell's textContent back to the value stored in the map, immediately reverting all unsaved edits table-wide with a single click.

Enter to confirm, not to insert a newline

Because table cells are single-line values, the keydown handler intercepts Enter and calls .blur() on the focused cell instead of letting contenteditable insert a line break — so pressing Enter reads naturally as "I'm done editing this cell" rather than corrupting the value with an embedded newline.