- From: Neil Deakin <enndeakin@sympatico.ca>
- Date: Wed, 18 Oct 2006 15:34:55 -0400
Some comments and questions: 5.5.1 Is the DragEvent supposed to inherit from Event? Wouldn't at least UIEvent be more reasonable? I'm not familiar with accessibility for drag and drop. Do platforms actually have a means of performing drag and drop that aren't mapped to mouse events? > The initDragEvent() and initDragEventNS() methods must initialise the event in a manner > analogous to the similarly-named methods in the DOM3 Events interfaces. [DOM3EVENTS] There aren't any such methods in the DOM3 Events. What happens when a script creates a drag event by calling initDragEvent(NS) and dispatching it? Should dataTransfer always be empty is this case? Is the addElement method used solely for the purpose of setting the image for dragging? Or, does it imply that the element itself is being dragged? (And that, for instance, dragging it into an HTML editor might copy the source for the element) What happens if setData, setDragImage, or addElement are called during any of the drag events other than dragstart? 5.5.2 In the chart, the dragend event has 'current drag target' listed for dropEffect, yet the text two paragraphs later says that this should be 'none'. 5.5.3 What happens in the following case: <div draggable="true"> <p>This is some text. <strong>Stronger text</strong></p> </div> Normally, starting a drag operation on html content, indicates to start a selection, not drag it. In the sample above, should a selection be started, or does this imply that the entire div is draggable when clicking and moving the mouse anywhere upon the text, and that it isn't possible to select the text by starting a selection within it? > If it is a selection that is being dragged, the dataTransfer member of the event must have > the text of the selection added to it as the data associated with the text/plain format. Is that the only format that should be available? Mozilla's internal drag and drop APIs also supplies a selection as serialized HTML using the format text/html (or images as an image type). Maybe the spec should clarify that the UA may supply additional formats if desired. If the data isn't available until the drop, there really isn't any way to know what to set dropEffect to during dragenter or dragover events, since it isn't known by the current target whether the data can be dropped there, not what drag effect can be used. The only real option would be to say 'yes, something can be dropped here, but if you try to, we still might not let you, and the drag cursor was just plain wrong'. So why does the spec go into such detail about what the effect should be? The spec makes no mention of the modifier keys when the drag is occurring. In fact, it seems to imply that the modifiers must be ignored when determining the drag cursor to use, and to use only the effectAllowed and dropEffect states. Normally, the modifier keys force a particular effect, if allowed, to be used. Just to clarify, the dragenter is sent to the current drop target, and then if not canceled, another dragenter event is dispatched at the <body>? Is the dragend event fired regardless of whether a drop occurred? (i.e. was successful or canceled) Typically, for move operations, the node may now be in the new location, should the dragend event still be fired? Personally, I think that the behaviour of textbox drag and drop is implementation specific, and the spec shouldn't define how text gets moved or copied from/to them. / Neil
Received on Wednesday, 18 October 2006 12:34:55 UTC