Hot Take: You Don't Need a Canvas to Build a Document CAD Editor

TLDR

Reaching for HTML5 canvas libraries (Fabric.js, Konva) to build drag-and-drop document editors introduces unnecessary spatial coordinate tracking, manual collision detection, and lossy export serialization. A rendered HTML document is already a complete CAD layout engine: getBoundingClientRect() supplies spatial coordinates, CSS Grid manages multi-column reflow, and DOM insertBefore handles reordering without breaking document structure.

Editing Engine Choice	Spatial Coordinate System	Multi-Column Reflow	Downstream Export (HTML / MD)
Canvas Overlay Layers	Custom JS Coordinate Math	Manual coordinate calculations	Lossy (Fails to map semantic HTML)
Native DOM Box Model	Browser getBoundingClientRect()	Native CSS Grid Reflow	100% Clean Semantic Output

---

Architectural analysis: flow reordering vs. Absolute positioning

The absolute positioning trap

Drag-to-position implementations assign absolute pixel coordinates to dragged elements:

/ DEFECTIVE: Lifting elements into absolute positioning breaks document flow /
.element {
  position: absolute;
  left: 240px;
  top: 520px;
}

Elements removed from document flow fail to respond to container resizing and cannot be serialized to clean Markdown or HTML structures.

---

The DOM flow model solution

Use DOM order for document content, reserving position: absolute strictly for non-rendering UI chrome (drag handles, selection borders, resize dividers):

// Perform clean structural DOM reordering using native insertBefore
export function reorderDocumentNode(draggedNode, targetNode, insertBeforeTarget) {
  const parentContainer = targetNode.parentNode;
  if (!parentContainer) return;
if (insertBeforeTarget) {     parentContainer.insertBefore(draggedNode, targetNode);   } else {     parentContainer.insertBefore(draggedNode, targetNode.nextSibling);   } }

Rule of thumb: Use native DOM reordering (insertBefore) for document content and limit absolute positioning strictly to interactive UI chrome.