CHAPTER 9  WORKING WITH DRAG-AND-DROP

A dragend handler is called at the end of the drag, whether or not a drop actually occurred. If the user canceled the drag or completed it, the dragend handler is still called. This gives us a good place to clean up any state we changed at the beginning of the process. Not surprisingly, we reset the CSS classes of our lists to their default, unstyled state.

Sharing Is Caring

Brian says: “If you are wondering whether or not the drag-and-drop functionality is worth all of the event handler code, don’t forget one of the key benefits of the API: sharing drags across windows and even across browsers.

Because the design of HTML5 drag-and-drop was built to mirror that of desktop capabilities, it is not surprising that it also supports sharing across applications. You can try this out by loading our example in multiple browser windows and dragging members from one source list to the racers and volunteers lists of another window. Although our simple highlighting feedback was not designed for this case, the actual drop capability works across windows and even across browsers if they support the API.” Our drag-and-drop example is a simple one, but it illustrates the full capability of the API.

Getting Into the dropzone

If you’re thinking that handling all of the drag-and-drop events is complicated, you’re not alone. The authors of the specification have designed an alternative, shorthand mechanism to support drop events: the dropzone attribute.

The dropzone provides developers with a compact way to register that an element is willing to accept drops without coding up lengthy event handlers. The attribute consists of a few space-separated patterns that, when provided, allow the browser to automatically wire up the drop behavior for you (see Table 9-2).

Table 9-2.Tokens of the dropzone Attribute

Borrowing from our example application, the racers list element could be specified as having the following attribute:

234