@helping-ai-workflow/md2doc 2.12.0 → 3.0.0

package/lib/md2doc.js

@@ -1080,18 +1080,27 @@ ${itemsHtml}
   // `.content { min-width: 0; flex: 1 1 auto; }` block, which
   // test/md2doc.test.js matches verbatim).
   //
-  // Why it exists: the gutter buttons hang OUTSIDE the content box, and the
-  // table row grip straddles the table's left border (half of it outside
-  // too — see the .ed-te-grip-row comment above). Without real padding the
-  // two fight over the same few pixels, which is what forced the earlier
-  // (now reverted) "inset the row grip into the table" hack that ended up
-  // covering the first cell's text. 56px of content padding plus moving the
-  // gutter buttons out (⠿ to left:-36px, ＋ to left:-54px) separates them
-  // properly: the gutter pair occupies [contentLeft-40, contentLeft-4]
-  // (v2.11.1; it was [contentLeft-54, contentLeft-18] until spec §4.2's own
-  // numbers were restored) and the 20px-wide row grip straddles contentLeft at
-  // [contentLeft-10, contentLeft+10] — an 8px gap, and the grip's inner half
-  // stays within the cell's own 14px padding, so it never touches cell text.
+  // Why it exists: the gutter buttons hang OUTSIDE the content box. 56px of
+  // content padding plus moving the gutter buttons out puts the pair at
+  // [contentLeft-40, contentLeft-4] (v2.11.1; it was
+  // [contentLeft-54, contentLeft-18] until spec §4.2's own numbers were
+  // restored), clear of .sidebar-splitter — see the .content rule below.
+  //
+  // GEOMETRY, AS MEASURED (S4 T1; the previous version of this comment
+  // claimed "an 8px gap" between the gutter and the table row grip, a number
+  // left over from the v2.11.0 pair position that v2.11.1 invalidated — the
+  // real gap was MINUS 6px, i.e. an overlap):
+  //   ⠿          [contentLeft-22, contentLeft-4]   (--ed-gutter-btn wide)
+  //   row grip   [contentLeft,    contentLeft+20]  (--ed-te-grip-row-w wide)
+  // The grip used to be centred on the table's left border at
+  // [contentLeft-10, contentLeft+10], which overlapped the ⠿'s right 6px and
+  // — being position: fixed, z-index 7, on document.body — won the hit test
+  // there. spec §4.2 conflict 2's ruling (grip entirely inside the table)
+  // is landed in lib/editor/client.js's updateTableEdgeGrips(); the
+  // clearance that remains is exactly --ed-gutter-gap, because the ⠿'s right
+  // edge and the grip's left edge are both derived from it. The grip is kept
+  // off the first cell's TEXT by --ed-te-cell-pad-left below, not by the
+  // 14px default padding, which is narrower than the grip.
   // (The padding was 48px until §4.2's hit-test conflict 1 was fixed; see the
   // .content rule in editModeLayoutCss below for why it is 56px now.)
   // S1 Task 5: the ordered-list ordinal is drawn by a CSS counter, and the
@@ -1147,10 +1156,11 @@ ${itemsHtml}
      further in, to spec §4.2's own [contentLeft-40, contentLeft-4] — the
      clearance is 16px at this padding rather than 2px. The padding stays at
      56px: nothing asks for the text column to move, and this measurement is
-     the one the §4.2 conflict-1 guard is written against.) The 20px table row grip
-     still straddles contentLeft at [contentLeft-10, contentLeft+10], so its
-     8px gap to ⠿ is unchanged. Guarded by the elementFromPoint(splitter.right
-     - 2, y) assertion §4.2 asks for, in
+     the one the §4.2 conflict-1 guard is written against.) The table row grip no
+     longer reaches this far left at all: §4.2 conflict 2 moved it inside the
+     table to [contentLeft, contentLeft+20] (S4 T1), so nothing but the gutter
+     pair itself occupies [contentLeft-40, contentLeft-4]. Guarded by the
+     elementFromPoint(splitter.right - 2, y) assertion §4.2 asks for, in
      test/editor-client-runtime.test.js. */
   .content { padding-left: 56px; }
 
@@ -1221,9 +1231,10 @@ ${itemsHtml}
      [contentLeft-54, contentLeft-18], which with 56px of padding sits wholly
      inside the content column (2px clear of .sidebar-splitter's right edge —
      see the padding rule's own comment for the measurement), so ＋ never
-     reaches a negative viewport x and never covers the splitter. The 20px
-     table row grip still straddles contentLeft at
-     [contentLeft-10, contentLeft+10] - an 8px gap, unchanged. */
+     reaches a negative viewport x and never covers the splitter. The table
+     row grip is at [contentLeft, contentLeft+20] since §4.2 conflict 2
+     landed (S4 T1), so the clearance from the ⠿'s right edge is exactly
+     --ed-gutter-gap and cannot drift: both edges are derived from it. */
   /* Stated ONCE, as tokens, because §4.2's three numbers are not independent:
      the gutter is exactly two buttons wide plus the deliberate right-hand
      breathing gap, and the hover zone below is exactly the gutter. Writing any
@@ -1232,6 +1243,19 @@ ${itemsHtml}
     --ed-gutter-btn: 18px;
     --ed-gutter-gap: 4px;
     --ed-gutter-w: calc(var(--ed-gutter-btn) * 2 + var(--ed-gutter-gap));
+    /* spec §4.2 hit-test conflict 2, landed S4 T1. The table row grip now
+       sits ENTIRELY inside the table (its LEFT edge on the table's left
+       border — see updateTableEdgeGrips() in lib/editor/client.js), which
+       leaves the ⠿'s right edge and the grip's left edge exactly
+       --ed-gutter-gap apart: the 4px breathing gap §4.2 already keeps on the
+       right of the gutter pair IS the separation. Nothing new is written
+       down, so nothing new can drift.
+       The consequence is this token: the grip is 20px wide and the first
+       column's default padding is 14px, so an inset grip would sit on that
+       cell's TEXT — the v2.10.1 user-acceptance defect that got the first
+       attempt at this ruling reverted. The first column is padded past the
+       grip instead, by the grip's own width plus that same gap. */
+    --ed-te-cell-pad-left: calc(var(--ed-te-grip-row-w) + var(--ed-gutter-gap));
   }
   .ed-handle {
     left: calc(-1 * (var(--ed-gutter-btn) + var(--ed-gutter-gap))); top: 0;
@@ -1283,6 +1307,16 @@ ${itemsHtml}
     content: ""; position: absolute;
     left: calc(-1 * var(--ed-gutter-w)); top: 0;
     width: var(--ed-gutter-w); height: 100%;
+  }
+
+  /* §4.2 conflict 2's other half: the row grip lives inside the first column
+     now, so that column's cells must be padded past it. EDIT MODE ONLY —
+     reader HTML and PDF output keep the shared 7px 14px and stay
+     byte-identical. Only the LEFT padding changes, and only on the first
+     cell of each row; every other cell is untouched. */
+  .ed-block[data-block-type="table"] th:first-child,
+  .ed-block[data-block-type="table"] td:first-child {
+    padding-left: var(--ed-te-cell-pad-left);
   }`;
 
   const html = `<!DOCTYPE html>
@@ -2296,17 +2330,49 @@ ${itemsHtml}
   }
   .ed-te-drop-indicator[hidden] { display: none; }
   .ed-te-row-dragging { opacity: 0.4; }
+  /* S4 Task 2 (spec §4.5): the block drag's own singleton drop indicator,
+     shown while a block is being dragged by its ⠿. Same 3px blue rule as the
+     table's, on a SEPARATE node rather than sharing '.ed-te-drop-indicator':
+     that one is shared by the row and column axes and each of them has to
+     rewrite the OTHER axis's dimension on every move or a stale value leaks
+     in — a third writer multiplies that coupling. It is still ONE node for the
+     whole document (the Global Constraint is "never one per boundary"), and
+     the separate class is what lets a test assert that a block drag raised
+     the BLOCK line rather than table chrome that happened to be on screen. */
+  .ed-block-drop-indicator {
+    position: fixed; z-index: 8; height: 3px; border-radius: 2px;
+    background: #3b82f6; pointer-events: none;
+  }
+  .ed-block-drop-indicator[hidden] { display: none; }
+  /* S4 Task 2b (user request, 2026-09-01): the drag's feedback on the SOURCE
+     side. lib/editor/client.js puts '.ed-block-dragging' on <html> the moment
+     a ⠿ drag engages and takes it off in teardownBlockDrag(), which every one
+     of the five abort paths funnels through. On <html> rather than on the
+     dragged block because the plan forbids mutating anything inside
+     '.content' during a drag — that invariant is the only reason Escape /
+     pointercancel / window blur can all clean up with nothing to revert.
+     The universal selector plus !important is what the rule needs to be worth
+     having: '.ed-handle' (the button the gesture starts on), '.ed-handle-menu-btn'
+     and every table grip carry their own 'cursor: pointer', and a plain
+     inherited cursor loses to all of them. */
+  html.ed-block-dragging, html.ed-block-dragging * { cursor: grabbing !important; }
   /* Notion-style grip handles: replace the original invisible TE_EDGE_PX=8
      proximity zone (user-acceptance feedback: unusably small, no visible
      affordance) with two real, adequately-sized (>=18x24px) click/drag
      targets. '.ed-te-grip-row' is a vertical 6-dot handle shown at the LEFT
      EDGE of the hovered row -- every row, the HEADER included (spec 3.10:
-     the header is draggable too), STRADDLING the table's left border (its
-     centreline ON that border), which is the same rule '.ed-te-grip-col'
-     uses on the table's TOP border -- one geometry for both axes, no
-     per-row-type special case. The block's own gutter is kept clear of it by
-     the edit-mode-only layout chunk emitted near the end of this stylesheet,
-     not by insetting the grip; '.ed-te-grip-col' is a horizontal 6-dot
+     the header is draggable too), sitting ENTIRELY INSIDE the table with its
+     LEFT edge on the table's left border (spec 4.2 hit-test conflict 2,
+     landed in S4 T1). The two axes are therefore NOT mirror images any more:
+     '.ed-te-grip-col' still straddles the table's TOP border, because nothing
+     of the page's own chrome lives up there. The row axis cannot: MEASURED on
+     v2.12.0 at 1400x900, the straddling grip occupied [tableLeft-10,
+     tableLeft+10] while the block's own '.ed-handle' occupied [blockLeft-22,
+     blockLeft-4] with tableLeft == blockLeft, so the grip (position: fixed,
+     z-index 7, on document.body) won the hit test for the RIGHT 6px of every
+     ⠿ whose Y band it reached. The first column's own padding is widened in
+     the edit-mode-only layout chunk near the end of this stylesheet so the
+     inset grip still never reaches cell TEXT; '.ed-te-grip-col' is a horizontal 6-dot
      handle shown just ABOVE the hovered column (every column). Dots are plain <span>s laid out via CSS grid with
      place-content: center, so the dot cluster stays compact/centered
      regardless of the button's own (larger, hit-target-sized) box — no
@@ -2325,8 +2391,15 @@ ${itemsHtml}
   .ed-te-grip:hover { background: rgba(0, 0, 0, 0.06); }
   .ed-te-grip-dot { width: 3px; height: 3px; border-radius: 50%; background: #9ca3af; }
   .ed-te-grip:hover .ed-te-grip-dot { background: #6b7280; }
+  /* spec §4.2 hit-test conflict 2 (S4 T1): the row grip's width is a TOKEN
+     because two other numbers are derived from it — lib/editor/client.js pins
+     the grip's LEFT edge to the table's left border (so the whole grip is
+     inside the first column and shares no pixel with the block gutter's ⠿),
+     and the edit-mode first-column padding must be wide enough to host it
+     without covering cell text. Written once here, derived twice below. */
+  :root { --ed-te-grip-row-w: 20px; }
   .ed-te-grip-row {
-    width: 20px; height: 28px; cursor: grab; z-index: 7;
+    width: var(--ed-te-grip-row-w); height: 28px; cursor: grab; z-index: 7;
     grid-template-columns: repeat(2, 3px); grid-template-rows: repeat(3, 3px);
     gap: 3px 4px;
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@helping-ai-workflow/md2doc",
-  "version": "2.12.0",
+  "version": "3.0.0",
   "description": "Markdown → HTML / PDF renderer with WaveDrom, Mermaid, and Graphviz support",
   "keywords": [
     "markdown",