drag and drop target strategies
in [JavaScript]
|
Prev: stop form submit
Next: Math ugliness.
From: dhtml on 16 Feb 2010 19:53 On Feb 16, 4:41 pm, dhtml <dhtmlkitc...(a)gmail.com> wrote: > On Feb 15, 5:20 pm, Peter Michaux <petermich...(a)gmail.com> wrote: > > [...] > > That leaves open the possiblity for a delegation strategy for generic > list-based sorting, e.g. > > function delegateMouseover(ev) { > var target = DragAPI.getTarget(ev); > var isListItem = DragAPI.isListItem(target); > //... > > } > Actually no that doesn't work because the pointer is over the dragged object.
From: Christian Winter on 18 Feb 2010 12:40 dhtml wrote: > On Feb 16, 4:41 pm, dhtml <dhtmlkitc...(a)gmail.com> wrote: > [...] >> That leaves open the possiblity for a delegation strategy for generic >> list-based sorting, e.g. >> >> function delegateMouseover(ev) { >> var target = DragAPI.getTarget(ev); >> var isListItem = DragAPI.isListItem(target); >> //... >> >> } >> > Actually no that doesn't work because the pointer is over the dragged > object. Any reason why the proxy object needs to be under the pointer? There are a number of implementations out there that position it in a distance of 10 to 20 pixels away from the mouse pointer, and I've never heard anyone complain about that. -Chris
From: dhtml on 18 Feb 2010 15:47 On Feb 18, 9:40 am, Christian Winter <thepoet_nos...(a)arcor.de> wrote: > dhtml wrote: > > On Feb 16, 4:41 pm, dhtml <dhtmlkitc...(a)gmail.com> wrote: > > [...] > >> That leaves open the possiblity for a delegation strategy for generic > >> list-based sorting, e.g. > > >> function delegateMouseover(ev) { > >> var target = DragAPI.getTarget(ev); > >> var isListItem = DragAPI.isListItem(target); > >> //... > > >> } > > > Actually no that doesn't work because the pointer is over the dragged > > object. > > Any reason why the proxy object needs to be under the pointer? > There are a number of implementations out there that position > it in a distance of 10 to 20 pixels away from the mouse pointer, > and I've never heard anyone complain about that. > If the proxy is 10px away from the cursor, the proxy is overlapping both the edge of the drop target and the non-drop target area, and the user then moves the mouse in the direction of the drop target, over the proxy, in one swift motion, he has actually moved the mouse over the proxy and not triggered a mouseover on the droptarget. After that the proxy moves, exposing the actual drop target. A throttling strategy makes that scenario more likely because the mousemove handler has a threshold that limits its frequency. The further the distance between the proxy and the pointer, the less likely this will occur. It would probably be best to test on a slower machine with an older browser, such as an old mac with Safari 2.
From: David Mark on 18 Feb 2010 17:40 dhtml wrote: > On Feb 18, 9:40 am, Christian Winter <thepoet_nos...(a)arcor.de> wrote: >> dhtml wrote: >>> On Feb 16, 4:41 pm, dhtml <dhtmlkitc...(a)gmail.com> wrote: >>> [...] >>>> That leaves open the possiblity for a delegation strategy for generic >>>> list-based sorting, e.g. >>>> function delegateMouseover(ev) { >>>> var target = DragAPI.getTarget(ev); >>>> var isListItem = DragAPI.isListItem(target); >>>> //... >>>> } >>> Actually no that doesn't work because the pointer is over the dragged >>> object. >> Any reason why the proxy object needs to be under the pointer? >> There are a number of implementations out there that position >> it in a distance of 10 to 20 pixels away from the mouse pointer, >> and I've never heard anyone complain about that. >> > > If the proxy is 10px away from the cursor, the proxy is overlapping > both the edge of the drop target and the non-drop target area, and the > user then moves the mouse in the direction of the drop target, over > the proxy, in one swift motion, he has actually moved the mouse over > the proxy and not triggered a mouseover on the droptarget. After that > the proxy moves, exposing the actual drop target. I'm admittedly entering the discussion late, but why would you care about mouseover events on the _target_. Anything relying on those is a botched design (and doomed to fail). Drop targets are just predetermined regions of the document. Therefore, drag and drop is about basic geometry, not event handling. See My Library's rendition for example.
From: David Mark on 18 Feb 2010 17:42
Peter Michaux wrote: > Hi, > > One of the first browser scripting techniques I worked with years ago > was DHTML drag and drop. I've come across and thought about three main > techniques to determine when a dragged item is over a drop target. All > of the ways have pros and cons depending on the situation. > > 1) When a drag is in progress, use the native mouseover to know when > the mouse cursor enters a drop target element. In order for the native > mouseover event to fire, there cannot be either the dragged item or a > proxy of the dragged item moving around and under with the cursor. If > there is an item like this with high z-index between the cursor and > target, then the mouseover event for the target cannot fire because > the cursor is always over the dragged item. There can be a dragged > item beside the cursor but that isn't very visually pleasing or what > the user is accustomed to experiencing. This technique is not so great > when dragging in a list. If the cursor is between two <li> elements > then it is over the <ul> and so where to show the item will drop? Also > deciding if the item will drop above or below a particular <li> or > will drop at the end of the list is a bit messy. > > 2) If the dragged item must look like it is remaining under the cursor > during the drag, then there is another strategy I saw a long time ago. > Extra transparent elements are created and added to the page directly > above (i.e. large z-index) the target zones. If these transparent > elements have z-index of 10, then the dragged item has a z-index of 5. > That way the dragged item appears to be under the cursor but the > mouseover events for the extra elements still fire as there is nothing > between the cursor and the extra elements. This is appealing but the > setup is expensive adding elements to the page. If the page is > scrolling or has scrolling elements the exact placement of the extra > elements is tricky as position reporting of the real target elements > in the page can be tricky. > > 3) Another option I have used is when the drag starts to compute > regions of the page that are drop targets. When the mousemove event is > fired during the drag, the position of the mouse is compared to the > computed regions to determine which region currently contains the > mouse cursor. Depending how the regions are computed this can be O(n) > lookup with every mousemove event or it can be O(1) if the regions are > all uniform in size. This does require knowing the positions of the > drop targets which can be a problem as mentioned in 2 above. I know > this system can be very fast and I've had impressed users that note > how fast it is compared to some other slow drag and drop > implementations. 3 for sure. ;) > > I don't think I've seen any other way of doing things that might be > worth considering. The main concerns are the appearance of the dragged > item (under or beside the mouse cursor) and the speed of showing the > current drop target for each mousemove. Since the mousemove event > fires in quick succession the computation needs to be fast. > > I've only investigated native drag and drop APIs a little and they > didn't seem very useful in terms of making an appealing user > experience. They are used for other things (e.g. dragging links from one browser to another). |