FLUID-148: Edge case: visual position of drop target when droppable is at beginning or end of a row.

Metadata

Source
FLUID-148
Type
Sub-issue
Priority
Major
Status
Open
Resolution
N/A
Assignee
Antranig Basman
Reporter
Joseph Scheuhammer
Created
2007-12-17T11:26:15.000-0500
Updated
2017-01-16T09:15:09.899-0500
Versions
  1. 0.1
  2. 0.3
  3. 0.4beta1
  4. 0.4
  5. 0.5beta1
  6. 0.5
  7. 0.6beta1
  8. 0.6
  9. 0.7
  10. 0.8
  11. 0.8.1
  12. 1.0
  13. 1.1
  14. 1.1.1
  15. 1.1.2
  16. 1.1.3
  17. 1.2beta1
  18. 1.2
  19. 1.2.1
  20. 1.3
  21. 1.3.1
  22. 1.4
  23. 1.5
  24. 2.0
Fixed Versions
N/A
Component
  1. Reorderer

Description

Using the lightbox as an example, if one drags an thumbnail to the left of the first item in a row, the drop target appears just after the last item in the previous row. This position is, in fact, correct. However, it would provide better feedback if it appeared at the beginning of the row that the user is dragging "within" (in this example). If however it was dragged to the right of the last item in a row, then the drop target should appear at the end of that row.

Environments

FF 50 (macOS 10.12)
FF2, FF3, Opera 9.6, Safari 3.2 (Mac OS 10.5)
FF4, Safari 5 (Mac OS 10.6)
Safari 3.2 (Mac OS 10.4)
FF2, FF3, IE6, IE7, IE8, Opera 9.6 (Win XP)
FF3, IE7, IE8 (Win Vista)
IE6 (Win 2000)

Comments

  • Shaw-Han Liem commented 2008-01-31T15:38:06.000-0500

    This is the behaviour we are deciding on for this case. The basic idea here is to show the drop affordance nearest to where the image will actually appear when dropped (even if this is different from where the mouse cursor is).

    1. Dragging on the first item in a row (Left half of thumbnail):
    We should show the drop affordance directly to the left of the item.

    2. Dragging on the last item in a row (Right half of thumbnail):
    We should show the drop affordance to the left of the first item in the NEXT row.

  • Anastasia Cheetham commented 2008-02-15T10:06:01.000-0500

    Actually, the two points described in the previous comment do hold if the item being dragged was not pulled from ahead of the drop target, but the points do not hold if dragged item was pulled from after the drop target location.

    Consider the simple case of two rows (for ease of discussion):

    If the dragged item was pulled from the first row, then if it is dropped at the end of the first row or the start of the second row, it will wind up at the end of of the first row.

    If the dragged item was pulled from the second row, then if it is dropped at the end of the first row of the start of the second row, it will wind up at the start of the second row.

    Thus IF we want to give an indication of where the image will appear after it is dropped, we would need to take into account where it was pulled from in addition to other considerations.

  • Antranig Basman commented 2008-08-15T16:42:11.000-0400

    Unfortunately, even with the current work on FLUID-1148, this issue is still not resolved - it is more problematic than it appears, and some of the analysis above isn't quite right.

    The issue arises because we are using "natural DOM flowing" for layout. Therefore elements (and indeed also the drop marker!) will naturally tend to appear "just where there is room for them". So the current behaviour is actually consistent, and undesirable - there is "almost always" room for a drop marker at the end of a row, but there is "never" room for a whole cell (since otherwise it would have appeared there). Therefore the drop marker always appears at the end of the "first row" (in Anastasia's walkthrough), but the actual item always appears at the start of the second row.

    It's hard to see on the face of it how we could resolve this, except by some rather odd requirements on the way we create drop markers (or the way we conceive of cells). One way to do this would be to create the drop marker inside the cell which starts the 2nd row - however, this represents a form of "DOM fascism" and may well in some cases create invalid markup (imagine the case where a cell is a <tr>).

    Well, actually, the above issue highlights some further problems - we could never actually have a drop marker within a table that was not itself a <tr> element. Therefore it seems the only way out of this is to add a parameterisation for the drop marker placement "strategy" as well as its creation.

  • Justin Obara commented 2008-10-31T10:09:05.000-0400

    design-watched