[whatwg] Drag and drop feedback
On Fri, 17 Feb 2012, Anne van Kesteren wrote: * Firefox, Chrome and Opera only allow dragend to delete ranges during a 'move' if the range exists within an editable element. The spec needs to change to reflect this - currently it expects this anywhere within a non-editable document. Fixed. * Firefox, Chrome and Opera allow dropping in all text based inputs (text search tel url email password number) not just text. The spec allowed this -- the spec just said text field, it didn't say what it meant (it just had an example that said this included textarea and type=text). I've made this more explicit. It may have to change if UAs use text fields for other controls. * Firefox, Chrome and Opera all make .effectAllowed writeable only when the data store is in read/write mode, so that only the source node has the ability to set the effectAllowed. Done. (The way WebKit and Opera do it, not the way Firefox does it.) * Opera and Firefox have chosen to implement modifiers at the point of dropEffect initialization during dragenter and dragover: initially set dropEffect to the default value specified in the spec table, then if the platform requests something else with a modifier, set the dropEffect to that modified value. Therefore those events see the modified dropEffect (which seems to be the intention of the spec), and can also override it by writing to the dropEffect property. Browsers ignored effectAllowed in doing this, which seems like it would be a source of bugs. I've adopted the idea here, but honoured effectAllowed in the UA requirements here. * When dragging selections, Firefox, Chrome and Opera populate text/html with the minimal markup intersected by the selection (the smallest possible markup that contains all of the selection, without any parent elements that contain both ends of the selection). I haven't attempted to define this, since even a detailed explanation would still be incomplete unless we also defined all the whitelisting done for security reasons, and I don't intend to try to play that game. * Opera populates text/html when dragging an element. This means that it is possible to drag HTML into another application without needing JavaScript. I've allowed this, but in no detail. * Opera recognises dropzone on parent elements of the immediate user selection - the spec currently requires it to be the specific element, which means that child elements of the dropzone are not within the dropzone. This implementation is as simple as replacing this line in the specification: If the immediate user selection is an element with a dropzone attribute that matches the drag data store - Set the current target element to the immediate user selection anyway. With this line: If the immediate user selection is an element with a dropzone attribute that matches the drag data store, or if the immediate user selection has an ancestor element with a dropzone attribute that matches the drag data store - Set the current target element to the immediate user selection anyway. The proposed change wouldn't work (you'd end up sending the drop events to the wrong element, which matters e.g. if conflicting drop zones are nested). But I've done something similar, so that dropzone does work even when the element has descendants. * When there is no body, Opera uses the root node as the fallback target (when the immediate user selection does not cancel dragenter). If there is no root node, Opera uses null. This allows documents with no body to function correctly, where the spec reverts to using the document object. This means that when subsequently moving the drag over another non-cancelling element, it will once again fire dragenter at the document. And again when the mouse drags over another non-cancelling element, etc. etc. Our proposal is to replace this: If the current target element is the body element with this: If the current target element is the body element, or if there is no body element and the current target is the html element And then replace this: Otherwise; Fire a DND event named dragenter at the body element, if there is one, or at the Document object, if not. Then, and set the current target element to the body element, regardless of whether that event was canceled or not. with this: If the body element or html element exist; Fire a DND event named dragenter at the first of the following objects that exists, and set the current target element to that object regardless of whether that event was canceled or not: * The body element * The html element [interpreted as the root node in non-html documents] Otherwise; set the current target element to null (Note that it is possible for a document containing an immediate user selection to have neither a body element nor a root element, if the dragenter event handler for the immediate user selection deletes the root element.) I
Re: [whatwg] Drag-and-drop feedback
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.
Re: [whatwg] Drag-and-drop feedback
Ian,
I love the new dropzone attribute. Nice work. Here is one nit, and a
couple of questions
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?
Q1) 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'))?
I see the spec says:
The dropzone attribute must reflect the content attribute of the same name.
But I'm not certain that that means a property must exist if the
attribute does not.
Q2) 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? If not, then that
really diminishes the value of dropzone. I can't see how I'd write
dragenter and dragleave handlers to change the background color of the
element and also rely on the dropzone attribute, since it seems to be
processed after dragenter/leave are triggered...
One approach would be to define dropzone_activate and
dropzone_deactivate events to handle this case. A better solution might
be to define a :dropzone-active CSS pseudo class, if you can coordinate
that with the CSS folks...
David
Re: [whatwg] Drag-and-drop feedback
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
Re: [whatwg] Drag-and-drop feedback
Couple of things I noticed after the changes to the DnD spec: - event.dataTransfer.types no longer mentions Text or URL. Is this intentional? - Does the casing of Text and URL in the return value of event.dataTransfer.types matter? Daniel On Wed, Nov 17, 2010 at 13:05, Charles Pritchard ch...@jumis.com wrote: On 11/16/2010 4:05 PM, Daniel Cheng wrote: On Tue, Nov 16, 2010 at 14:48, Charles Pritchard ch...@jumis.com wrote: When interacting with non-DOM apps or pages, some platforms can't easily convert arbitrary MIME types to native data transfer types for copy/paste or DnD. For this reason, I think the spec should explicitly list MIME types for which UAs should handle the conversion to native data transfer types. A couple that come to mind: text/plain, text/uri-list, text/rtf, application/rtf, text/html, text/xml, image/png, and image/svg+xml. UAs can make a best-effort attempt to convert the other types, but it won't be guaranteed that they will be there for interaction with non-DOM applications. I'm not sure what this means exactly. Could you elaborate? I don't think these need to be converted by a UA -- the application which receives the data does that conversion on its own. This is a good use case for promise-based data callbacks. 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. Daniel Sorry, I completely misunderstood this one. I thought you were referring to operations from the browser to the desktop. The UA could handle conversion to image/png. It's low-hanging fruit. Conversion from complex formats into markup is something that should be handled by the non-DOM app, not the UA. Lacking decent markup conversion, a FileList is fine. I don't have to sniff the operating system, I just have to be determined on what mime types I'm going to support.
Re: [whatwg] Drag-and-drop feedback
On 12/1/2010 2:52 PM, 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? They're covered in implementation: http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#datatransfer If format equals text, change it to text/plain. If format equals url, change it to text/uri-list. Let format be the first argument, converted to ASCII lowercase - Does the casing of Text and URL in the return value of event.dataTransfer.types matter? It shouldn't, they are converted to lowercase. Daniel On Wed, Nov 17, 2010 at 13:05, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/16/2010 4:05 PM, Daniel Cheng wrote: On Tue, Nov 16, 2010 at 14:48, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: When interacting with non-DOM apps or pages, some platforms can't easily convert arbitrary MIME types to native data transfer types for copy/paste or DnD. For this reason, I think the spec should explicitly list MIME types for which UAs should handle the conversion to native data transfer types. A couple that come to mind: text/plain, text/uri-list, text/rtf, application/rtf, text/html, text/xml, image/png, and image/svg+xml. UAs can make a best-effort attempt to convert the other types, but it won't be guaranteed that they will be there for interaction with non-DOM applications. I'm not sure what this means exactly. Could you elaborate? I don't think these need to be converted by a UA -- the application which receives the data does that conversion on its own. This is a good use case for promise-based data callbacks. 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. Daniel Sorry, I completely misunderstood this one. I thought you were referring to operations from the browser to the desktop. The UA could handle conversion to image/png. It's low-hanging fruit. Conversion from complex formats into markup is something that should be handled by the non-DOM app, not the UA. Lacking decent markup conversion, a FileList is fine. I don't have to sniff the operating system, I just have to be determined on what mime types I'm going to support.
Re: [whatwg] Drag-and-drop feedback
On 11/16/2010 4:05 PM, Daniel Cheng wrote: On Tue, Nov 16, 2010 at 14:48, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: When interacting with non-DOM apps or pages, some platforms can't easily convert arbitrary MIME types to native data transfer types for copy/paste or DnD. For this reason, I think the spec should explicitly list MIME types for which UAs should handle the conversion to native data transfer types. A couple that come to mind: text/plain, text/uri-list, text/rtf, application/rtf, text/html, text/xml, image/png, and image/svg+xml. UAs can make a best-effort attempt to convert the other types, but it won't be guaranteed that they will be there for interaction with non-DOM applications. I'm not sure what this means exactly. Could you elaborate? I don't think these need to be converted by a UA -- the application which receives the data does that conversion on its own. This is a good use case for promise-based data callbacks. 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. Daniel Sorry, I completely misunderstood this one. I thought you were referring to operations from the browser to the desktop. The UA could handle conversion to image/png. It's low-hanging fruit. Conversion from complex formats into markup is something that should be handled by the non-DOM app, not the UA. Lacking decent markup conversion, a FileList is fine. I don't have to sniff the operating system, I just have to be determined on what mime types I'm going to support.
Re: [whatwg] Drag-and-drop feedback
On 11/1/2010 6:03 PM, Ian Hickson wrote:
On Mon, 22 Feb 2010, Ian Hickson wrote:
On Thu, 4 Feb 2010, Ian Hickson wrote:
On Sat, 23 Jan 2010, Eduard Pascual wrote:
Would it be possible to provide a list of drag items (to call them
somehow) instead of, or in addition to, the current info provided by
the DataTransfer object?
That's a pretty good idea. I think we should probably do this when we
add more types to the DataTransfer object.
Some engineers at Google discussed this a bit and came up with the
following proposal:
dataTransfer.items = DataTransferItems
DataTransferItems.length
.getItem(n) = DataTransferItem
.add(stringData, type)
.add(blobData)
.add(fileData)
.add(dataTransferItem)
.clear()
DataTransferItem.kind = 'string', 'file', 'blob', ...
.type = MIME type
.binary = boolean
.getTextData(function callback (data)) - throws if binary
is true
.getBlob() - returns File or Blob
When we add promises later, this can easily be extended to support that
as well (basically, just by adding a new add() method for the promise
case).
I've added a simple version of this (no Blob support, and no way to add a
dataTransferItem, but otherwise more or less the same).
How close are we to adding promises?
.add(fileEntry,callOnTransfer);
This would allow the script to write to the contents of a file entry
upon request, instead of doing it ahead of time.
callOnTransfer = function( dataTransferPromiseEvent ) {
var dest = dataTransferPromiseEvent.fileEntry;
/// file writer API
dataTransferPromiseEvent.flush();
)
}
The fileEntry would be written ahead of time, either as a blank file,
or it'd be an already existing file.
DataTransfer.addFile(fileData);
It's now DataTransfer.items.add(fileData);
When interacting with non-DOM apps or pages, some platforms can't easily
convert arbitrary MIME types to native data transfer types for
copy/paste or DnD. For this reason, I think the spec should explicitly
list MIME types for which UAs should handle the conversion to native
data transfer types. A couple that come to mind: text/plain,
text/uri-list, text/rtf, application/rtf, text/html, text/xml,
image/png, and image/svg+xml. UAs can make a best-effort attempt to
convert the other types, but it won't be guaranteed that they will be
there for interaction with non-DOM applications.
I'm not sure what this means exactly. Could you elaborate?
I don't think these need to be converted by a UA -- the application which
receives the data does that conversion on its own.
This list of transfer types reminds me of all the redundancy that can
take place in a data transfer.
A sufficiently large XML content file may be transferred in ~4 different
file formats
for compatibility with the destination.
This is a good use case for promise-based data callbacks.
On Mon, 28 Jun 2010, Daniel Cheng wrote:
It's pretty common for there to be non-text data in a drag-and-drop
operation or copy-and-paste operation. DataTransfer doesn't allow for that
currently, since it only sets and returns DOMStrings.
It'd be nice if we could extend setData/getData to allow for Blobs. Some
random thoughts:
1. Add a bool parameter to setData/getData. If false, treat the data as a
DOMString; if true, treat the data as a Blob.
2. Add an encoding parameter to setData/getData. Encoding can be a string
value naming a text encoding like UTF-8 or ISO-8859-1, or it can be the
string value binary. If encoding names a text encoding, the UA will
transcode the requested data into/from a DOMString. Otherwise, if the
encoding value is binary, the UA will treat data as a Blob.
3. Create new DataTransfer functions instead of overloading them, e.g.
setDataBlob, getDataBlob.
I'm not sure which one is the preferred approach. It seems like it'd be nice
to have native support for whatever text encodings the browser understands,
but it seems complicated and I'm not sure it's necessary. Thoughts?
The new DataTransferItems feature could let you do this using
dataTransfer.items.add(blob), if we added that. Right now you can add just
text strings and File objects. We could also one day support arbitrary JS
objects (with the structured clone stuff) the same way, too.
Also, if I wanted to go ahead and implement a prototype in WebKit, should I
prefix it with a UA-specific string, e.g. webkitSetDataBlob?
Yes.
This relates to my comments later in this e-mail -- About allowing
.add(fileEntry,callback)
as a means for a promise-based download.
* 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
Re: [whatwg] Drag-and-drop feedback
On Tue, Nov 16, 2010 at 14:48, Charles Pritchard ch...@jumis.com wrote: When interacting with non-DOM apps or pages, some platforms can't easily convert arbitrary MIME types to native data transfer types for copy/paste or DnD. For this reason, I think the spec should explicitly list MIME types for which UAs should handle the conversion to native data transfer types. A couple that come to mind: text/plain, text/uri-list, text/rtf, application/rtf, text/html, text/xml, image/png, and image/svg+xml. UAs can make a best-effort attempt to convert the other types, but it won't be guaranteed that they will be there for interaction with non-DOM applications. I'm not sure what this means exactly. Could you elaborate? I don't think these need to be converted by a UA -- the application which receives the data does that conversion on its own. This list of transfer types reminds me of all the redundancy that can take place in a data transfer. A sufficiently large XML content file may be transferred in ~4 different file formats for compatibility with the destination. This is a good use case for promise-based data callbacks. 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. Daniel
Re: [whatwg] Drag-and-drop feedback
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 useinput 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.
Currently, this seems to be implemented by the OS:
Vista downloads a URL to the temporary files directory, then passes it
to the browser.
No cookies, or other credentials are sent with the fetch, as it is an
OS-level fetch.
Entering a remote URL does not seem to function in OS X as there is no
place on the file upload screen to enter a URL.
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.
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.
On a side note -- I've been having a lot of issue with building blobs:
Are there currently semantics in place to distinguish a DOMString from
binary data?
At present, I can only think of Typed Arrays from the WebGL-related specs.
Currently, when I try to build a Blob using binary data, I end up with a
UTF-8 escaped DOM String.
I'm still forced to run an XHR request, to grab binary data for an image
(one already loaded by the browser),
so that I can store that image data in local storage. I then use a
js-based base64 encoder, as browser encoders are expecting
a DOMString and throw errors on binary (per specs).
This would be solved in part, via FileSystem/File APIs, but they're also
expecting DOMString.
I expect it's meant to be solved by adding Blob support directly to XHR.
Re: [whatwg] Drag-and-drop feedback
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) Daniel
[whatwg] Drag-and-drop feedback
On Mon, 22 Feb 2010, Ian Hickson wrote: On Thu, 4 Feb 2010, Ian Hickson wrote: On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. Some engineers at Google discussed this a bit and came up with the following proposal: dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(n) = DataTransferItem .add(stringData, type) .add(blobData) .add(fileData) .add(dataTransferItem) .clear() DataTransferItem.kind = 'string', 'file', 'blob', ... .type = MIME type .binary = boolean .getTextData(function callback (data)) - throws if binary is true .getBlob() - returns File or Blob When we add promises later, this can easily be extended to support that as well (basically, just by adding a new add() method for the promise case). I've added a simple version of this (no Blob support, and no way to add a dataTransferItem, but otherwise more or less the same). On Mon, 22 Feb 2010, Daniel Cheng wrote: How does DataTransferItems interact with the original DataTransfer object? I'm assuming changes in one should be reflected in the other. Yes. If that's the case, what should happen if I do this: dataTransfer.items.add(fileData); dataTransfer.getData(mimeTypeForFile); getData() doesn't expose the items with files, only those that are text. (It can't expose the files since those are asynchronous binary Blobs, not synchronous Unicode strings). How come there's no DataTransferItems.get(type) method? It would probably have to be get(type, kind) and would have to be able to return a list, at which point you might as well just iterate over the actual .items list and check the type and kind for each one directly. It seems that a get() here wouldn't really save much. If you have any use cases you could show, I'd be happy to see what the code would look like though to see if it would save much. If it does, certainly it would make sense to add something like that. DataTransferItem provides richer metadata than is available through the native drag-and-drop interface on most platforms. When dragging data from a non-DOM application, how do you extrapolate the metadata to fill in the type/binary fields? I don't follow. Could you give an example of what you mean? On Fri, 26 Feb 2010, Dmitry Titov wrote: I understand 'binary' as indicator of whether or not the item can be read as a text string. I'm not sure why item.kind == string is not the same. If the intent is to also cover some files that can be read as string and as Blob, then it might be buggy because the only way to establish if the file can be converted into JS string is to actually read the bytes and try to convert to Unicode. There can be invalid character sequences or the encoding info may be missing. Perhaps we should remove 'binary' and assume that items that item.kind == string can use getTextData(callback) to pull the string. Yeah, I ended up going that way. On a separate note, I think items.add(dataTransferItem) is not useful w/o a way to create a new DataTransferItem separately from the DataTransferItems list. Agreed. I ended up not adding it. 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? [in the context of supporting native data dragged to the web] Should there be some sort of standard list of mappings that all UAs should support wherever possible? What happens if the UA doesn't have a mapping for a type? I'm happy to add a mapping list if someone can provide one for common platforms. I don't currently have one. The spec just says that the UA should do a best effort attempt. On Mon, 29 Mar 2010, Daniel Cheng proposed: DataTransfer mirrors DataTransferItems, but DataTransfer.getData() will throw an error if the data is a blob. Currently the types of files and of string data are different namespaces, you can have a text/plain file and a text/plain string. Should I disallow this? Is it not possible to end up in such a situation in native DND UIs? Maybe a second getData method that can provide conversion given a text encoding would be useful? the File/Blob API should support
Re: [whatwg] Drag-and-drop feedback
On Fri, 5 Feb 2010, Roland Steiner wrote: Since I am currently in the process of fixing bugs in this area for Chrome, there are 2 things I'm wondering about: .) whether Text and URL should be part of the return value of types (probably not, according to Ian's comment). However, since text/uri-list may in fact not contain a valid URL, the presence/absence of URL in types could be useful. I.e., it could indicate whether getData(URL) will return something useful. For now .types shouldn't ever have Text and URL, since they get converted to MIME types. In practice, it's unlikely that a text/uri-list option will have no URLs. I agree that this was a bad design choice, though. .) Judging from the example in https://developer.mozilla.org/En/DragDrop/Drag_Operations#drop , Firefox seems to use only LF for line feeds within text/uri-list, while RFC 2483 calls for CR-LF for all text/* formats, including text/uri-list, as does the HTML5 spec in the section on the drag-and-drop processing model. Since the UA has to parse text/uri-list for the return value of URL, I wonder whether both should be accepted (break on LF, filter out any CR). I recommend just following whatever the text/uri-list spec says. .) should dragged files be converted to file URLs and returned in a call to getData(text/uri-list) or getData(URL)? Exposing file: URLs seems like a bad idea, since that exposes privacy- sensitive information like the file path... I would recommend not doing this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
I like the DataTransferItems proposal. I had a few questions, but no one answered, so I'm going to propose some modifications: DataTransferItems is a mapping of types to data like DataTransfer. DataTransfer mirrors DataTransferItems, but DataTransfer.getData() will throw an error if the data is a blob. Maybe a second getData method that can provide conversion given a text encoding would be useful? DataTransfer changes: DataTransfer.addFile(fileData); dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(type) = DataTransferItem .add(stringData, type) .add(blobData) .add(dataTransferItem) .clear() DataTransferItem.kind = 'string', 'blob' .type = MIME type .getTextData(function callback (data)) - throws if binary is true .getBlob() - returns Blob The binary property has been folded into the kind property. When interacting with non-DOM apps or pages, some platforms can't easily convert arbitrary MIME types to native data transfer types for copy/paste or DnD. For this reason, I think the spec should explicitly list MIME types for which UAs should handle the conversion to native data transfer types. A couple that come to mind: text/plain, text/uri-list, text/rtf, application/rtf, text/html, text/xml, image/png, and image/svg+xml. UAs can make a best-effort attempt to convert the other types, but it won't be guaranteed that they will be there for interaction with non-DOM applications. Daniel On Tue, Mar 9, 2010 at 3:03 PM, Daniel Cheng dch...@google.com wrote: On Fri, Feb 26, 2010 at 10:56 AM, Dmitry Titov dim...@google.com wrote: On Mon, Feb 22, 2010 at 6:06 PM, Daniel Cheng dch...@google.com wrote: Several questions about the proposal: How does DataTransferItems interact with the original DataTransfer object? I'm assuming changes in one should be reflected in the other. If that's the case, what should happen if I do this: dataTransfer.items.add(fileData); dataTransfer.getData(mimeTypeForFile); Unless there is a specific reason to think different, there is only one set of items backing DataTransfer object - today the files and 'other items' are represented separtely, the proposed items list is simply a merged version of the same. In your example you should be able to getData. Does that mean getData() can return types besides DOMString? How come there's no DataTransferItems.get(type) method? There can be multiple items of that type (dragging several image files). Would it return another items list? What is the use case for this? Also, some items may have empty type (a file with unknown extension). 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. DataTransferItem provides richer metadata than is available through the native drag-and-drop interface on most platforms. When dragging data from a non-DOM application, how do you extrapolate the metadata to fill in the type/binary fields? 'type' can be inferred in many cases from file extension, native clipboard format or other means. It can be done w/o content sniffing and disk IO. Should there be some sort of standard list of mappings that all UAs should support wherever possible? What happens if the UA doesn't have a mapping for a type? I understand 'binary' as indicator of whether or not the item can be read as a text string. I'm not sure why item.kind == string is not the same. If the intent is to also cover some files that can be read as string and as Blob, then it might be buggy because the only way to establish if the file can be converted into JS string is to actually read the bytes and try to convert to Unicode. There can be invalid character sequences or the encoding info may be missing. Perhaps we should remove 'binary' and assume that items that item.kind == string can use getTextData(callback) to pull the string. On a separate note, I think items.add(dataTransferItem) is not useful w/o a way to create a new DataTransferItem separately from the DataTransferItems list. Daniel On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 4 Feb 2010, Ian Hickson wrote: On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. Some engineers at Google discussed this a bit and came up with the following proposal: dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(n) = DataTransferItem .add(stringData, type) .add(blobData)
Re: [whatwg] Drag-and-drop feedback
On Fri, Feb 26, 2010 at 10:56 AM, Dmitry Titov dim...@google.com wrote: On Mon, Feb 22, 2010 at 6:06 PM, Daniel Cheng dch...@google.com wrote: Several questions about the proposal: How does DataTransferItems interact with the original DataTransfer object? I'm assuming changes in one should be reflected in the other. If that's the case, what should happen if I do this: dataTransfer.items.add(fileData); dataTransfer.getData(mimeTypeForFile); Unless there is a specific reason to think different, there is only one set of items backing DataTransfer object - today the files and 'other items' are represented separtely, the proposed items list is simply a merged version of the same. In your example you should be able to getData. Does that mean getData() can return types besides DOMString? How come there's no DataTransferItems.get(type) method? There can be multiple items of that type (dragging several image files). Would it return another items list? What is the use case for this? Also, some items may have empty type (a file with unknown extension). 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. DataTransferItem provides richer metadata than is available through the native drag-and-drop interface on most platforms. When dragging data from a non-DOM application, how do you extrapolate the metadata to fill in the type/binary fields? 'type' can be inferred in many cases from file extension, native clipboard format or other means. It can be done w/o content sniffing and disk IO. Should there be some sort of standard list of mappings that all UAs should support wherever possible? What happens if the UA doesn't have a mapping for a type? I understand 'binary' as indicator of whether or not the item can be read as a text string. I'm not sure why item.kind == string is not the same. If the intent is to also cover some files that can be read as string and as Blob, then it might be buggy because the only way to establish if the file can be converted into JS string is to actually read the bytes and try to convert to Unicode. There can be invalid character sequences or the encoding info may be missing. Perhaps we should remove 'binary' and assume that items that item.kind == string can use getTextData(callback) to pull the string. On a separate note, I think items.add(dataTransferItem) is not useful w/o a way to create a new DataTransferItem separately from the DataTransferItems list. Daniel On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 4 Feb 2010, Ian Hickson wrote: On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. Some engineers at Google discussed this a bit and came up with the following proposal: dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(n) = DataTransferItem .add(stringData, type) .add(blobData) .add(fileData) .add(dataTransferItem) .clear() DataTransferItem.kind = 'string', 'file', 'blob', ... .type = MIME type .binary = boolean .getTextData(function callback (data)) - throws if binary is true .getBlob() - returns File or Blob When we add promises later, this can easily be extended to support that as well (basically, just by adding a new add() method for the promise case). I've put this into the comment in the spec, but haven't specced it. If any browser vendors want to try implementing this or something like it, any reports of implementation experience would be very useful. Please prefix the items attribute with some unique string like webkitItems or geckoItems so that it doesn't clash with the spec when we do add something like this! Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Mon, Feb 22, 2010 at 6:06 PM, Daniel Cheng dch...@google.com wrote: Several questions about the proposal: How does DataTransferItems interact with the original DataTransfer object? I'm assuming changes in one should be reflected in the other. If that's the case, what should happen if I do this: dataTransfer.items.add(fileData); dataTransfer.getData(mimeTypeForFile); Unless there is a specific reason to think different, there is only one set of items backing DataTransfer object - today the files and 'other items' are represented separtely, the proposed items list is simply a merged version of the same. In your example you should be able to getData. How come there's no DataTransferItems.get(type) method? There can be multiple items of that type (dragging several image files). Would it return another items list? What is the use case for this? Also, some items may have empty type (a file with unknown extension). DataTransferItem provides richer metadata than is available through the native drag-and-drop interface on most platforms. When dragging data from a non-DOM application, how do you extrapolate the metadata to fill in the type/binary fields? 'type' can be inferred in many cases from file extension, native clipboard format or other means. It can be done w/o content sniffing and disk IO. I understand 'binary' as indicator of whether or not the item can be read as a text string. I'm not sure why item.kind == string is not the same. If the intent is to also cover some files that can be read as string and as Blob, then it might be buggy because the only way to establish if the file can be converted into JS string is to actually read the bytes and try to convert to Unicode. There can be invalid character sequences or the encoding info may be missing. Perhaps we should remove 'binary' and assume that items that item.kind == string can use getTextData(callback) to pull the string. On a separate note, I think items.add(dataTransferItem) is not useful w/o a way to create a new DataTransferItem separately from the DataTransferItems list. Daniel On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 4 Feb 2010, Ian Hickson wrote: On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. Some engineers at Google discussed this a bit and came up with the following proposal: dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(n) = DataTransferItem .add(stringData, type) .add(blobData) .add(fileData) .add(dataTransferItem) .clear() DataTransferItem.kind = 'string', 'file', 'blob', ... .type = MIME type .binary = boolean .getTextData(function callback (data)) - throws if binary is true .getBlob() - returns File or Blob When we add promises later, this can easily be extended to support that as well (basically, just by adding a new add() method for the promise case). I've put this into the comment in the spec, but haven't specced it. If any browser vendors want to try implementing this or something like it, any reports of implementation experience would be very useful. Please prefix the items attribute with some unique string like webkitItems or geckoItems so that it doesn't clash with the spec when we do add something like this! Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Thu, 4 Feb 2010, Ian Hickson wrote: On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. Some engineers at Google discussed this a bit and came up with the following proposal: dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(n) = DataTransferItem .add(stringData, type) .add(blobData) .add(fileData) .add(dataTransferItem) .clear() DataTransferItem.kind = 'string', 'file', 'blob', ... .type = MIME type .binary = boolean .getTextData(function callback (data)) - throws if binary is true .getBlob() - returns File or Blob When we add promises later, this can easily be extended to support that as well (basically, just by adding a new add() method for the promise case). I've put this into the comment in the spec, but haven't specced it. If any browser vendors want to try implementing this or something like it, any reports of implementation experience would be very useful. Please prefix the items attribute with some unique string like webkitItems or geckoItems so that it doesn't clash with the spec when we do add something like this! Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
Several questions about the proposal: How does DataTransferItems interact with the original DataTransfer object? I'm assuming changes in one should be reflected in the other. If that's the case, what should happen if I do this: dataTransfer.items.add(fileData); dataTransfer.getData(mimeTypeForFile); How come there's no DataTransferItems.get(type) method? DataTransferItem provides richer metadata than is available through the native drag-and-drop interface on most platforms. When dragging data from a non-DOM application, how do you extrapolate the metadata to fill in the type/binary fields? Daniel On Mon, Feb 22, 2010 at 3:51 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 4 Feb 2010, Ian Hickson wrote: On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. Some engineers at Google discussed this a bit and came up with the following proposal: dataTransfer.items = DataTransferItems DataTransferItems.length .getItem(n) = DataTransferItem .add(stringData, type) .add(blobData) .add(fileData) .add(dataTransferItem) .clear() DataTransferItem.kind = 'string', 'file', 'blob', ... .type = MIME type .binary = boolean .getTextData(function callback (data)) - throws if binary is true .getBlob() - returns File or Blob When we add promises later, this can easily be extended to support that as well (basically, just by adding a new add() method for the promise case). I've put this into the comment in the spec, but haven't specced it. If any browser vendors want to try implementing this or something like it, any reports of implementation experience would be very useful. Please prefix the items attribute with some unique string like webkitItems or geckoItems so that it doesn't clash with the spec when we do add something like this! Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
Quick correction/addendum: FireFox seems to be actually fine with CRLF as line separator in setData(text/uri-list, data) and will return only the first URL within data on getData(URL). However, it doesn't seem to return files as URLs with getData(text/uri-list), which I guess would be my third question: .) should dragged files be converted to file URLs and returned in a call to getData(text/uri-list) or getData(URL)? - Roland On Fri, Feb 5, 2010 at 4:34 PM, Roland Steiner rolandstei...@google.comwrote: Since I am currently in the process of fixing bugs in this area for Chrome, there are 2 things I'm wondering about: .) whether Text and URL should be part of the return value of types (probably not, according to Ian's comment). However, since text/uri-list may in fact not contain a valid URL, the presence/absence of URL in types could be useful. I.e., it could indicate whether getData(URL) will return something useful. .) Judging from the example in https://developer.mozilla.org/En/DragDrop/Drag_Operations#drop , Firefox seems to use only LF for line feeds within text/uri-list, while RFC 2483 calls for CR-LF for all text/* formats, including text/uri-list, as does the HTML5 spec in the section on the drag-and-drop processing model. Since the UA has to parse text/uri-list for the return value of URL, I wonder whether both should be accepted (break on LF, filter out any CR). The other problem here is that WebKit/Safari and Chromium convert files to file URLs to return for text/uri-list/URL. Is there a consensus how this difference should be best handled (or is this just a bug in FF)? Cheers, Roland On Thu, Feb 4, 2010 at 11:29 AM, Ian Hickson i...@hixie.ch wrote: Webkit and Firefox are case-sensitive. IE only does TEXT and URL, but case-insensitively (at least for Text, I didn't test URL). Chrome is case-insensitive for everything. Tough call. I guess we'll go with just converting everything to lowercase, so that it's case-insensitive. BTW I noticed Chrome includes Text and URL in the .types list. That's incorrect according to the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
Webkit and Firefox are case-sensitive. IE only does TEXT and URL, but case-insensitively (at least for Text, I didn't test URL). Chrome is case-insensitive for everything. Tough call. I guess we'll go with just converting everything to lowercase, so that it's case-insensitive. BTW I noticed Chrome includes Text and URL in the .types list. That's incorrect according to the spec. If event.dataTransfer converts everything to lowercase, that means there are native formats that will always be impossible to access. Since text and url are already special, maybe case should only be ignored for those two. All other formats, even if they are actually MIME type strings, should be handled in a case-sensitive manner. Daniel
Re: [whatwg] Drag-and-drop feedback
On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 4 Feb 2010, Daniel Cheng wrote: Webkit and Firefox are case-sensitive. IE only does TEXT and URL, but case-insensitively (at least for Text, I didn't test URL). Chrome is case-insensitive for everything. Tough call. I guess we'll go with just converting everything to lowercase, so that it's case-insensitive. BTW I noticed Chrome includes Text and URL in the .types list. That's incorrect according to the spec. If event.dataTransfer converts everything to lowercase, that means there are native formats that will always be impossible to access. The spec requires that the UA lowercase all the native types as well (and that they be converted to MIME types). Could you elaborate on which types would be a problem, and on what platforms? Forcing UA to lowercase all formats has a high implementation cost. Most DataTransfer implementations now can directly interact with the native system data object, whatever form that takes. With this change, the UA has to enumerate (with possible string conversions involved, depending on the platform) and lower case all formats currently in the drag and drop/clipboard operation with every call to getData()/setData()/clearData(). Furthermore, what happens if there are collisions after lowercasing? Also, suppose some Windows app XYZ uses the data format My Awesome Clipboard Format. If a page wants to set drag and drop (or clipboard data; presumably, the interfaces to transfer data are going to remain somewhat similar), it will be unable to set data in the correct format unless the UA happens to internally map a MIME type to that data format. Some common MIME types should definitely be mapped to native data formats, but the interface shouldn't prevent someone from interfacing with any arbitrary app they want. Since text and url are already special, maybe case should only be ignored for those two. All other formats, even if they are actually MIME type strings, should be handled in a case-sensitive manner. In your previous e-mail, you were arguing they should be case-insensitive... I think your earlier arguments are more persuasive. The MIME type specs do say they're case-insensitive. True, but I think the problems with making all strings lowercase outweigh the benefits. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Thu, 4 Feb 2010, Daniel Cheng wrote: On Thu, Feb 4, 2010 at 5:28 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 4 Feb 2010, Daniel Cheng wrote: Webkit and Firefox are case-sensitive. IE only does TEXT and URL, but case-insensitively (at least for Text, I didn't test URL). Chrome is case-insensitive for everything. Tough call. I guess we'll go with just converting everything to lowercase, so that it's case-insensitive. BTW I noticed Chrome includes Text and URL in the .types list. That's incorrect according to the spec. If event.dataTransfer converts everything to lowercase, that means there are native formats that will always be impossible to access. The spec requires that the UA lowercase all the native types as well (and that they be converted to MIME types). Could you elaborate on which types would be a problem, and on what platforms? Forcing UA to lowercase all formats has a high implementation cost. It's not _that_ high. It's just a few strings, and it's easily cachable. Most DataTransfer implementations now can directly interact with the native system data object, whatever form that takes. With this change, the UA has to enumerate (with possible string conversions involved, depending on the platform) and lower case all formats currently in the drag and drop/clipboard operation with every call to getData()/setData()/clearData(). Furthermore, what happens if there are collisions after lowercasing? The spec requires that the UA convert the formats to MIME types, so the UA is responsible for preventing collisions. Also, suppose some Windows app XYZ uses the data format My Awesome Clipboard Format. If a page wants to set drag and drop (or clipboard data; presumably, the interfaces to transfer data are going to remain somewhat similar), it will be unable to set data in the correct format unless the UA happens to internally map a MIME type to that data format. Yes. Some common MIME types should definitely be mapped to native data formats, but the interface shouldn't prevent someone from interfacing with any arbitrary app they want. I'm open to changing this again, but if it is to change again I want to make sure we never change it after that, so we need to be very sure about what the spec should say here. Exactly what conversions should happen? When? If you could work with other browser vendors to come up with the exact rules for dataTransfer that everyone agrees makes sense on every platform, that would be ideal. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
Since I am currently in the process of fixing bugs in this area for Chrome, there are 2 things I'm wondering about: .) whether Text and URL should be part of the return value of types (probably not, according to Ian's comment). However, since text/uri-list may in fact not contain a valid URL, the presence/absence of URL in types could be useful. I.e., it could indicate whether getData(URL) will return something useful. .) Judging from the example in https://developer.mozilla.org/En/DragDrop/Drag_Operations#drop , Firefox seems to use only LF for line feeds within text/uri-list, while RFC 2483 calls for CR-LF for all text/* formats, including text/uri-list, as does the HTML5 spec in the section on the drag-and-drop processing model. Since the UA has to parse text/uri-list for the return value of URL, I wonder whether both should be accepted (break on LF, filter out any CR). The other problem here is that WebKit/Safari and Chromium convert files to file URLs to return for text/uri-list/URL. Is there a consensus how this difference should be best handled (or is this just a bug in FF)? Cheers, Roland On Thu, Feb 4, 2010 at 11:29 AM, Ian Hickson i...@hixie.ch wrote: Webkit and Firefox are case-sensitive. IE only does TEXT and URL, but case-insensitively (at least for Text, I didn't test URL). Chrome is case-insensitive for everything. Tough call. I guess we'll go with just converting everything to lowercase, so that it's case-insensitive. BTW I noticed Chrome includes Text and URL in the .types list. That's incorrect according to the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Sat, 23 Jan 2010, Eduard Pascual wrote: Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? That's a pretty good idea. I think we should probably do this when we add more types to the DataTransfer object. On Sat, 23 Jan 2010, Maciej Stachowiak wrote: The HTML5 drag-and-drop model (or rather, the IE drag-and-drop model that it is based on) doesn't really work for this case anyway, regardless of the copy/paste issue, since there doesn't seem to be any sane way to distinguish between an in-page drag and a drag to an external application such as a clipboard. If you can drag to a clipboard, I don't see why we would _disallow_ the copy/paste interaction. That sounds like a design flaw with the drag and drop model. One of many. Sounds like something to fix not something to compound with another design flaw. Fair enough. I've removed the copy/paste mode of drag-and-drop. I'll deal with the copy/cut/paste events separately. On Mon, 25 Jan 2010, Jian Li wrote: DownloadURL. The data associated with the DownloadURL format should be parsed similar to the URL format. When the drag ends in another application, the remote file described in the associated data URL should be downloaded and provided to the target application. How would this be exposed to other apps? Is it possible in Windows to drop something and then have the application that received the drop wait for a download (which could take hours) to complete? How does that work? On Windows, [...] we use the file stream to transfer the data between the source application and the target application and thus the target application will not be blocked if it uses a background thread (this is what Windows Shell does). On MacOSX, a file stream is also used for such purpose. However, we need to provide more metadata about the download when we call DataTransfer.setData(DownloadURL, ...). This is because on Windows we need to know about the file name and size when the drag is initiated. We can wait till we get the headers to extract the file name and size but this is blocking. Even more, if the http chunk mode is used, we cannot get the size from the headers. So how would you provide the file size? On MacOSX, we need to provide the mime type and file name. Could we consider adding mime type, file name and size information into the data value parameter of setData method? For example, dataTransfer.setData(DownloadURL, text/plain:1000:http://example.com/download.txt;); I think we should just have a promise mechanism rather than one hard-coded for URLs. But I think it's probably best for us to wait until we have the current spec implemented reliably and sanely before adding something like that. We don't even have a good test suite for the drag-and-drop API yet. On Mon, 25 Jan 2010, Michael Davidson wrote: The issue that I'm having is that if the DataTransfer object says that it has Files, I have no way to determine what type those files are. (In this case, I only want to accept image files.) I understand that the DataTransfer shouldn't have the content of the files for security reasons, but it would be helpful if it did contain the file names and/or MIME types. I could provide a second attribute with the types of the files, would that work? I suppose if we did this, we should remove the Files fake type. That might not be a bad idea in general, it's kind of a hack. I'm not sure how I feel about having multiple different ways of representing the data in a DataTransfer object... It would give a clean precedent for adding other features, though, like promises, which some people have requested. Multiple different ways to get the same info doesn't seem great, but it doesn't matter to me as long as the information is available. Another option is to throw an error if developers try to access forbidden attributes during dragenter/dragover. I haven't added this for now, because Firefox 3.6 already shipped with Files and I think it'd be better to get the API stablised on what's already specified before adding more (and since it's shipped, I'd rather not remove the existing features). However, what I think we should do in the next version (in a few months, maybe) is have a new way of exposing the data, as Eduard suggested, which has one item per thing in the data, and which in all but the dragstart and drop events only exposes the type information. I've noted this in a comment in the spec. On Sat, 23 Jan 2010, Daniel Cheng wrote: Formats are generally given by MIME types, with some values special-cased for legacy reasons. For the purposes of this API, however, the format strings are opaque, case-sensitive, strings, and the empty string is a valid format string. RFC 2616
Re: [whatwg] Drag-and-drop feedback
On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Aug 2009, Jian Li wrote:
In order to download the attachment from an Internet mail application,
the user will have to click the attachment link and a save dialog will
pop up to let the user select the destination folder. This will normally
involves multiple clicks. Native application, like Outlook, can let the
user drag attachments directly into the destination place, i.e. desktop,
which is really convenient.
We propose adding a specific format string to the DataTransfer object:
DownloadURL. The data associated with the DownloadURL format should
be parsed similar to the URL format. When the drag ends in another
application, the remote file described in the associated data URL should
be downloaded and provided to the target application.
How would this be exposed to other apps? Is it possible in Windows to drop
something and then have the application that received the drop wait for a
download (which could take hours) to complete? How does that work?
If we can rely on the download happening before the drag, then we could
add something to the DataTransfer object to add File objects.
We cannot do the download before the drag because the drop target might not
accept the drag or the user might press ESC to cancel the drag-and-drop. We
do not want to do any unnecessary download before we know for sure that the
user really wants it.
It could be possible that the target application could be blocked for long
time if we do not provide the drag-and-drop information in a nice way. On
Windows, we could provide a download file in two ways: file path or file
stream. For the former way, a file has to be downloaded first before the
target application can consume it and thus the target application will be
blocked until the download completes. For the latter way, we use the file
stream to transfer the data between the source application and the target
application and thus the target application will not be blocked if it uses a
background thread (this is what Windows Shell does). On MacOSX, a file
stream is also used for such purpose.
However, we need to provide more metadata about the download when we call
DataTransfer.setData(DownloadURL, ...). This is because on Windows we need
to know about the file name and size when the drag is initiated. We can wait
till we get the headers to extract the file name and size but this is
blocking. Even more, if the http chunk mode is used, we cannot get the size
from the headers. On MacOSX, we need to provide the mime type and file name.
Could we consider adding mime type, file name and size information into the
data value parameter of setData method? For example,
dataTransfer.setData(DownloadURL, text/plain:1000:
http://example.com/download.txt;);
On Fri, 4 Sep 2009, Jens Alfke wrote:
On Sep 3, 2009, at 6:05 PM, Francisco Tolmasky wrote:
However, I think the addition of the deferred setData methods could be
added today in a way that is completely backwards compatible with
current implementations and would still be of great benefit.
Specifically, my request for deferring the calling of toString on
non-string objects as such:
event.dataTransfer.setData(something, { toString: function() {
return expensiveFunctionCall(); } });
This would allow me to submit patches to Firefox and WebKit that would
solve the current performance issues which are literally blocking my
ability to switch from fake drag and drop to native drag and drop.
At the same time, this should still work today in all browsers that
implement setData because the object is coerced into a string
immediately for you, thus not requiring immediate action on their part
to change anything.
+1. A real drag-n-drop API has to support promised data.
I agree with this in principle, but I think we should wait for DND to be
properly implemented in current browsers before adding this.
On Tue, 12 Jan 2010, Michael Davidson wrote:
The table in section 7.9.3 says that the DataTransfer object should be
empty for dragenter and dragover events.
Clearly this is not the case - the example in 7.9.1 shows that, at the
very least, the DataTransfer object needs to have a 'types' attribute so
that the drag handler can determine if it can accept the drag.
I've tried to clarify what empty is supposed to mean here.
The issue that I'm having is that if the DataTransfer object says that
it has Files, I have no way to determine what type those files are. (In
this case, I only want to accept image files.) I understand that the
DataTransfer shouldn't have the content of the files for security
reasons, but it would be helpful if it did contain the file names and/or
MIME types.
I could provide a second attribute with the types of the files, would that
work? I suppose if we did this, we should remove the Files fake type.
That might not be a bad idea
Re: [whatwg] Drag-and-drop feedback
On Sat, Jan 23, 2010 at 2:30 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 12 Jan 2010, Michael Davidson wrote: The table in section 7.9.3 says that the DataTransfer object should be empty for dragenter and dragover events. Clearly this is not the case - the example in 7.9.1 shows that, at the very least, the DataTransfer object needs to have a 'types' attribute so that the drag handler can determine if it can accept the drag. I've tried to clarify what empty is supposed to mean here. Thanks, that makes sense for the status quo. The issue that I'm having is that if the DataTransfer object says that it has Files, I have no way to determine what type those files are. (In this case, I only want to accept image files.) I understand that the DataTransfer shouldn't have the content of the files for security reasons, but it would be helpful if it did contain the file names and/or MIME types. I could provide a second attribute with the types of the files, would that work? I suppose if we did this, we should remove the Files fake type. That might not be a bad idea in general, it's kind of a hack. I'm not sure how I feel about having multiple different ways of representing the data in a DataTransfer object... It would give a clean precedent for adding other features, though, like promises, which some people have requested. Multiple different ways to get the same info doesn't seem great, but it doesn't matter to me as long as the information is available. Another option is to throw an error if developers try to access forbidden attributes during dragenter/dragover. Michael On Fri, 22 Jan 2010, Daniel Cheng wrote: Two more questions about implementation details: Cut/copy: Does it make sense to fire a drag event at all? The spec says that drag events should be fired at the source node every 350ms (presumably to allow the source node to cancel a drag after it started), but a cut/copy takes place instantaneously. I've clarified the spec to say that the loop has to happen immediately and then only repeat every 350ms if it's still active. If drag events should be fired during cut/copy, should the clipboard be restored to its original state if the drag event is cancelled? It would make sense, but might make implementations more complicated. The idea is for the cut/copy to be done exactly as if it was a drag to a hypothetical clipboard window, meaning everything happens in the drop part, so yes. Paste: It seems like there is no time a dragleave event would ever fire. A paste essentially goes through the drag and drop loop once; the only possible transition is for the current target element to go from null to non-null. The 'dragleave' event can fire during a paste if the drag is canceled. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Drag-and-drop feedback
On Mon, 17 Aug 2009, Jian Li wrote:
In order to download the attachment from an Internet mail application,
the user will have to click the attachment link and a save dialog will
pop up to let the user select the destination folder. This will normally
involves multiple clicks. Native application, like Outlook, can let the
user drag attachments directly into the destination place, i.e. desktop,
which is really convenient.
We propose adding a specific format string to the DataTransfer object:
DownloadURL. The data associated with the DownloadURL format should
be parsed similar to the URL format. When the drag ends in another
application, the remote file described in the associated data URL should
be downloaded and provided to the target application.
How would this be exposed to other apps? Is it possible in Windows to drop
something and then have the application that received the drop wait for a
download (which could take hours) to complete? How does that work?
If we can rely on the download happening before the drag, then we could
add something to the DataTransfer object to add File objects.
On Fri, 4 Sep 2009, Jens Alfke wrote:
On Sep 3, 2009, at 6:05 PM, Francisco Tolmasky wrote:
However, I think the addition of the deferred setData methods could be
added today in a way that is completely backwards compatible with
current implementations and would still be of great benefit.
Specifically, my request for deferring the calling of toString on
non-string objects as such:
event.dataTransfer.setData(something, { toString: function() {
return expensiveFunctionCall(); } });
This would allow me to submit patches to Firefox and WebKit that would
solve the current performance issues which are literally blocking my
ability to switch from fake drag and drop to native drag and drop.
At the same time, this should still work today in all browsers that
implement setData because the object is coerced into a string
immediately for you, thus not requiring immediate action on their part
to change anything.
+1. A real drag-n-drop API has to support promised data.
I agree with this in principle, but I think we should wait for DND to be
properly implemented in current browsers before adding this.
On Tue, 12 Jan 2010, Michael Davidson wrote:
The table in section 7.9.3 says that the DataTransfer object should be
empty for dragenter and dragover events.
Clearly this is not the case - the example in 7.9.1 shows that, at the
very least, the DataTransfer object needs to have a 'types' attribute so
that the drag handler can determine if it can accept the drag.
I've tried to clarify what empty is supposed to mean here.
The issue that I'm having is that if the DataTransfer object says that
it has Files, I have no way to determine what type those files are. (In
this case, I only want to accept image files.) I understand that the
DataTransfer shouldn't have the content of the files for security
reasons, but it would be helpful if it did contain the file names and/or
MIME types.
I could provide a second attribute with the types of the files, would that
work? I suppose if we did this, we should remove the Files fake type.
That might not be a bad idea in general, it's kind of a hack. I'm not sure
how I feel about having multiple different ways of representing the data
in a DataTransfer object... It would give a clean precedent for adding
other features, though, like promises, which some people have requested.
On Fri, 22 Jan 2010, Daniel Cheng wrote:
Two more questions about implementation details:
Cut/copy:
Does it make sense to fire a drag event at all? The spec says that drag
events should be fired at the source node every 350ms (presumably to allow
the source node to cancel a drag after it started), but a cut/copy takes
place instantaneously.
I've clarified the spec to say that the loop has to happen immediately and
then only repeat every 350ms if it's still active.
If drag events should be fired during cut/copy, should the clipboard be
restored to its original state if the drag event is cancelled? It would
make sense, but might make implementations more complicated.
The idea is for the cut/copy to be done exactly as if it was a drag to a
hypothetical clipboard window, meaning everything happens in the drop
part, so yes.
Paste:
It seems like there is no time a dragleave event would ever fire. A paste
essentially goes through the drag and drop loop once; the only possible
transition is for the current target element to go from null to non-null.
The 'dragleave' event can fire during a paste if the drag is canceled.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Sat, Jan 23, 2010 at 11:30 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 17 Aug 2009, Jian Li wrote: [...] The issue that I'm having is that if the DataTransfer object says that it has Files, I have no way to determine what type those files are. (In this case, I only want to accept image files.) I understand that the DataTransfer shouldn't have the content of the files for security reasons, but it would be helpful if it did contain the file names and/or MIME types. I could provide a second attribute with the types of the files, would that work? I suppose if we did this, we should remove the Files fake type. That might not be a bad idea in general, it's kind of a hack. I'm not sure how I feel about having multiple different ways of representing the data in a DataTransfer object... It would give a clean precedent for adding other features, though, like promises, which some people have requested. Would it be possible to provide a list of drag items (to call them somehow) instead of, or in addition to, the current info provided by the DataTransfer object? More formally, add a property of type DragItemList that might be called DragItems. The DragItem type (building brick for DragItemList) could provide the data and meta-data for each object being dragged (that'd be the getData, clearData, and setData methods, a readonly string type and a readonly boolean isFile). In principle, that list could actually replace the DataTransfer object. In order to keep compatibility with existing content, either of these approaches could work: 1) Actually replace the DataTransfer object with the DragItemList, but make the DragItemList type implement DataTransfer's interface. 2) Instead of replacing, add the list as a new field/property/attribute/whatever-you-call-it to the DataTransfer object. This approach would solve the issues of dragging multiple files and the potential drop targets needing to check the metadata (such as the type); but in addition would seamlessly adapt if in the future a mechanism of performing a multi-object drag appear. Keeping in mind how many modern software can already handle multiple selections, that seems a quite near feature. For example, in some word processors it's possible to hold the Ctrl key while dragging the mouse over the text to select additional text fragments: when such a split selection is dragged or sent to the clipboard, the text fragments are typically concatenated; but if the drop or paste target is any kind of list, it would be reasonable (and in some cases a significant upgrade in usefulness) to import the fragments as separate entries for the list. As long as the drag (or cut/copy) source provides some metadata to identify the boundaries of each fragment, this functionality enhancement would be quite easy to implement (currently, it is impossible on most contexts). Anyway, that's just an idea. BTW, all the type and member names used in the proposal are arbitrary and can be changing for anything more convenient. The only purpose of those names was to describe what they represent. Regards, Eduard Pascual
Re: [whatwg] Drag-and-drop feedback
On Sun, 11 Oct 2009, Garrett Smith wrote: My question is: Which browser does document.initDragEvent work in? Do you mean DragEvent.initDragEvent? Document.initDragEvent is inordinately long and cumbersome, taking 16 arguments, and requiring the creation of a DataTransfer object. That seems extremely cumbersome just to get a drag event to fire. This method doesn't seem to be implemented anywhere FWICT. Was it copied from an existing implementation? It seems to have been an invention. But whose? It's just the usual way things are done for events. I'll follow whatever DOM3 Events says to do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Mon, Oct 12, 2009 at 4:37 AM, Ian Hickson i...@hixie.ch wrote: On Sun, 11 Oct 2009, Garrett Smith wrote: My question is: Which browser does document.initDragEvent work in? Do you mean DragEvent.initDragEvent? AH, yeah. The event is under MouseEvent, then? So:- document.createEvent(MouseEvents); Document.initDragEvent is inordinately long and cumbersome, taking 16 arguments, and requiring the creation of a DataTransfer object. That seems extremely cumbersome just to get a drag event to fire. This method doesn't seem to be implemented anywhere FWICT. Was it copied from an existing implementation? It seems to have been an invention. But whose? It's just the usual way things are done for events. I'll follow whatever DOM3 Events says to do. Sorry, but I don't see how that answers my questions. It seems it was not copied from existing implementations, but was instead an invention. Who wrote that API? Garrett
Re: [whatwg] Drag-and-drop feedback
On Mon, 12 Oct 2009, Garrett Smith wrote: On Mon, Oct 12, 2009 at 4:37 AM, Ian Hickson i...@hixie.ch wrote: On Sun, 11 Oct 2009, Garrett Smith wrote: My question is: Which browser does document.initDragEvent work in? Do you mean DragEvent.initDragEvent? AH, yeah. The event is under MouseEvent, then? So:- document.createEvent(MouseEvents); It's a DragEvent, so you have to do: document.createEvent(DragEvent); Document.initDragEvent is inordinately long and cumbersome, taking 16 arguments, and requiring the creation of a DataTransfer object. That seems extremely cumbersome just to get a drag event to fire. This method doesn't seem to be implemented anywhere FWICT. Was it copied from an existing implementation? It seems to have been an invention. But whose? It's just the usual way things are done for events. I'll follow whatever DOM3 Events says to do. Sorry, but I don't see how that answers my questions. It seems it was not copied from existing implementations, but was instead an invention. Who wrote that API? The DragEvent interface is new in HTML5, but it uses the same conventions as all interfaces that inherit from Event. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Drag-and-drop feedback
On Tue, Nov 25, 2008 at 6:52 PM, Ian Hickson i...@hixie.ch wrote: (Note: feedback relating to drag-and-drop of files from the filesystem, with possible uploading of content, isn't included in this e-mail. I am waiting to see what happens with the Web Apps File Upload spec.) On Mon, 30 Apr 2007, Jon Barnett wrote: On 4/30/07, Ian McKellar i...@mckellar.org wrote: On 4/25/07, David Hyatt hy...@apple.com wrote: The use case of being able to drop images into a contenteditable region and have them show up as img elements at the appropriate place and then get automatically uploaded somewhere is a really compelling one. Is there already an API for knowing exactly where something is dropped? Possibly - an empty Range object as either the relatedTarget or part of the detail of a drop event. There isn't, but isn't the cursor moved to the drop target position automatically in most systems? And in systems where that doesn't happen, shouldn't the drop happen where the cursor is anyway? On Wed, 18 Jun 2008, Neil Deakin wrote: The initDragEvent/initDragEvent methods take a DataTransfer as an argument. Is it expected that the DataTransfer to use here can be created with 'new DataTransfer'? No. If you really wanted to create your own DragEvent object, you'd have to fake a DataTransfer object using a JS object that happened to implement all the right attributes and methods. If I understand correctly, the rationale for the design decisions for HTML5 drag and drop was largely founded upon existing functionality in IE and Safari. My question is: Which browser does document.initDragEvent work in? Document.initDragEvent is inordinately long and cumbersome, taking 16 arguments, and requiring the creation of a DataTransfer object. That seems extremely cumbersome just to get a drag event to fire. This method doesn't seem to be implemented anywhere FWICT. Was it copied from an existing implementation? It seems to have been an invention. But whose? There doesn't seem to be any implementation for creating and dispatching drop events. The problem of creating and dispatching drag events still exists and needs a good solution. The solution provided by HTML 5 is cumbersome. As proposed: createInitedEvent(type, options); The event has default values, based on the type. |options| type: object |options| provides property/value pairs that replace default values for the event. If a default value is not replaced by an option property value, then the default value is used instead. http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0164.html Garrett
[whatwg] Drag-and-drop feedback
(Note: feedback relating to drag-and-drop of files from the filesystem, with possible uploading of content, isn't included in this e-mail. I am waiting to see what happens with the Web Apps File Upload spec.) On Mon, 30 Apr 2007, Jon Barnett wrote: On 4/30/07, Ian McKellar [EMAIL PROTECTED] wrote: On 4/25/07, David Hyatt [EMAIL PROTECTED] wrote: The use case of being able to drop images into a contenteditable region and have them show up as img elements at the appropriate place and then get automatically uploaded somewhere is a really compelling one. Is there already an API for knowing exactly where something is dropped? Possibly - an empty Range object as either the relatedTarget or part of the detail of a drop event. There isn't, but isn't the cursor moved to the drop target position automatically in most systems? And in systems where that doesn't happen, shouldn't the drop happen where the cursor is anyway? On Wed, 18 Jun 2008, Neil Deakin wrote: The initDragEvent/initDragEvent methods take a DataTransfer as an argument. Is it expected that the DataTransfer to use here can be created with 'new DataTransfer'? No. If you really wanted to create your own DragEvent object, you'd have to fake a DataTransfer object using a JS object that happened to implement all the right attributes and methods. IE and Safari allow a no-argument form of clearData as well which clears all formats. Added. The description for the 'types' property implies that this should be a live list. Why? Why not? The clearData, setData and getData methods should clarify what happens if an empty format is supplied. Done. I still don't understand the purpose of the addElement method. Either this should be removed or there should be clarification of the difference between addElement and setDragImage Added a note. Previously, I said that DragEvents should be UIEvents. I think they should instead inherit from MouseEvent. Done. We have a need to be able to support both dragging multiple items, as well as dragging non-string data, for instance dragging a set of files as a set of File objects (see http://www.w3.org/TR/file-upload/) from the file system onto a page. Agreed, but I haven't added anything for files yet because I'm waiting for that spec to stabilise. On Fri, 20 Jun 2008, Robert O'Callahan wrote: On Thu, Jun 19, 2008 at 9:31 AM, Thomas Broyer [EMAIL PROTECTED] wrote: That's how Adobe AIR solved the problem. They added a Bitmap and File list data formats, for which getData returns AIR-specific objets (a BitmapData and an array of File objects respectively) Creating a new data format for each kind of collection seems suboptimal. And it breaks completely if you want heterogeneous collections. It would be useful to have a clearer description of use cases for this kind of thing. When would an app be dragging a mixed bag of stuff like this? (That aren't all files, and that can't all be described together as a single piece of data with a single type.) On Thu, 14 Aug 2008, Greg Houston wrote: [...] something lacking in the HTML5 drag and drop specification is the ability to define a handle for the element that is being dragged. With the drag and drop in javascript libraries you can define a handle (a different element) that drags the draggable element. If the handle property/attribute is null then the element itself is it's own handle. Isn't that just dragging the handle? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
