[whatwg] Drag-and-drop feedback

[Ian Hickson]

On Tue, 2 Nov 2010, Charles Pritchard wrote:
> On 11/1/2010 6:03 PM, Ian Hickson wrote:
> > On Thu, 26 Aug 2010, Charles Pritchard wrote:
> > > On 8/25/2010 2:02 PM, Ian Hickson wrote:
> > > > On Mon, 2 Aug 2010, Charles Pritchard wrote:
> > > > > >
> > > > > > [ UAs can use <input type=file> to let the user enter remote 
> > > > > > URLs ]
> > > > > 
> > > > > When a user through selection, click+drag or manual entry of a 
> > > > > URL should the browser still submit an Origin request header? It 
> > > > > seems that CORS doesn't come into effect here -- but at the same 
> > > > > time, it'd be handy for logging purposes and added security.
> > > >
> > > > I don't think there'd be an origin, but that's rather up to the 
> > > > user agent. (In this case it's acting on behalf of the user, not 
> > > > the page, so I don't think it makes sense to give the page's 
> > > > origin.)
> > >
> > > Sounds like an implementer would not include a Referer header, 
> > > either.
> >
> > Possibly.
> 
> Is this something we want to leave undefined? As the <input type="file"> 
> widget typically routes directly to OS-level file management, I don't 
> think there's a simple solution to bringing more control to the browser.

I don't really see anything wrong with leaving this undefined; it's just a 
user feature, not something the Web page can have any control over.


> > > Continuing on with tweaking URLs to work with with the File API:
> > > 
> > > Chrome has gone ahead with their setData proposal, enhancing the 
> > > event.dataTransfer object so that users may drag a file from within 
> > > the browser onto their desktop.
> > > 
> > > The extension uses setData with a key of DownloadURL and a value 
> > > including a mime type, file descriptor and URI.
> > > 
> > > I'd like this interface to work within ondrop; if 
> > > getData(DownloadURL) is set, then a FileList would be returned in 
> > > event.dataTransfer.files, much like it is when users drag files from 
> > > their desktop into the browser.
> > > 
> > > This would of course require Origin checks; whereas dragging onto 
> > > the desktop does not require an Origin check.
> >
> > I'm not quite sure I follow what you are proposing. However, in a 
> > future version of this API we should definitely add a "promise"-like 
> > feature that lets you specify drag data without having it already 
> > downloaded, so that when the user drops the data somewhere, the 
> > browser can then ask the JS for the data. I'm not sure using 
> > setData('DownloadURL') is a good way to do it; that just seems to add 
> > more hacks to an already pretty hacky API.
>
> The DataTransferItem proposal is heading in this direction. Currently, a 
> file collection ".files", works with the File API and XmlHttpRequest. 
> Drag+drop from the desktop returns file objects.
> 
> I'm proposing we explore methods to enable drag+drop from within the 
> browser to return file objects.
> 
> The FileSystem API is a resource: we can now build a file from within 
> standard APIs. Until that point, we could only use the BlobBuilder 
> semantics.
> 
> The proposal DataTransferItem.add(fileData) pretty much takes care of 
> the request (when used with a working/complete FileSystem API).
> 
> We still need a promise-like feature, as you've pointed out.

This all seems reasonable at a high level, but it's probably too early to 
start adding this kind of feature today. I've noted things along the lines 
of what you describe in the spec as possible "v2" material.


> On a side note -- I've been having a lot of issue with building blobs:

For blob issues, public-webapps is probably more appropriate as that is 
where the File API specs are being discussed.


On Tue, 2 Nov 2010, Daniel Cheng wrote:
> > On Tue, 9 Mar 2010, Daniel Cheng wrote:
> > >
> > > I think files have always been a special case and should continue to 
> > > be handled that way. I don't think there's any platform pasteboard 
> > > that supports multiple items of one non-file type, so it'd make the 
> > > most sense to make it a 1:1 mapping from types to data.
> >
> > Currently the new DataTransferItems API doesn't enforce the limit of 
> > one "string" item per type. Should it?
> 
> What happens if a page were to add multiple string items of "text/plain"?
> How would that translate if dragging to a native app? There's also some
> implementation concerns here--it'd be harder/require more memory to preserve
> multiple strings of the same type when dragging things within a page.
> (If/when Blob support is added, the same comments generally apply)

Ok, I've limited the API to only one "string" item per type.


On Tue, 16 Nov 2010, Charles Pritchard wrote:
> 
> How close are we to adding promises?

I think it's probably a little early given that no implementation has yet 
implemented the DataTransforItems object (as far as I know).


> > > * I am worried about the effectAllowed attribute. Needless to say 
> > > that the number of value is exponencially proportional to the number 
> > > of possible values for the dropEffect attribute. Wouldn't it be 
> > > better to have a linear number of booleans ?
> >
> > Yes, but it's about 10 years too late to change that.
> 
> This section should (and is?) be kept up with WAI-ARIA.
> 
> The concept here, of effectAllowed, is semantic, much like HTML. If your 
> use-case doesn't fit the minimal vocabulary, you can use your own cursor 
> and other visualizations. Even in that case, you should still include 
> some amount of semantic data about the possible drop event.

I don't follow.


On Tue, 16 Nov 2010, Daniel Cheng wrote:
> 
> Automatic conversion is already implemented for some types (text, URL, 
> and maybe HTML). It's just not explicitly mentioned in the spec. I'm not 
> sure how a policy of no conversion would work; the clipboard 
> mechanism/encoding varies greatly from platform to platform. With no 
> automatic conversion, a page trying to read text from a drop would have 
> to first sniff the operating system, choose the appropriate strategy for 
> reading text, and then transcode the result to a DOMString.

The spec does sort of nod in this direction:

# If the drag initiated outside of the application, the user agent must 
# add items to the drag data store item list as appropriate for the data 
# being dragged, honoring platform conventions where appropriate [...]

...however, it's rather underdefined at the moment, lacking implementation 
experience. I expect we'll flesh this out in due course.


On Wed, 1 Dec 2010, Daniel Cheng wrote:
>
> Couple of things I noticed after the changes to the DnD spec:
> - event.dataTransfer.types no longer mentions "Text" or "URL". Is this
> intentional?

As far as I can tell it didn't mention them before either. Am I missing 
something? Why would it mention them?


> - Does the casing of "Text" and "URL" in the return value of
> event.dataTransfer.types matter?

It can't ever return those values, whatever the case, as far as I can 
tell.

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