Sortable: Specifications needed

[rdworth]

Section 3 - Functional Specifications/Requirements on ​http://jqueryui.pbwiki.com/Sortable need to be written. Should include more than just a listing of API options. See ​http://jqueryui.pbwiki.com/Slider for an example.

[paul]

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

[jdmarshall]

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

[jdmarshall]

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

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.

[Scott González]

Duplicate of #6172.