Search and Top Navigation
#13880 closed bug (duplicate)
Opened August 04, 2015 08:08PM UTC
Closed May 04, 2017 03:38PM UTC
jQuery UI sortable - overlapping by 50% doesn't seem to work
| Reported by: | TomasM | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | none |
| Component: | ui.sortable | Version: | 1.11.3 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
A nice demo is at official website here:
I think that the tolerance option does not work as intended.
With tolerance: intersect, the item should overlap the other item by at least 50%.
I expect the elements to be swapped if one element overlaps the another by more than 50% of its height. But as you can see at the official demo page, if you drag the very first element at the very first pixels, you need to move the first element more than 150% (!!!!) of its height down in order for the plugin to detect reorder.
This is in my opinion very wrong bug. It should swap them if I only move the item 50% of its height. Am I missing something? Thank you
Attachments (0)
Change History (4)
Changed August 20, 2015 03:59PM UTC by comment:1
| status: | new → open |
|---|
Changed October 12, 2015 11:44AM UTC by comment:2
This needs to get a higher priority. This is not user friendly.
Changed May 08, 2016 12:57AM UTC by comment:3
The easy 'fix' should be at least to change the documentation to reflect the actual behavior, so at least developers know what to expect, and this could be done right away. So instead of 'The item overlaps the other item by at least 50%' it should say 'The mouse pointer overlaps the other item by at least 50%'. I think that's what it's really doing.
The bigger issue is that neither of the two tolerance values is very useful for sorting. I think when you sort items the pointer position shouldn't matter. The problem with pointer position is that if you have items of different sizes and you use containment: 'parent', it can be impossible to reorder the larger one over the smaller one when the smaller one is the first or the last item, depending on where you click on the larger one. What should rather matter is the edge of the dragged item vs the other one.
The behavior is definitely confusing, and the documentation is wrong, but I don't think we should change the behavior until the rewrite lands since it's a potentially breaking change for users. The actual behavior is based on the item size AND the pointer location within the item being dragged.