Prev: stop form submit
Next: Math ugliness.
From: David Mark on 18 Feb 2010 17:44
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.

One caveat. It isn't the position of the mouse, but whether the dragged
element overlaps the regions. May not matter in some contexts, of course.
From: David Mark on 18 Feb 2010 17:47
jeff wrote:
> 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.
>>
>
>> 3) Another option I have used is when the drag starts to compute
>> regions of the page that are drop targets.
>
> I've had no need for drag and drop on an item, but I have done
> something very much like option 3 for other uses.
>
> On another note, Scriptaculous has resortable lists,

Most libraries use similar examples. The Prototripe/Craptaculous
example has always been a laughingstock due to performance issues.

>
> http://wiki.github.com/madrobby/scriptaculous/sortable-lists-demo

Right. That dog don't hunt (never did).

>
> you can drag an item of the list around and it then snaps to the nearest
> list position. I have no idea how they do that and never had enough
> desire to look through the code, which is no joy.

They are likely using something along the lines of option #3. But then
you never know with those guys. :)

>
> Under no circumstance do I recommend using Scripataculous. But I do
> find that bit clever.

Not really, but it depends on your perspective.

>
> 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 suppose you could always recalculate element positions if the page
> changes (potentially hard to know), or just periodically re-poll (which
> I've done), but perhaps it is only necessary to know which target you
> are closest to?

Context is key as usual. Your app should be in control of when (and if)
the document changes.
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: stop form submit
Next: Math ugliness.