@jsenv/dom 0.17.14 → 0.17.16

package/dist/jsenv_dom.js

@@ -8951,6 +8951,26 @@ installImportMetaCssBuild(import.meta);/**
  *
  * Whichever trigger fired, it has established the intent: the gesture then
  * starts at the first pixel, without a second threshold to cross.
+ *
+ * WHEN A FINGER MAY TRAVEL TOO: [data-drag-on-contact].
+ *
+ * The wait a finger is asked for is not a rule about fingers, it is the answer to
+ * an ambiguity — travel means scroll as much as it means drag, so the two have to
+ * be told apart. Where nothing scrolls the ambiguity does not exist, and the wait
+ * is asking the hand to prove something nothing else could have meant: inside a
+ * dialog that holds the page still, a finger travelling on a piece can only be
+ * carrying it.
+ *
+ * So the attribute says that place, not that element — put on the dialog, every
+ * source inside it reads by distance like a mouse does, at the same few pixels.
+ * A tap is left alone by that: a press that goes nowhere is still a press, which
+ * is what a piece that is also a link or a card needs.
+ *
+ * It is opt-in and cannot be anything else. Nothing here can see whether the
+ * surroundings scroll — a page scrolls by default, an overflow is one CSS
+ * property away, and getting it wrong the wrong way means the list runs away
+ * under the finger that meant to reorder it. Only the application knows it has
+ * taken the scroll away.
  */
 
 /* At module scope, and on the markers rather than on the pressed element: both
@@ -8993,6 +9013,13 @@ const css$4 = /* css */`
        knows which way what surrounds the source scrolls. */
     touch-action: pan-x pinch-zoom;
   }
+  [data-drag-on-contact] [data-drag-source],
+  [data-drag-source][data-drag-on-contact] {
+    /* Nothing scrolls here, so there is no pan to leave to anyone — the finger
+       may travel from the first pixel. Zoom is kept: it belongs to the reader,
+       not to the gesture, and two fingers are never a drag. */
+    touch-action: pinch-zoom;
+  }
   [data-drag-ignore] {
     -webkit-touch-callout: default;
     touch-action: auto;
@@ -9060,6 +9087,8 @@ const markDragSource = (element, axes) => {
  *   distance-based.
  * @param {boolean|"if-touch"} [options.longPress="if-touch"]
  *   Which pointers start a drag by holding still instead of by travelling.
+ *   `"if-touch"` excepts what stands inside a `[data-drag-on-contact]`, where
+ *   nothing scrolls and a finger resolves by distance like a mouse.
  * @param {number} [options.longPressDelay=400]
  *   How long (ms) the pointer must stay down. Kept under the system context-menu
  *   delay so the object is picked up before the menu would have opened.
@@ -9091,7 +9120,10 @@ const dragAfterIntent = (grabEvent, dragGestureInitializer, {
     startDragGesture(dragGestureInitializer);
     return;
   }
-  const startsOnLongPress = longPress === true || longPress === "if-touch" && grabEvent.pointerType === "touch";
+  const startsOnLongPress = longPress === true || longPress === "if-touch" && grabEvent.pointerType === "touch" &&
+  // The wait tells a scroll from a drag, and here there is no scroll to tell
+  // it from — see [data-drag-on-contact] at the top of this file.
+  !(target.closest && target.closest("[data-drag-on-contact]"));
   if (startsOnLongPress) {
     dragAfterLongPress(grabEvent, dragGestureInitializer, {
       longPressDelay,
@@ -12759,15 +12791,77 @@ import.meta.css = [/* css */`
 
      !important because this is not a preference: a box that travels cannot let
      the page travel with it, and the rule has to win over whatever an
-     application says about its own scrollers. */
-  [data-drag-travel*="x"],
-  [data-drag-travel*="x"] * {
+     application says about its own scrollers.
+
+     Said on the box, where it is a statement about the box and not about what
+     it happens to hold — and read only where a browser asks the box at all:
+     one that CLIPS is asked (it is a scroll container, which is what "asked"
+     means to a browser), one that does not is walked past. A box that travels
+     usually clips, because moving something in and out of a box is what
+     clipping is for. One that does not still travels — what an inner scroller
+     has left over reaches the page there, and the rule below says why that is
+     the lesser of the two prices. An application that knows which of ITS
+     elements scroll can contain those itself, on the element every engine
+     reads; nothing in here can know that from a stylesheet. */
+  [data-drag-travel*="x"] {
     overscroll-behavior-x: contain !important;
   }
-  [data-drag-travel*="y"],
-  [data-drag-travel*="y"] * {
+  [data-drag-travel*="y"] {
     overscroll-behavior-y: contain !important;
   }
+  /* The scrollers a browser makes on its own, wherever they are inside the box:
+     a textarea and a list of options scroll their own content by nature, and
+     nobody had to say so for them — no stylesheet declared them, so nothing
+     else here can find them, and they would hand what is left of a gesture to
+     the page like any undeclared scroller does.
+
+     Named rather than found, because being native is exactly what makes them
+     nameable. An input is NOT in the list: it is the one form control that has
+     nothing to scroll on the axis anything travels on, and containing it is how
+     a row-wide invisible checkbox becomes a hole under the wheel.
+
+     A textarea with nothing in it, or a list of options short enough to fit, is
+     contained too — a browser cannot be asked "only if it scrolls". On Blink
+     that costs a wheel over an empty textarea, which then moves nothing rather
+     than the list around it; elsewhere the engine already only asks what
+     scrolls. Worth the page not moving behind a travel. */
+  [data-drag-travel*="x"] :is(textarea, select[multiple], select[size]) {
+    overscroll-behavior-x: contain !important;
+  }
+  [data-drag-travel*="y"] :is(textarea, select[multiple], select[size]) {
+    overscroll-behavior-y: contain !important;
+  }
+  /* The same thing said again to everything inside — and only where saying it
+     is what works.
+
+     Two readings of "contain" are out there, and the rule above lands in only
+     one of them. Blink walks EVERY scroll container between the pointer and the
+     page and asks each one whether the gesture may go past it, whether or not
+     it had anything to scroll: the box above is asked, and containing it is the
+     whole answer. Gecko and WebKit ask only the ones that actually scroll: the
+     box is skipped (it travels, it does not scroll), and what is left of a
+     list's gesture reaches the page unless the LIST itself was told — which is
+     what this does, to everything, because which descendant scrolls is not
+     something a stylesheet can know.
+
+     Not said to Blink, where it is not needed and does harm: an element that
+     clips is a scroll container to a browser (a line of text with an ellipsis,
+     a rounded card, an invisible checkbox covering a row), and Blink asking one
+     of those with nothing to scroll gets "no further" for an answer — the wheel
+     stops there and the list right above it never moves. A dead zone under the
+     pointer, wherever something inside the box happens to clip.
+
+     Blink is told apart by a property only it has, rather than by reading a user
+     agent: the split above is between engines, and -webkit-app-region is one of
+     the few things that names one. */
+  @supports not (-webkit-app-region: none) {
+    [data-drag-travel*="x"] * {
+      overscroll-behavior-x: contain !important;
+    }
+    [data-drag-travel*="y"] * {
+      overscroll-behavior-y: contain !important;
+    }
+  }
 `, "@jsenv/dom/src/interaction/drag/drag_to_travel.js"];
 
 // How far a pointer goes before it is a travel rather than a click: below this

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jsenv/dom",
-  "version": "0.17.14",
+  "version": "0.17.16",
   "type": "module",
   "description": "DOM utilities for writing frontend code",
   "repository": {