On Tue, Mar 30, 2010 at 2:54 AM, Stef Epardaud <[email protected]> wrote:
> On Tue, Mar 30, 2010 at 02:33:07AM -0700, Daniel Cheng wrote: > > But what was the rationale for preventing key events while doing > DnD? > > > > I'm not 100% sure, but I'm assume it's so that the process of dragging > and > > dropping doesn't trigger unrelated mouse / keyboard listeners. > > Unrelated yes, but that also prevents applications from adding DnD > functionality based on key presses. > > > Why not make the implied drag and/or dragstart explicitely fired > when > > external applications start DnD in the browser? That might make it > > simpler and more consistent. > > > > Because those events are intended for a source node. It introduces > several > > new problems (which node should get the event? how do authors > differentiate > > between the two different types of dragstart?) without really solving > > anything that isn't already handled by other events. If you have drop > > targets in your page, you don't really care about a drag and drop > operation > > in progress unless the item is dragged over your page--at which point > one > > can simply use dragenter / dragover / dragleave. > > How about registering the drag/dragstart on window.external? > > So you're saying that if I start dragging from a document element (say a > div) and from an external application over the document, in both cases a > dragenter listener registered on the body element should get fired even > when the drag is currently over a descendent of the body? > Same for dragleave when the drag is finished or the drag went out of the > browser window (to other external apps for example)? > > If so, then I can live with this. > Yep, as long as event propagation is not stopped. > -- > Stéphane Epardaud >
