Ok my bug, theres a threshold, but it is only 2px.

Dragging links (anchors) is not so sensitive.

Threshold should be computed in milimeters or at least 8px.

I'm not convinced that our behavior is an issue here. Given the vast array of devices and sensitivity settings out there, I can't think of a way to determine a good threshold. A solid UI should be able to handle accidental dragstarts gracefully, just like it has to handle the circumstance of users changing their minds after starting the drag operation.

You are right: user just have to drop the elements at their home location to cancel the operation.

But the operation should not start when the distance is less than the threshold used to start dragging anchors.

It is so ugly to see the drag operation starting (and the cloned elements displayed) when you just tried to select a big item (eg a thumbnail).

With Chromium should we try to re-emit the native dragstart event ourselves (is it applicable ?) and (oh yeah !) draw some "1em" sized font in a canvas and compute the size in pixels to get an idea of a proper threshold ? Come on...

Again, the operation should not start when the distance is less than the threshold used to start dragging anchors.

Please update the status.

We did implement a full macintosh like drag-n-drop system in javascript more than ten years ago.

But here we are talking about native dragndrop, allowing to drop in another window or process and we expect it working "out of the box" (in future browsers).

Moving the bug back to Unconfirmed to look into the claim that we handle anchors differently from images.

That being said, can you please give me specific examples to frame the discussion? It would be helpful to have concrete cases where our treatment of drag and drop causes undesired user experiences, and where other browsers behave differently. When providing examples, please include URLs and specific actions.

I don't understand the point you're trying to make in the paragraph about the 1em sized font. You shifted from your previously suggested 8px threshold to 1em, which makes it seem that you're agreeing with my point that no fixed threshold would work. Can you please clarify what you meant?

Last, the best way to make sure that a behavior will occur in future browsers is to get it standardized. The relevant standards seem to be [1, 2, 3] -- I'm still learning about this space though. All these documents describe drag & drop in very abstract terms, so I would be surprised if they'd be willing to include such a low-level UX detail.

[1] https://www.w3.org/TR/2010/WD-html5-20101019/dnd.html
[2] https://html.spec.whatwg.org/multipage/interaction.html
[3] https://developers.whatwg.org/dnd.html#dnd

To see what I mean you can go to the bottom of this page:

        http://www.html5rocks.com/en/tutorials/dnd/basics/

And check the sensitivity of the dragstart by clicking and dragging slowly, 

First with the boxes A B C D (client-side dragstart event listener), then with the links below (native anchor dragstart listener)

2 pixels is a very small threshold for triggering the client-side dragstart event listener on very high resolution screens.

Specially when the elements are both clickable (selectable) and draggable.

The threshold feels more comfy with anchors, or using Firefox.

I believe the dragstart threshold for anchors is more tolerant for the exact same reason I need a more tolerant threshold for my DOM elements with a client-side dragstart event listener: they are both clickable and draggable.

The threshold could be temporal, and/or the user should be able to change it at the application level. 

I cannot remember for sure but I believe it was a user definable system-level mouse setting on MacOS where every application was using the System 7 Drag manager.

Also, when an item is both clickable and draggable, maybe you want give the user an opportunity to cancel the click after mousedown (releasing the button outside of the element) without firing the dragstart event.

It seems like we'll actually reduce the distance required to start dragging links --  http://crbug.com/20486 

Links are not my concern here, it is about html5 dragndrop, and
specifically the dragstart event.

There should be a configurable distance (or delay) used to differ the
html5 dragstart event for draggable items, to allow canceling a click
for items that are both draggable and clickable (eg: selectable icons
and list items in a web application)

If we use a custom client-side javascript library for dragndrop, we
cannot drop items outside of the browser window (eg on the desktop, in a
folder, or in another application).

Either a configurable distance or delay will be implemented, either a
relaxed security policy will be made available (allowing us to fire at
will the dragstart event), either items both clickable and draggable
will maybe remain a pain in the css until I'm retired (20 years left) :-)


On 06. 10. 16 03:32, pwn… via monorail wrote: