Sortable: Specifications needed

Done (phew): http://jqueryui.pbwiki.com/Sortable

I can't speak for anyone else, but I can tell you what I need, in brief:

New functionality/bug fixes:

1) The placeholder needs to follow the helper more closely. Currently you can drop and item while the helper is on the opposite side of the screen. This leads to some pretty bad interactions with the other bugs in sortable

2) Somehow, elements that are not currently visible need to have lower precedence than items that are. Scrollable sortables wreak havoc on DnD operations.

3) Sub O(n) intersection testing. For any large number of sortable items the linear scan takes too long, especially on IE7, and is too inaccurate (see later commentary)

I can think of 3 general solutions to this problem. Some sort of 2d sort perhaps, but for my purposes searching for intersecting connectWith sortables and only then descending into them would probably suffice (most of my problems occur on pages with many drop targets). Otherwise, intersection test should be able to pick all relevant items, and then pick the best fit, not just the first that looks good.

Keepers, aka please don't break these:

1) Dragging anywhere below the last item in the Sortable append()s the placeholder to the sortable.

2) Scrolling (actually this could be better)

3) Ability to reject a drag operation (eg, beforeStop() { return false; })

4) Ability to reject after an ajax call (I do this by identifying the original location of the item from the event data)

5) Ability to drag the actual item

6) Reflow on drag (nice to have)

7) Clickable items inside of draggable ones (in my case, hyperlinks in the items)

8) Ability to set a move cursor

I've spent a lot more time poking around the code now and I have another request.

Each sortable has a full table of every other item in its connectWith containers. Probably the containers should do their own thing. This starts to get pretty bad even with only 3 containers, because you get 9 entries for each item. So that's probably priority 1, and could be fixed as part of a breadth-first search solution (ie, find the containers I'm intersecting with, then ask them about their items, rather than keeping my own cache).

Beyond that, it turns out that most of the time spent in sortable() relates to calculating the size of the 'items'. That's a pretty expensive proposition for large sortables, especially if all of the sortables are of uniform size.

So for each element you look up half to a dozen CSS rules, then repeat it for the next element. It would be nice to either be able to provide hints, or for the sizing code to notice that most of the sorted items have identical CSS and look it up once.

Duplicate of #6172.