FWIW, I thought about this some more and I could also see the argument for returning true from ondragdrop. Since we have already diverged so far from the relevant HTML5 APIs, I don't think there's much risk of people confusing the two. I could go either way. Does anyone have anymore arguments one way or the other that could help us decide?
Also, I was wondering if we should use returning a special value from ondrag to mean that the cursor should be changed to indicate dropability. What do you think? - a On Sun, Nov 9, 2008 at 11:21 PM, Nigel Tao <[EMAIL PROTECTED]> wrote: > > On Mon, Nov 10, 2008 at 4:41 PM, Chris Prince <[EMAIL PROTECTED]> wrote: >> Is that conventional? I thought DOM callbacks generally returned >> *true* to indicate "yes, I understood what you wanted and I did >> something". > > > As discussed in my Big DnD e-mail, of which I've copied the relevant > snippet below. I don't think we came to a conclusion, but it > (returning false to do something) was briefly discussed. > > Nigel said: >>> The various callbacks (ondragenter, ondragover, ondragleave, ondrop) >>> should return false if they wish to accept the drag operation. This >>> may seem counter-intuitive to the usual programming convention that a >>> callback returns a boolean indicating success, but this is mimicking >>> the HTML5 idea that an event handler returns false to prevent the >>> default action, which in this case would be to navigate to the given >>> file (and away from the web app that wants the file drop). Note that >>> the JavaScript callback does not have to explicitly call >>> context.event.preventDefault(). > > And then Aaron said: >> Couple points here: >> >> * 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. >
