Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Draggable objects

redblobgames.com

Post reply on HN
Print view View original

111–120 of 147 posts

Re: Draggable objects

#111

Post by orlp »

Nezteb wrote: post #105
aboodman wrote: post #83

Earlier quoted context omitted.

I have a trick for this that I love that is very general: 1. When a user begins dragging, calculate the layouts for all possible drop targets (or perhaps just those that are currently visible). 2. For each of those layouts record the position the dragged objects ends up in. 3. On each mouse movement, select from those positions the one that's closest to the dragged object's current position 4. Render the selected lay…

I was bored so I made a super simple implementation of this: https://codepen.io/Nezteb/pen/MWZBapL

Doesn't work with touch.

Re: Draggable objects

#112

Post by layer8 »

The article doesn’t seem to discuss cancellation. For example, there is the convention (at least on Windows) that pressing Escape cancels the dragging. Sometimes you also want to cancel the dragging when the mouse-up happens outside of some defined area. Cancellation serves as a quicker Undo (or an “oh, I actuality didn’t mean to drag”) for the user. In any case, this means that you have to save the original state at the start of the dragging, so that it can be restored if the dragging is cancelled, even if you otherwise provide no Undo functionality.

In the case of cancellation-when-dragging-outside-an-area, there’s also un-cancellation, meaning you resume the dragging when the pointer returns to the area, after the state visually reverted to the original one while outside the area (to indicate to the user that a cancellation would happen if the mouse button is released at that point). Or put differently, the real cancellation only happens upon mouse-up, but is already visually indicated while dragging.

Re: Draggable objects

#113

Post by layer8 »

wruza wrote: post #86
PaulDavisThe1st wrote: post #81

One extra detail, something I've learned from 20 years of working on dragging all kinds of objects around the GUI of Ardour [0]: handle ALL button press and release events as drag events where there is no movement. That is: press ALWAYS starts a drag that is finished by the release, and the code that handles release "special cases" the no-movement condition. [0] https://ardour.org/

What’s the rationale here?

This reminds me a bit of how double-click works, or originally worked: A single (first) click selects the element, and if there’s a second click within a short timeout period on the selected element, it invokes a default action on that element. Meaning, the double click is not a separate type of operation, it’s a continuation of what happens on a single click. You don’t wait after a single click to see if it becomes a double click; instead you always perform the single-click operation (selecting the element), and a second click that makes it a double click may or may not follow, and if it follows is compatible with the single-click action.

Re: Draggable objects

#114

Post by tobr »

aboodman wrote: post #83
wildrhythms wrote: post #67

This article is about dragging, and I've run into all of the pitfalls and come to the same solutions that Amit talks about. Excellent article! One of the hardest things I have needed to code from scratch is drag-to-reorder. It seem so natural from a user perspective, but when you get into inconsistently sized items, having to create placeholders between items, detecting edges, going down rabbitholes of box-fitting al…

I have a trick for this that I love that is very general: 1. When a user begins dragging, calculate the layouts for all possible drop targets (or perhaps just those that are currently visible). 2. For each of those layouts record the position the dragged objects ends up in. 3. On each mouse movement, select from those positions the one that's closest to the dragged object's current position 4. Render the selected lay…

> record the position the dragged objects ends up in

Can you explain this in more detail? Don’t you need to actually change the layout to figure this out correctly? Or are you approximating it with the top/left corner of the current element in the same place or something?

EDIT: I read to fast, for some reason I understood step 1 as figuring out the location/bounding box of each drop target, but I think you mean to actually put the dragged object there and let the browser compute the layout.

Re: Draggable objects

#116

Post by ellyagg »

Nezteb wrote: post #105
aboodman wrote: post #83

Earlier quoted context omitted.

I have a trick for this that I love that is very general: 1. When a user begins dragging, calculate the layouts for all possible drop targets (or perhaps just those that are currently visible). 2. For each of those layouts record the position the dragged objects ends up in. 3. On each mouse movement, select from those positions the one that's closest to the dragged object's current position 4. Render the selected lay…

I was bored so I made a super simple implementation of this: https://codepen.io/Nezteb/pen/MWZBapL

I thought they meant the object automatically snaps to the nearest target in real-time.

Re: Draggable objects

#118

Post by dgreensp »

amitp wrote: post #38

Thank you everyone! What a surprise to be on HN today. Happy to answer questions!

I used to write browser UI code all the time, but it’s been a few years. This is the first I’ve heard of someone using pointer events.

Do you worry at all about someone’s browser not supporting them, given that Safari added support in 2020? I guess Safari 12 is hopefully no longer used in practice, with macOS Mojave users hopefully running Safari 13 or 14? It would be pretty bad if something as simple as dragging didn’t work in a production app designed for the market of web users at large.

Adding event handlers to the document during a drag is a time-honored practice, and browsers add brand-new features all the time that are intended to simplify some use case or other but have their own edge cases and gotchas, which the article says are not fully addressed. And there’s still a combination of pointer and touch events in the end result. I wonder if the “simplicity” in the sense of less code is worth the additional edge cases, less browser support, and the developer needing to understand the ins and outs and browser differences of pointer events, which are presumably less understood and documented than mouse events.

Re: Draggable objects

#119

Post by PaulDavisThe1st »

layer8 wrote: post #113
wruza wrote: post #86

Earlier quoted context omitted.

What’s the rationale here?

This reminds me a bit of how double-click works, or originally worked: A single (first) click selects the element, and if there’s a second click within a short timeout period on the selected element, it invokes a default action on that element. Meaning, the double click is not a separate type of operation, it’s a continuation of what happens on a single click. You don’t wait after a single click to see if it becomes…

Historically, it differed on different windowing systems. The two versions featured the following event sequences:

A: button press, button release, button press, button release

B: button press, button press, button release

This subtle difference leads to a world of difference in mid-level code.

Re: Draggable objects

#120

Post by amitp »

dgreensp wrote: post #118
amitp wrote: post #38

Thank you everyone! What a surprise to be on HN today. Happy to answer questions!

I used to write browser UI code all the time, but it’s been a few years. This is the first I’ve heard of someone using pointer events. Do you worry at all about someone’s browser not supporting them, given that Safari added support in 2020? I guess Safari 12 is hopefully no longer used in practice, with macOS Mojave users hopefully running Safari 13 or 14? It would be pretty bad if something as simple as dragging did…

I don't worry about it. I usually wait a few years before using some browser feature. I'm not writing a production app and I have no customers. If I had customers, then I'd be looking at what browsers they use and making a decision based on that.

This page is not prescriptive: I'm not trying to tell everyone else what to do. This page is descriptive: I'm trying to document what works for me. For the use cases I need on my pages, pointer events cleared up a lot of glitches and edge cases I previously had with mouse+touch events. There are some that remain. I'm happy with the switch. This isn't a luxury everyone has. Not all use cases are as well supported as the things I want to do.

Post reply on HN