Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating drag images #110

Closed
mhelvens opened this issue Nov 29, 2015 · 6 comments
Closed

Creating drag images #110

mhelvens opened this issue Nov 29, 2015 · 6 comments

Comments

@mhelvens
Copy link

Hi there,

I tried using rasterizeHTML to create a drag-image for the HTML5 drag-and-drop API, but no luck so far. The drag image always appears empty:

function ondragstart(event) {
    let canvas = $('<canvas>')[0];
    rasterizeHTML.drawHTML(`<strong>Dragging HTML!</strong>`, canvas);
    event.dataTransfer.setDragImage(canvas, 0, 0);
}

I guess it's because rasterizeHTML works asynchronously, and the drag-and-drop API expects to receive the drag-image canvas synchronously. Setting the drag image after the drawHTML promise resolves doesn't work either. It then appears as if no custom drag image was set at all.

Is it possible to support a 'synchronous mode' (obviously with some limitations)? Or if I'm just doing something wrong, please let me know?

@cburgmer
Copy link
Owner

Hey, interesting use case.

Indeed, there is quite a bunch of asynchrony going on internally. Quite some of it that could be worked around with a bunch of limitations though. However it looks like the core issue will be with the code actually building an image object from the underlying SVG object (see https://github.com/cburgmer/rasterizeHTML.js/blob/master/src/svg2image.js#L106). This I believe will always be asynchronous. You could double check with trying to construct an image in the code you've provided (replacing the call to rasterizeHTML)..

@mhelvens
Copy link
Author

There's an example on MDN. It uses an Image directly (no canvas needed). Does that answer your question, or is there something more specific about the svg part that has to be asynchronous?

@cburgmer
Copy link
Owner

Interesting, so Firefox does support painting the image, even if we pass in something that hasn't loaded yet?!

So I don't think hope is lost for you, however rasterizeHTML might be too heavy weight for your use case: apart from waiting for the image to be loaded, asynchrony comes in from executing JavaScript, calculating the image's canvas size, loading external references, checking for browser compatibility (blobs, workarounds for sandboxing issue), and more...

Most of that, if not all, might be optional for you, but making this optional for this library will be quite a challenge. In your case you might just want to have a look at https://github.com/cburgmer/rasterizeHTML.js/blob/master/src/document2svg.js#L69, which is amongst the core functionality of the library. In your case, understanding what is happening there might be the best step forward for you to implement a lightweight version for yourself. This does not mean I intend to leave you alone with this, I'm happy to provide context along the way.

However, if you are up for it, we could identify the minimum set required to generate an image from HTML in a synchronous fashion and pull it out into a small library. rasterizeHTML has gotten bigger continuously, so breaking out functional chunks would be nice.

@mhelvens
Copy link
Author

I understand. There is a hack out there which I'm currently using. It involves hiding the desired drag-image element behind another element on the page (it has to be in the DOM tree and positioned within the bounds of the viewport to qualify, but apparently you can still obscure it).

I will keep using that hack for now, because I can't afford to spend much time on this. But just so you know, should you want to implement this in the future: There are developers out there who would see rasterizeHTML as a more elegant solution to the drag-image problem (no matter how 'hacky' the library is inside; at least it's well tested and encapsulated).

@cburgmer
Copy link
Owner

cburgmer commented Dec 1, 2015

Sounds reasonable! Let's keep the issue open as a feature request for a synchronous call.

@cburgmer
Copy link
Owner

I'll close this issue as we can let #155 track this feature request. Feel free to re-open if you feel we've missed something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants