- This topic is empty.
May 3, 2016 at 5:00 am #241174
I was playing around with @Shikkediel’s vanilla JS draggable script and decided to merge it with what I had so far with the dock-to-sidebar widget demo.
I also added local storage save functionality (where each display state and position is saved when widgets are moved or docked).
You’re welcome to further modify it for your needs: http://fofwebdesign.co.uk/template/_testing/widgets-show-hide-dock-drag-local-storage.htmMay 3, 2016 at 5:45 am #241176
Sorry @Allie_P, I hadn’t noticed you posted another question. Both random placement scripts should work fine and they’re more or less the same, I recall the one I proposed is just a bit more basic. The choice of draggable code generally depends on if you’re using jQuery already or not. Functionality isn’t much different.May 5, 2016 at 11:38 am #241272May 5, 2016 at 12:10 pm #241275
Seems fine here. What device/browser have you noticed a problem on and in what circumstances?May 5, 2016 at 12:12 pm #241276
Might be the (lack of) z-index thingy… I was thinking about adapting my Codepen scripts for multiple elements but I suspect Beverly could fix in it a jiffy.May 5, 2016 at 12:28 pm #241277
OS X / Safari
They get stuck all the time when I try to drag them across the screen.
Have a look: https://streamable.com/8tf6May 5, 2016 at 3:01 pm #241281
Sorry, I don’t have that environment to test in :(
Only iOS /Safari
What z-index change do you suggest Shikkediel? Do you have access to OS X at your side too?May 5, 2016 at 3:08 pm #241282
Nope, no option to check on any Applish device. Windows 7 here…
What z-index change do you suggest
Just lifting the currently dragged item above all other content, any higher placed element can prevent fluid dragging at the moment when they are overlapping.
Or maybe even keeping track of all z-indexes and leaving the items in the last recorded order but that’s a bit more complicated of course.May 5, 2016 at 4:02 pm #241284
I’ll look at z-index again tomorrow on Windows 7/8/10 + Android, but on iOS (on iPhone at the mo) the z-index doesn’t seem to pose a problem. The dragged boxes maintain fluid dragging even when they pass underneath other elements.May 5, 2016 at 5:28 pm #241285
Hmm… looking back at the code, it might be up for a small revision. I suppose I used the following so it was easier to pass on
thisbut it probably makes more sense to use
windowinstead here :
this.addEventListener('mousemove', dragIt, false);
Meaning some other lines would have to be changed as well… but the overlapping issue should disappear.May 6, 2016 at 3:42 am #241293
OK – I’m back in the office now and can see that a really fast drag will cause the mouse to lose contact with the widgets, but a moderate-to-fast drag seems fine. I think its a reasonable expectation for users to move the widgets in a ‘purposeful’ way if they want to actual place them elsewhere, otherwise just close them altogether. Just my thoughts though.
Anyway, I added the z-index change to lift dragged widgets to the foreground, and then return them to ‘auto’ z-index when dropped. This is done with the addition and removal of a ‘.move’ class so that other CSS decorations can be applied during the drag action (such as a box-shadow).May 6, 2016 at 8:14 am #241306
Hardly bothersome indeed and an easier fix. Works well.May 6, 2016 at 12:32 pm #241325
I’m pretty happy with it too. Yey for teamwork! :DMay 8, 2016 at 11:30 am #241369
I think its a reasonable expectation for users to move the widgets in a ‘purposeful’ way if they want to actual place them elsewhere, otherwise just close them altogether.
Sorry, but I’m gonna have to disagree. I think on a big screen is pretty easy/common to drag something from one side to the other with a short but fast movement. :(
Here’s what I was able to accomplish so far:
For the positioning I used this pen but for some reason it keeps aligning the objects. I have
var ensued = false;so I’m not sure why that’s happening. Any ideas?May 8, 2016 at 1:47 pm #241372