I tried out your demo page and (literally!) the first thing I did had a bug in it. Just bad luck?
There's an off-by-one error while dragging an item from the left container to the right container, but only when my mouse has just entered the right box. If I continue dragging my mouse horizontally then the item's drop placeholder corrects itself.
Screencast requires flash player :( I wish the day where I can forget about flash player will be gone soon...I want to watch your screencast but Adobe won't trick me into installing their malware again...
I recently had to implement a drag and drop list, and found Sortable was a super easy to use and extensible library, with configurable callbacks for inserting your own logic in all the right places. It's also a stand alone library, which is nice.
I tried a bunch of others, but Sortable was the clear winner by a fair margin.
Here in my FF, they are smooth, but they make it feel very slow (at least I think it's the animations that cause this impression). I hope they are configurable, saw nothing in the readme, but I probably just missed it.
Odd. Here on Firefox/Linux using an underpowered laptop and 1080p monitor (indeed not the most optimal set up, but it's what I got right now), I expect most animations on modern websites to be janky.
But Sortable is completely smooth for me, yet Dragula lags or stutters a little.
I really wonder what the difference is?
I do have to say, even though they were slower, Dragula's drag-n-drop felt more "solid", in a way. Though I would guess that's some subtle clever placement tweaks, nothing that should affect performance.
It looks great! I would suggest adding an option of a delayed event, this way if you want to trigger a drag event you have to hold pressed for a second or so, this way it won't interact with touch scroll events of my phone
The one thing I don't like (i.e. inconsistent with the UIs of most OSes) is that if the user drags something to a valid target, and then before the mouse is released, drags it off that valid target to an invalid target, and then releases the mouse at that point, the valid target is triggered. What should happen is that the entire drag-and-drop operation should be cancelled, as if the user dragged straight to the invalid target and released.
I wouldn't want a DnD library to magically 'implement' accessibility for me. How would that even work in a one-sizzle-fits-all way? If I'm building a UI that needs both mouse interaction and keyboard interaction, I want to consider and build both those things, not expect all the keyboard stuff to happen automatically because I used a library to manage mouse events.
EDIT there's a bad autocorrect in there but I'm going to leave it
Just wondering if this library provided keyboard access only manipulation, would you have expected it to provide mouse events?
I'm biased on the keyboarding should be required perspective: I deal with accessibility day in and day out, and a library such as this had to be ripped out and removed from the organization, simply because junior developers would prototype and ship without thinking about that required use-case of keyboard access.
> I want to consider and build both those things, not expect all the keyboard stuff to happen automatically because I used a library to manage mouse events.
I understand what you're saying and commend you for it, but other developers might not want to implement all that themselves, or more often than not, might not even be aware that they have to. In other words, a JavaScript library with zero accessibility features gets added to one hundred websites over night, and in an instant, you have one hundred inaccessible websites. It is an all too common pattern in recent years, as most projects, even the big ones, don't even include accessible examples.
But this is a library. It's not a drop-in 'sortable list' component (which I agree could, and should, have built-in keyboard accessibility). It's a general purpose toolkit for setting up drag interactions.
Asking if it 'implements' keyboard accessibility is like asking if a box of hardware tools implements wheelchair accessibility – it might be possible to build something wheelchair-accessible using the toolbox, but that's up to you.
I completely agree that there are lots of devs who won't consider accessibility when using this or other DnD libraries, and that's a shame, but it's not the place of a DnD library to magically create an alternative keyboard UI that somehow corresponds with whatever drag-and-drop UI you've built using the library. That just couldn't work. A human needs to think about it.
You make some good points, and I agree that my original question, as it was phrased, isn't the best fit for a library such as this. Perhaps, what I should've asked is whether the demo, which developers will use as a jump-off point, implements any keyboard accessibility (it doesn't, by the way, so I'm not hopeful that any projects using this will be keyboard-accessible).
Author here. It's really easy to do. I implement tons of keyboard accessibility alongside dragula in my projects. In the demo it just felt out of scope. In one project I use dragula for a sprintboard, where you can cancel drags with Esc, drop with Enter, and move cards manually across columns with the arrow keys or a shortcut for each column (e.g 'o' for open)
So yeah, it's not part of the lib but it's deadbrain-easy to add on top.
I wouldn't totally write off HTML5 drag and drop, if you want to interact with other apps and enable drag between window it's the only game in town https://github.com/stevendwood/html5-dropzone
He wrote that article 6 years ago, before a lot of the latest standards were even semi finalized. So when he wrote it he was 100% correct. Now however that article is a bit out of date.
Thank you. I habitually avoid jQuery, it's almost always a lot heavier than I need it to be, and depend on libraries like yours to quickly add valuable functionality.
Where do you see this using jQuery.draggable? Or do you just mean it's a duplicate of draggable? Either way, dragula is drag and drop without a jQuery dependency, and in ~500 lines of code. This is a fantastic option for anyone who doesn't want to include jQuery or jQuery UI in their app.
This is what I'm using. Generally easy to use but there are a few CSS issues. GitHub page has people's workarounds but it hasn't been 'officially' updated for a while.
Edit: also, Gridster shuffles the panels around nicely in both axes and allows resizing which is very useful
I've been using it exclusively in a complex react app[0] for the past 3 months and I have absolutely no complaints whatsoever.
[0] - https://github.com/prakhar1989/react-surveyman