drag and drop target strategies
in [JavaScript]
|
Prev: stop form submit
Next: Math ugliness.
From: Peter Michaux on 16 Feb 2010 15:14 On Feb 16, 12:06 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Peter Michaux wrote: > > Thomas 'PointedEars' Lahn wrote: > >> Peter Michaux wrote: > >> > [...] > >> > 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. > > >> > I'm curious which of the above methods people here have used and if > >> > there are any other techniques worth considering. > > >> Sounds like going at lengths to invent a polygonous wheel without > >> properly testing the other inventor's round one before, which strikes me > >> as being a particularly stupid idea. > > > Can you confirm that native drag and drop is, in fact, a round wheel > > and can provide cross-browser functionality? > > Perhaps, but that task would be up to you. I'm not asking you to do any work but to state whether you already know that the wheel is round or not. You say that the other inventor's wheel is round implying you already know it is and that I simply need to test it to see that is the case. From what I've seen that other inventor's wheel is just a different polygon than the DHTML drag and drop solution wheels. I have not seen a way to control the appearance of the drag proxy for native drag and drop in IE, for example. If that cannot be done then that is game over for even considering native drag and drop in IE for any drag and drop purpose that I've encountered. Peter
From: Jorge on 16 Feb 2010 16:45 On Feb 16, 7:50 pm, Peter Michaux <petermich...(a)gmail.com> wrote: > (...) Lining up the bits in the four > pieces can be difficult depending on the contents. (...) I don't think so, no, it isn't... :-/ http://jorgechamorro.com/cljs/039/ -- Jorge.
From: Thomas 'PointedEars' Lahn on 16 Feb 2010 17:00 Peter Michaux wrote: > Thomas 'PointedEars' Lahn wrote: >> Peter Michaux wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> Peter Michaux wrote: >> >> > [...] >> >> > 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. >> >> > >> >> > I'm curious which of the above methods people here have used and if >> >> > there are any other techniques worth considering. >> >> Sounds like going at lengths to invent a polygonous wheel without >> >> properly testing the other inventor's round one before, which strikes >> >> me as being a particularly stupid idea. >> > Can you confirm that native drag and drop is, in fact, a round wheel >> > and can provide cross-browser functionality? >> Perhaps, but that task would be up to you. > > I'm not asking you to do any work but to state whether you already > know that the wheel is round or not. You say that the other inventor's > wheel is round implying you already know it is and that I simply need to > test it to see that is the case. No, that is a fallacy. I am merely saying that "little investigation" does not provide sufficient a reason for going at lengths to reinvent the wheel. > From what I've seen that other inventor's wheel is just a different > polygon than the DHTML drag and drop solution wheels. You had not stated your reasons by then. > I have not seen a way to control the appearance of the drag proxy for > native drag and drop in IE, for example. If that cannot be done then > that is game over for even considering native drag and drop in IE for > any drag and drop purpose that I've encountered. Define: drag proxy. Besides, your logic is flawed. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: RobG on 16 Feb 2010 17:43 On Feb 16, 2:06 pm, Peter Michaux <petermich...(a)gmail.com> wrote: > On Feb 15, 7:09 pm, RobG <rg...(a)iinet.net.au> wrote: > > > > > On Feb 16, 11:20 am, Peter Michaux <petermich...(a)gmail.com> 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. > > [...] > > > 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. > > > Have you considered a quadtree[1]? I've never programmed one, but > > they are commonly used in CAD and other graphics applications dealing > > with 2d and 3d spatial indexing. > > No I hadn't considered a quadtree but I can imagine it would be useful > to keep the number of regions low. Perhaps it would be especially > useful if there were circular shaped targets. The shapes of the targets isn't relevant. The idea is to create an quadtree index to the target shapes. The cursor position is converted to a spatial key and if there are no targets within the region, no further search is required. If there are targets in the region the cursor is over, search to see if it's over any of those particular targets. When the quadtree is created, the position of the targets is stored so determining which ones the cursor is over is pretty quick. If the targets don't overlap, life is easier - as long as the cursor is over a target, no search for other targets is necessary. The down side comes if the targets change their position in the page, the index and stored positions of targets need to be recalculated. But there should be a bit of slack after a move is complete and before the next one starts so it might be unnoticeable. There are also very efficient methods to do the re-calculation using shifts rather than working out a new position and index for every target from scratch every time. There may be better strategies to deal with a large number of targets in a small region of a page, e.g. when re-ordering a list. -- Rob
From: dhtml on 16 Feb 2010 19:41
On Feb 15, 5:20 pm, Peter Michaux <petermich...(a)gmail.com> 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. > Drop targets that do not have ondragover/ondragout or dragOverClassName can be excluded from that list. 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); //... } If mousemove is slowing down too much, then look at why. Profile the function calls using Firebug to see what it is doing that is to heavy. Like other events, mousemove can be throttled. Although some would prefer using a setTimeout or setInterval on mousedown, and cancelling that on mouseup, it is actually more efficient to throttle the event by adding to the first step of mousemove, a check of now against last mousemove time. e.g. if(now - lastMouseMoveTime < THRESHOLD) return; I just moved and not using my own machine. everything's in boxes and stuff. Still catching up on other posts. Garrett |