forty-cdk 0.21.0 → 0.21.1

package/drag-drop/README.md

@@ -388,6 +388,22 @@ for the full analysis.
 | `data-drag-animating`   | `[forDraggable]`  | Present while the item's FLIP reorder transition plays (requires `[animateReorder]`) |
 | `data-settling`         | preview element   | Present while the drop-settle transition plays (requires `[animateReorder]`)         |
 
+Both `data-dragging` rows hold for a drag a **coordinator** composing the list owns rather
+than starting through `[forDraggable]` itself — the keyboard lift of `[forVirtualReorder]`, and
+the virtualized branch of `[forTableRowReorder]`. Those intercept the lift key before the item
+sees it, so the list carries no lift state for the gesture, and the coordinator marks the item
+instead ([#1693](https://github.com/tutkli/forty-cdk/issues/1693)). Styling keyed off either
+attribute therefore behaves the same whether the collection is windowed or not.
+
+The `data-for-drag-preview` row is also the supported hook for **keeping the clone out of element
+queries**. The default preview is a `cloneNode(true)` copy appended to `document.body`, so for the
+whole gesture — and past the drop, while a settle transition runs — it answers the item's own
+selector (`[forDraggable]`, or a composed one such as `[forTableRow]`) and repeats its `data-index`.
+`id` and `data-testid` are stripped from the clone and its whole subtree, so a hook that identifies
+a single element stays unambiguous; anything that **enumerates** items by attribute selector during
+a drag must filter the preview out with `:not([data-for-drag-preview])`
+([#1691](https://github.com/tutkli/forty-cdk/issues/1691)).
+
 ## Sortable list
 
 ```html