On Fri, Oct 31, 2008 at 4:20 AM, Aaron Boodman <[EMAIL PROTECTED]> wrote: >> Another item for consideration is whether or not the function should >> modify the existing DOM element (that is passed as an argument to >> registerDropTarget), or create a new element that is a child of that >> given element. > > I didn't get this part. From the code reviews, it doesn't appear that > you are modifying the DOM in any script-visible way. I think this is > important. It would be weird to add properties or children.
The current implementations (i.e. IE, Firefox) does not modify the DOM in a script-visible way. However, to get something working for Safari, we may have to insert a new element (and specifically, an <embed>). We might not need to, though, if we can somehow get access to the WebKit Objective-C APIs. I'm still experimenting. >> Such an interest might look like this >> options.contextAttributes = [ 'event', 'fileArray', 'fileMimeTypes' ]; >> desktop.registerDropTarget(domElement, options); > > It would be better to not have to register such interest. How much > extra IO is it to determine them? Can we do it asynchronously and just > not fire any events until we have the data? It's probably nicer not to have to register an interest - maybe I'm overly paranoid about future compatability. If the disk I/O is indeed a practical issue, async should work, so I'll drop this proposal. > * Returning false to ondragleave to accept the drag seems weird to me. > Why would anyone want to wait for ondragleave to accept the drag? > Similarly, returning false to ondragenter, ondragover, etc seems > meaningless to me. > > * I see nothing weird about returning false to 'accept' the drag. I > think of it less like 'accepting' (since that is kinda meaningless > with this API -- there's nothing to accept, you have already gotten > all the data in ondragdrop) and more like preventing the navigation > which would normally occur on drop. Strictly speaking, we only need return values for ondragenter and ondragover. By the time you (i.e. the page's Javascript) are returning from ondrop, you already have all we (Gears) could have told you, and similarly for ondragleave. I just thought it seemed more symmetrical if all four callbacks had a "return false when things go as expected (i.e. you're getting files)" convention.
