[whatwg] Drag-and-drop feedback

[Ian Hickson]

On Mon, 31 Jan 2011, David Flanagan wrote:
> 
> nit: One of your old examples near the beginning of the DnD section 
> involves class="dragzone", which seems confusing now that you've added 
> an attribute with the same zone.  Maybe change that class to droppable?

The word "dragzone" doesn't appear in the spec anymore so hopefully this 
was addressed already.


> Say I want to create a library to emulate dropzone today, because it is 
> just so much nicer than all the dragenter and dragleave stuff.  In order 
> to do this right, I need to be able to tell if the browser already 
> supports dropzone. Will it work to test ("dropzone" in 
> document.createElement('div'))?

In theory, yes.


> If I understand correctly, the dropzone attribute means that we no 
> longer *have* to write dragenter and dragleave handlers.  But every 
> useful dropzone I've seen in practice provides some kind of feedback 
> (changes background color, e.g.) when it is "armed" and ready to accept 
> a drop.  Is there any mechanism for doing this?

Not yet, but we should add CSS selectors for this kind of thing. I 
encourage you to approach the CSS working group with suggestions for 
enabling the styling of drag-and-drop interfaces.

Specific needs are:

 - some way to be able to match an element that is being dragged over.

 - some way to be able to animate an element as it goes into and out of 
   this state (CSS transitions?), e.g. to be able to animate something
   "getting out of the way" to let you drop an item between others.

 - as an extension to the previous feature, a way to distinguish being 
   dragged above or to the left of the drag target vs below or to the 
   right of the drag target.

One pseudo-class with an argument should be able to handle that, say 
:drop-target, :drop-target(before), :drop-target(after).

If CSS can be so updated, I'd be happy to integrate with this in HTML.


On Mon, 14 Mar 2011, Jeb Boniakowski wrote:
>
> I would like to be able to paste images from the system clipboard into 
> web apps.  E.g. an annotated screengrab right into the bug tracker, a 
> pic into emails, an image from twitpic into a blog CMS's post screen.

The Clipboard API and Events specification hopefully addresses this use 
case:

   http://dev.w3.org/2006/webapi/clipops/clipops.html


> (note: there seems to a small typo in the current Editor's Draft: the
> getData() method only takes 'format', not a second parameter called
> 'data', right?  That's what the summary tables above say.  In either
> case, these should probably agree).

Fixed. Thanks.


> There's a range in what the browsers return for types.  In Safari
> (r80833), having a png on the clipboard shows you:
>  - com.apple.pasteboard.promised-file-url
>  - public.tiff
>  - NSPromiseContentsPboardType
>  - com.apple.webarchive
>  - public.utf8-plain-text
>  - dyn.ah62d4rv4gu8yc6durvwwaznwmuuha2pxsvw0e55bsmwca7d3sbwu
>  - text/uri-list
>  - Apple files promise pasteboard type
>  - application/x-webarchive
>  - dyn.ah62d4rv4gu8y6y4usm1044pxqzb085xyqz1hk64uqm10c6xenv61a3k
>  - dyn.ah62d4rv4gu8zs3pcnzme2641rf4guzdmsv0gn64uqm10c6xenv61a3k
>  - WebURLsWithTitlesPboardType
>  - dyn.ah62d4rv4gu8yc6durvwwa3xmrvw1gkdusm1044pxqyuha2pxsvw0e55bsmwca7d3sbwu
>  - CorePasteboardFlavorType 0x75726C6E
>  - CorePasteboardFlavorType 0x75726C20
>  - text/plain
>  - public.url-name
>  - NeXT RTFD pasteboard type
>  - public.url
>  - com.apple.flat-rtfd
>  - com.apple.pasteboard.promised-file-content-type
>  - image/tiff
> 
> Whereas the Chrome I have (10.0.648.133) shows me:
>  - text/html
>  - text/uri-list
>  - url
> 
> Firefox (3.6.15):
>  - text/x-moz-url
>  - text/x-moz-url-data
>  - text/x-moz-url-desc
>  - text/uri-list
>  - text/_moz_htmlcontext
>  - text/_moz_htmlinfo
>  - text/html
>  - text/plain
> 
> I don't think this contravenes the spec, except that for all of those 
> rich types in Safari, you don't actually get anything when you ask for 
> it.  The spec doesn't really mandate anything that you have to do with 
> any specific types of data on the clipboard, which especially makes 
> sense when considering data that originates outside the browser.
> 
> This has one interesting implication though for data that originates
> inside the browser: drag/drop or paste with images loaded from data
> URIs.  Currently, the clipboard behavior of these is interesting but
> varies:
>
>  - Chrome will return an img tag with the data uri intact, with the 
> Base64-encoded data for type "text/html" (preceded by a meta tag telling 
> you you're getting html)
>
>  - Firefox does pretty much the same thing, minus the meta tag
>
>  - Safari doesn't present a "text/html" type in this case.  However, it 
> does provide a "text/plain", which contains *just* the data uri itself.
> 
> Now, this situation isn't preventing anyone from doing anything, as far 
> as I can tell, but would it be crazy to try to normalize this in the 
> HTML5 spec?

I don't think it would be crazy. Ambitious, maybe. :-)

The one type it seems you would really want is image/png. I don't see that 
in any of the lists above. The place to start, then, might be in seeing if 
the browser vendors would be willing to implement that; if they are, it 
makes defining a common subset of what they do that much easier.

However, as you say in your e-mail (not quoted here), maybe the better 
solution is to focus on the newer aspects of the DND API.


> Briefly, it looks to me like the use cases were more thought out here 
> for interacting with system drag-drop than with copy-paste.  Excuse me 
> if that isn't the case, and the idea of richer copy-paste was just 
> considered to be out of scope.

It is definitely the case that D&D was the focus here. However, it should 
work fine with C&P too; the models are more or less equivalent.


> According to the spec, with this API implemented, there will be no way 
> to copy an image from a tab, and paste it into another tab (assuming the 
> browser itself doesn't do something crazy like...bounce the system 
> clipboard to a temporary file on paste and give you the filename 
> somewhere).  The DataTransferItem can be of two kinds: a string, or a 
> string referring to a file, so this lets you drag String-y data off your 
> system and into a tab, and it also lets you presumably use Drag/Drop 
> instead of the system's file browser to attach files.

You can also get a File object (which is a superset of Blob with a 
filename). In due course we'll add Blob support too.


On Mon, Mar 14, 2011 at 9:22 PM, Daniel Cheng <dcheng at google.com> wrote:
>
> I'm currently 60-75% complete landing the patches for image paste support in
> Chrome. I've chosen to expose image/png instead of a raw bitmap through
> event.clipboardData.items in Chrome as a Blob. DataTransferItem::getAsFile()
> is currently specced to return a File; in my local changes, it secretly
> returns a Blob instead. I think it may make sense to rename it to
> getAsBlob() and change the corresponding add() method in DataTransferItems
> to take a Blob. I think these basic changes should support the use case you
> want if it gets more widely implemented.

The spec actually has a getAsBlob(), it's just commented out (search the 
source file for DND-v3). If you want to implement it, I can put it in, 
it's all ready already.


On Mon, 14 Mar 2011, Glenn Maynard wrote:
> 
> PNG compression is expensive; on a larger image it may take 5-10 
> seconds; more for more aggressive compressors.  This wants an async API, 
> so compression doesn't block and compression can be threaded.  (A 
> mechanism that can support Progress Events would make a lot of sense, 
> too--something for much later, of course, but should at least be kept in 
> mind, since func(successCb, errorCb) interfaces don't handle that 
> nicely.)

Also commented out is an API for copying and dragging promises rather than 
complete files, which addresses this async issue. I haven't put it in yet 
because we're still waiting for the basics of the new API features to be 
supported. One thing at a time.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'