Drag & Drop enhancements

[HeinrichApfelmus]

We should probably put the drag & drop attributes and events into a single module.

We should also add an example that showcases all the available events and attributes.

---

Also think about drag data. Ideally, we want to put arbitrary Haskell values there, though that would probably require an FFI construction à la StablePointer. This discussion is probably best left to issue #23, though.

[HeinrichApfelmus]

@daniel-r-austin I'm trying to create an example that showcase all the different drag & drop events, but somehow I'm having trouble getting certain events to fire. Could you take a look as you're the "drag & drop expert" here? :)

The idea ist that the colored text should be dragged into the colored boxes and the colored boxes should respond positively or negatively when something is dropped over them.

[fluffynukeit]

Ha, thanks for the vote of confidence. I'll try to take a look tonight or tomorrow if I can manage it. FYI I'll be on vacation from July 4 for 5 or so days and will be out of contact.

[fluffynukeit]

I unfortunately have not been able to figure this one out. It seems pretty clear to me that the dragleave event is being fired when you drag over the "Drop here!" text. You can see this more easily by making the width and height of the drop zones much wider; the color change of the text will work inside of the box as long as you're not dragging over the Drop here! text. Another way to see it is to make the on dragleave text color, say, orange. When dragging onto the box, you'll see the color change from the box color then quickly to orange.

Here is a stack overflow question that seems related, but I was unable to get the "pointers-events" solution to work at all. If it's still an issue when I return from my trip, I'll take a second look. Hope that helps!

[HeinrichApfelmus]

Oh dear, so the dragleave event is fired when the mouse is moved over a child event, because it has left the original element. Thanks a lot, I would never have guessed that!

This behavior is annoying because it does not work with our intuition of the droppable attribute. I would have expected that an element that is not droppable cannot receive dragenter and dragleave events, and that moving the mouse of child elements that are not droppable does not change anything about the "is being dragged over" status. It is also inconsistent with the drop element being fired on the element, even though it has already received a dragleave event which indicates that the mouse pointer has moved away.

I had hoped that I never have to read the HTML 5 drag & drop speficiation, but apparently, if we want to offer a model that is simpler to understand, we have to deal with it. :) (I don't think we should reproduce the HTML semantice because then every user of threepenny will have the same issues with trying to understand drag & drop. This is Haskell-land, after all.)

Judging from the drag-and-drop processing model, it appears that we can use the dropzone attribute to implement a model where droppable does the obvious thing. I will update our documentation to specify the behavior in more detail.

[HeinrichApfelmus]

It turns out that the HTML 5 specification for drag & drop is horrible and that browser implementations do not even conform to the spec. Well, well, who would have thought?

In consequence, I have changed the documentation to include warnings on whatever strange behavior I could observe. In the long term, we probably want to build our own drag & drop model. For instance, separate events on whether a drop was accepted or rejected would be nice, etc.

However, for a first release, I think the status quo will do.