taye

Gah! Thanks for mentioning this. What browser did you try it with?

I've never liked famo.us and never bothered to look into it so a rewrite for it won't happen (at least not by me). I'd like to think that if famo.us is any good then something like interact.js should be able to work with it without heavy modification or with a thin layer on top, but maybe I'm thinking too highly of my own work :-P.

That's due to hardware acceleration so really Chrome is buggy. I don't really know what to do about that.

Thanks for mentioning that. It's fixed now.

My heart sunk a little, before the ellipsis. You're welcome!

It's because of hardware acceleration something or other. I don't really know what to do about that :D. I saw the same thing on Chrome and Firefox on Windows until a few months ago. I don't have a Mac so... ¯\_(ツ)_/¯.

Thank you.

I wouldn't call it a subset and I didn't make it as an alternative to jQuery UI. However, I do have plans to make one ;-). I think that the advantage is in what interact.js doesn't do. It's more about providing the data that applications need for responding to pointer input however they like - Drag and drop is just one way to use the input data.

I wrote about the ideas behind it on the Mozilla Hacks blog recently: https://hacks.mozilla.org/2014/11/interact-js-for-drag-and-d...

I think that that sort of thing would better done in a separate library. I've actually been thinking about doing it myself but I haven't had the time.

Thanks! Unfortunately I've had only an Android tablet and Firefox OS phone to test the homepage extensively so I'm not surprised that the website has some usability problems on other devices and form factors.

> When you drag no-drop over the yes-drop div it appears on top. If you then drag yes-drop and go back to dragging the no-drop this then appears under the yes-drop div.

This is because before dragging, there's no CSS transform style. After dragging the transformation causes the element to be rendered above its siblings. Then when the other element is transformed it is then rendered above. I've added

  transform: translate(0px, 0px);

to both elements to fix that.

> Also I don't get what causes the highlight of the drop zones to activate. Percentage of shape? Center of Shape? Personally I prefer that it is the mouse pointer that activates the enter / leave and not the shape itself.

It's mentioned in the JS code comments

  interact('.dropzone').dropzone({
      // only accept elements matching this CSS selector
      accept: '#yes-drop',
      // Require a 75% element overlap for a drop to be possible
      overlap: 0.75,

You could instead set overlap to "pointer".

> Added: If you drag the yes-drop from the side to enter the drop zones, the outer zone looks like 50 pixels wide and yet the error or margin to drop it in there is about 2 pixels before you enter the inner zone.

The deepest dropzone element in the DOM gets drop priority if the element/pointer is over multiple dropzones.

Not presently. However, it's been on my mind for a while and as of now is priority numero uno.

Thanks

I hadn't actually thought about the Mac touch-pad and unfortunately I don't have easy access to one for testing.

Firfox doesn't fire paste events unless an editable element has focus. You would have to bring focus to an input element to make sure that an event is fired.

What if your site is a graphic editing web app using a <canvas> renderer? By convention users should be able to copy and paste graphical objects created within the app as well as paste text or images copied from elsewhere.

If you use keyboard short-cuts in your UI to copy into your app's memory but not the system clipboard then you have no way to know whether the data the user wants to paste was copied from your app or somewhere else. If you only use the system clipboard and inform the user that copy/pasting is done with right-click or key-combos and not the browser's "Edit" menu, you can handle copy-pasting predictably.

This was the most reliable method I could think of. Yes the browser's "Edit" menu is a problem and there's no way to get around that.

I don't have a mac. I was too lazy to get someone else's to test this. But I'm sure people reading can figure out how to get it working on macs :)

No apology necessary.

As I mentioned in another comment, I use NoScript to disable javascript so I wouldn't even notice that kind of thing. I agree that that is unnecessary and sort of abusive to users. I only intended on using this within web apps like a document editor etc.

I'm really not sure and I've been too occupied to try things out.

Detecting a long hold and then selecting the text before the usual mobile context menu pops up could be good enough. I only devised this solution for a desktop app.

I've never actually noticed any site doing that to me as I usually browse with NoScript.

I wrote that post with the intention of using the solution in apps to copy/paste app data in plain text - eg. selecting multiple objects in a drawing app and copying them as a JSON string.

I guess NoScript/Ghostery/AdBlock Plus could be considered solutions to your problem.