Just built a pretty significant business application with a UI based on HTML5 drag and drop. There were certainly a few quirks, but it was nothing compared to web development in "the old days". Without any library the whole DnD song and dance is implemented as part of a React component that's only about 100 lines of JavaScript.
There are two places likely to trip you up. One of them is as mentioned in the original article: it's hard to remember which events need to have their default prevented. At the moment we're calling `preventDefault` in `onDragOver` which is required to identify the element as a drop target, and `stopPropagation` in `onDrop` which I believe is to prevent many browsers' default attempts to navigate to a dropped url-like thing.
The other potential pitfall is that, for security reasons, the data can only be read in `onDrop`, not in `onDragOver`. If you have a string id you don't mind being downcased you can just use the hack of sending that through the data transfer types (eg. as type "id/12345"), with a "text/plain" fallback.
> There are no less than seven events associated with drag and drop: dragstart, drag, dragover, dragenter, dragleave, drop, and dragend.
> This seems rather a lot for a series of actions that can be accurately described by the mousedown, mousemove, and mouseup events.
Mouse events also include mouseover, mouseout, mouseenter, and mouseleave.
The start/over/enter/leave events serve useful purposes, notably that you can offer UI cues to the user. For instance, if you drag an image onto an image search page that normally accepts text, the search box can become a giant drop target with "drop image here to search" text. And if you drag a non-image onto the same page, the page can check the MIME type and give the user UI that says that won't work.
The author gets into that in "dragthat and dragsomethingelse," where they talk about the problem with dragenter and dragleave behaving like mouseover and mouseout, events which fire many times in situations where you generally don't need them to.
Nothing you said is incorrect, nor do I behave differently (who doesn't utilise JQuery?).
That being said; it seems like a copout to ignore glaring issues while waving our collective hands in the air and saying "just use a library to abstract it!"
One of the reasons libraries are as popular as they are (particularly JQuery which does "nothing" except provide an abstraction) is because the standards are so weak and cross browser support so incomplete.
A lot of people think we're currently in a great place in terms of web-development. I actually disagree. We're still in a bad place, it just so happens that were were in an even worse place previously (e.g. IE6 era).
Is there any real motive in the standardisation community or web community in general to make the spec' good enough so JQuery is no longer required by 9/10 websites? Why isn't $('#something').click(); built in yet?
If someone was using angular and wanted to use the native html5 drag and drop, I created a directive for it here https://github.com/ganarajpr/angular-dragdrop if you are interested.
Having read the blog ( from top to end ) I kind of agree with some of the things that the author says. There are a few edge cases that we need to take care of if using native drag and drop. There is also the not-so-slight issue that it doesnt work on mobile browsers....
About prevent default: You need to tell the browser that this element will handle the drop/has handled the drop, or it will perform its default operation. What is it's default operation? To load the file/URL that you just have dropped onto the browser window.
Or maybe you have multiple drop areas stacked on each other. Should the event propagate to the parent element or not?
Ok, why is it done in JavaScript and not simply with dropzone="true"? Because you want to be able to let script logic decide if that drop/dragover event is eaten or not.
I stopped reading at some point, but I wonder if the author has ever implemented D'n'D support in any other language. It works very similar to this in I guess most GUI APIs. Maybe that is another reason why it works like that in HTML5?
I sympathize with your argument, but unfortunately it doesn't seem to be correct.
Arguably, you should be able to implement just the 'drop' event and call event.preventDefault() in that event to suppress the default behavior of loading the file/URL. I don't see a clear reason why any other event should matter, the actual action that triggers the load is dropping.
As for propagation to parent elements, that's not controlled by event.preventDefault(), that's controlled by event.stopPropagation().
I do agree that the author doesn't seem to realize that drag & drop is actually rather complex and that other languages look similar (e.g. large number of events). But the quirks around when you have to call preventDefault() do seem to be legitimate issues.
It really should only be used to drag and drop files from another application. If you just want to move elements around on the page mousedown, mousemove, and mouseup are all you need. I don't think we need a new API for this as it is pretty straightforward to roll your own.
But future devs shouldn't have to "roll their own" when someone's done it before. Why not just rewrite the standard and make it sane? JQuery shouldn't be the de facto JS library, those features should be (and are being) integrated into HTML already.
One of the best and well explained issues with the HTML5 DnD.
The specs for DnD are written very well but the implementation is brilliantly fucked up that the only way you are left is to use a library and enjoy the hardwork of someone who spent hours getting smeared in the dirt.
> Web developers MUST NOT (in the sense of RFC 2119) use HTML 5 drag and drop. They should use old-school scripts instead.
As far as I remember if you do that (i.e. if you use mousedown, mouseover, etc and move your dragged element accordingly), the result won't be nearly as good as with "native" drag and drop, and you will see the dragged element lagging behind the cursor.
That and sharing state with other windows is nearly impossible whereas HTML5 DnD makes multi-window stuff seamless. But I agree when he says that, as it is, HTML5 DnD is ridiculously difficult to implement properly.
Step 1 to being a web developer, search Google first. More than likely anything you need done has been done 10,000 times and there are at least 100 tutorials.
Don't be afraid to use libraries such as jQuery,which HTML5 drag-and-drop doesn't require, but I see that you mentioned avoiding it in another comment. Libraries many times also have the advantage of increasing browser support transparently, which is generally a good thing.
Worried about loading time with libraries? Use a CDN such as http://cdnjs.com/, most users will have the popular ones already cached in their browser.
Use StackOverflow if you have questions, that's what it's there for. Hacker News is for... news.
* I looked into those, but wow wow wee wow are they complex. I'll be working with cloning/moving DIVs instead, especially because HTML5 isn't supported everywhere.
* I prefer to avoid libraries when possible, especially when diametrically opposed ones are in use (I'm making an Angular app, JQuery doesn't always play nice).
* Thank you for the tip about http://cdnjs.com/, I'll be using it in the future.
* Hacker News is news, but it's also about discussion. That and I've personally never heard of how bad HTML5 DnD was, I thought the community might benefit from looking into it too.
I've seen this naming pattern a couple of times in articles submitted to HN. The "... considered harmful" pattern starts with Dijkstra, "GOTO statement considered harmful"[1]. It doesn't mean "such-and-such feature is implemented incorrectly." It means, "such-and-such feature, even when implemented correctly, gives programmers at large the wrong notions."
So, one would say "singletons considered harmful". The entire notion of singletons is wrong. But the entire notion of drag/drop events is not wrong. Just the implementation.
A pattern which really reached its apex over at Ward's Wiki [0]. It really should be reserved for concepts generally broken. I'm pretty sure I saw somewhere recently an article about "...considered harmful."
Edit: Ah, yes, Eric Meyer [1], complaining about "...considered harmful" seven years prior to the original article. :-)
what he says is still valid,the spec hasnt changed,is broken even or recent browsers such as Chrome ,is complicated and confusing.It's another exemple of half baked spec written by people that are never going to use it,just like app cache.
Frankly HTML5 is a disaster(and no , things like WebWorkers or WebSockets are not part of the HTML5 spec before anyone jumps on me).
It's just hard to build something robust on weak foundations,but that's lot of client side developpers, making these things work even though specs are just not helping.
Updated the title to reflect that, thanks. Really makes you wonder though; why hasn't HTML5 Drag and Drop been simplified yet? I personally have no idea what to do, besides adding JQuery.
I agree, his language is incredibly inflammatory and generally unnecessary. But he's done a really good job of writing up the flaws, so I suppose the tradeoff in this case was worth it.
[+] [-] couchand|11 years ago|reply
There are two places likely to trip you up. One of them is as mentioned in the original article: it's hard to remember which events need to have their default prevented. At the moment we're calling `preventDefault` in `onDragOver` which is required to identify the element as a drop target, and `stopPropagation` in `onDrop` which I believe is to prevent many browsers' default attempts to navigate to a dropped url-like thing.
The other potential pitfall is that, for security reasons, the data can only be read in `onDrop`, not in `onDragOver`. If you have a string id you don't mind being downcased you can just use the hack of sending that through the data transfer types (eg. as type "id/12345"), with a "text/plain" fallback.
[+] [-] JoshTriplett|11 years ago|reply
> This seems rather a lot for a series of actions that can be accurately described by the mousedown, mousemove, and mouseup events.
Mouse events also include mouseover, mouseout, mouseenter, and mouseleave.
The start/over/enter/leave events serve useful purposes, notably that you can offer UI cues to the user. For instance, if you drag an image onto an image search page that normally accepts text, the search box can become a giant drop target with "drop image here to search" text. And if you drag a non-image onto the same page, the page can check the MIME type and give the user UI that says that won't work.
[+] [-] Gracana|11 years ago|reply
[+] [-] angersock|11 years ago|reply
Read the rest of the article: there's a lot of other stupid API shit that heavily outweighs any clever little benefits.
[+] [-] mrec|11 years ago|reply
Not to mention onclick and ondblclick, which really needs access to the OS-level double-click delay setting if you want it to behave properly.
[+] [-] romaniv|11 years ago|reply
Fancy events could be added incrementally, later.
[+] [-] InfiniteRand|11 years ago|reply
If I could not use a library, I would look for the unminified code of a library and copy and paste it the relevant section.
Because ultimately, unless things go wrong and I need to dig deep, I have better things to do than mastering yet another complex web api.
[+] [-] Someone1234|11 years ago|reply
That being said; it seems like a copout to ignore glaring issues while waving our collective hands in the air and saying "just use a library to abstract it!"
One of the reasons libraries are as popular as they are (particularly JQuery which does "nothing" except provide an abstraction) is because the standards are so weak and cross browser support so incomplete.
A lot of people think we're currently in a great place in terms of web-development. I actually disagree. We're still in a bad place, it just so happens that were were in an even worse place previously (e.g. IE6 era).
Is there any real motive in the standardisation community or web community in general to make the spec' good enough so JQuery is no longer required by 9/10 websites? Why isn't $('#something').click(); built in yet?
[+] [-] ganarajpr|11 years ago|reply
There is documentation as well in here : http://ganarajpr.github.io/angular-dragdrop/
Having read the blog ( from top to end ) I kind of agree with some of the things that the author says. There are a few edge cases that we need to take care of if using native drag and drop. There is also the not-so-slight issue that it doesnt work on mobile browsers....
[+] [-] fiatjaf|11 years ago|reply
[1]: http://draggabilly.desandro.com/
[+] [-] striking|11 years ago|reply
[+] [-] panzi|11 years ago|reply
Or maybe you have multiple drop areas stacked on each other. Should the event propagate to the parent element or not?
Ok, why is it done in JavaScript and not simply with dropzone="true"? Because you want to be able to let script logic decide if that drop/dragover event is eaten or not.
I stopped reading at some point, but I wonder if the author has ever implemented D'n'D support in any other language. It works very similar to this in I guess most GUI APIs. Maybe that is another reason why it works like that in HTML5?
[+] [-] eridius|11 years ago|reply
Arguably, you should be able to implement just the 'drop' event and call event.preventDefault() in that event to suppress the default behavior of loading the file/URL. I don't see a clear reason why any other event should matter, the actual action that triggers the load is dropping.
As for propagation to parent elements, that's not controlled by event.preventDefault(), that's controlled by event.stopPropagation().
I do agree that the author doesn't seem to realize that drag & drop is actually rather complex and that other languages look similar (e.g. large number of events). But the quirks around when you have to call preventDefault() do seem to be legitimate issues.
[+] [-] iza|11 years ago|reply
[+] [-] striking|11 years ago|reply
[+] [-] aniketpant|11 years ago|reply
The specs for DnD are written very well but the implementation is brilliantly fucked up that the only way you are left is to use a library and enjoy the hardwork of someone who spent hours getting smeared in the dirt.
[+] [-] mraison|11 years ago|reply
As far as I remember if you do that (i.e. if you use mousedown, mouseover, etc and move your dragged element accordingly), the result won't be nearly as good as with "native" drag and drop, and you will see the dragged element lagging behind the cursor.
[+] [-] striking|11 years ago|reply
[+] [-] JoshTriplett|11 years ago|reply
[+] [-] ascotan|11 years ago|reply
[+] [-] josu|11 years ago|reply
[+] [-] dm2|11 years ago|reply
http://www.html5rocks.com/en/tutorials/dnd/basics/
http://html5demos.com/drag
I don't understand why this is an issue, there are tons of great tutorials: https://www.google.com/search?q=HTML5+drag-and-drop
Step 1 to being a web developer, search Google first. More than likely anything you need done has been done 10,000 times and there are at least 100 tutorials.
Don't be afraid to use libraries such as jQuery,which HTML5 drag-and-drop doesn't require, but I see that you mentioned avoiding it in another comment. Libraries many times also have the advantage of increasing browser support transparently, which is generally a good thing.
Worried about loading time with libraries? Use a CDN such as http://cdnjs.com/, most users will have the popular ones already cached in their browser.
Use StackOverflow if you have questions, that's what it's there for. Hacker News is for... news.
[+] [-] sfvisser|11 years ago|reply
> Don't be afraid to use libraries such as jQuery, ...
So, bad specs are not an issue because there are tutorials explaining how to use them and there are slightly better abstractions on top of them?
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] striking|11 years ago|reply
* I prefer to avoid libraries when possible, especially when diametrically opposed ones are in use (I'm making an Angular app, JQuery doesn't always play nice).
* Thank you for the tip about http://cdnjs.com/, I'll be using it in the future.
* Hacker News is news, but it's also about discussion. That and I've personally never heard of how bad HTML5 DnD was, I thought the community might benefit from looking into it too.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] mereskin|11 years ago|reply
http://mereskin.github.io/dnd/
[+] [-] chiubaka|11 years ago|reply
[+] [-] moron4hire|11 years ago|reply
So, one would say "singletons considered harmful". The entire notion of singletons is wrong. But the entire notion of drag/drop events is not wrong. Just the implementation.
[1] It's interesting to read some of the counter-arguments, and reflect on programming language design arguments we have today: http://web.archive.org/web/20090320002214/http://www.ecn.pur..., and Dijkstra's own commentary on the whole ordeal is--as usual--entertaining http://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1009.PDF
[+] [-] couchand|11 years ago|reply
Edit: Ah, yes, Eric Meyer [1], complaining about "...considered harmful" seven years prior to the original article. :-)
[0]: http://c2.com/cgi/wiki?search=ConsideredHarmful
[1]: http://meyerweb.com/eric/comment/chech.html
[+] [-] jackweirdy|11 years ago|reply
Could you expand on that? Haven't heard this argument before
[+] [-] onion2k|11 years ago|reply
[+] [-] aikah|11 years ago|reply
Frankly HTML5 is a disaster(and no , things like WebWorkers or WebSockets are not part of the HTML5 spec before anyone jumps on me).
It's just hard to build something robust on weak foundations,but that's lot of client side developpers, making these things work even though specs are just not helping.
[+] [-] striking|11 years ago|reply
[+] [-] shangxiao|11 years ago|reply
[+] [-] striking|11 years ago|reply