Comments on drag and drop

Hello!

I have reviewed section 5.3. "Drag and drop" [1]. I have several comments  
to make.


The whole drag-and-drop API should specifically allow (mention in prose)  
that scripts can:

1. on dragstart setup several types of data - in different formats. Say,  
on dragstart a script can define setData('text/html', 'whatever') and  
setData('text/plain', 'whatever2'). However, do not limit this to textual  
content types: images, videos, sounds, and other binary formats should be  
allowed.

This can be done based on the source object, or based on any arbitrary  
data in the source document.

This is allowed by the spec now - but not very well explained.


2. on drop, the target object can retrieve any of the available types  
needed. Some targets can only accept text/html, some other text/plain,  
while others can accept any type of data.


3. The above two points should be valid in the copy/paste scenarios  
presented [2]. But for now, only two formats are allowed for paste:  
text/plain and text/uri-list. [3]

"When the user invokes a clipboard paste operation, the user agent must  
act as if the user had invoked a drag on a hypothetical application  
representing the clipboard, setting the data associated with the drag as  
the text from the keyboard (either as text/plain or text/uri-list). If the  
contents of the clipboard cannot be represented as text or URIs, then the  
paste operation must not have any effect."

That's not something "great".

The idea is: On Windows I can copy mathematical formulas from Mathematica,  
then paste in Notepad and I get the textual representation. I can also  
paste the "same" data in IrfanView where I get the actual render of the  
formula (like in Mathematica). The same goes for copy/pasting HTML: in  
Firefox you can copy HTML, then paste it as HTML in OpenOffice, or as  
plain text in Vim.

Why not allow this on the Web?


4. Pasting stuff should work on any focusable element in a HTML 5  
document. Do not restrict the paste action to inputs where text can be  
pasted (as it seems to be now, given the type restriction). Allow the  
scripts to do whatever they want with the provided data, with all the  
provided types.

Given the Mathematica example above: a script, on paste, could show the  
textual formula and the render of the formula in the same document.

Problem: there's a need to define a way to work with binary data in the  
DOM. For example, a way take an image/png from a paste action and display  
it in the document - this would be (almost?) doable with a data: uri.


5. The same goes for copy: allow users to try to "copy" any focusable  
element. Obviously, the UA will do nothing - unless some text can be  
copied to the clipboard - a selection. However, the script could provide  
some data (with the setData method).

The API provided by Microsoft [4] allows the authors to enable/disable the  
cut/copy/paste operations on elements, and to attach event handlers for  
all these operations. The HTML 5 spec should define something similar.


6. I read the HTML 5 spec on drag and drop, then I read the documentation  
 from Microsoft [5] and Apple [6]. Immediately after reading the spec I  
took some notes about having the type attribute for the dataTransfer  
object, defined as an array which lists the available data types. I was  
surprised to see exactly this idea in the Apple documentation for WebKit.  
Very good.

I strongly recommend adding the types attribute to the DataTransfer object.


7. Also, there should be a way to check the keyboard modifiers in the  
events (ctrl, shift, and alt). This is to allow authors to build web  
applications for to the following two scenarios, when the user starts  
dragging some object to a target:

a) The default action is to move the object. With Shift the object would  
be copied, not moved.

b) The default action is to copy the content of the object as HTML. Using  
Ctrl the content would be copied as text/plain.

Of course, there more use cases for allowing key modifiers - it really  
depends on the creativity of authors. Think of sliders, other complex form  
widgets, 3D objects, etc.

If I am not mistaken, Internet Explorer already provides these attributes.  
[7]



8. Two CSS pseudo-classes should be defined:

a) One pseudo-class which matches the source element being dragged  
:drag-src. KHTML already implements this with the :-khtml-drag  
pseudo-class. [6]

b) Another pseudo-class which matches the possible target element (when  
the user moves the pointer over any other element) :drag-dest.



9. The drag and drop XPCOM interfaces available in the Gecko platform is  
different, but actually provide rather similar functionality, similar  
concept. [8]

As it seems, Gecko doesn't provide any psuedo-classes for this API.


10. I find both of the descriptions of the whole drag and drop API better  
on Microsoft [5] and Apple sites [6], when compared to the HTML 5  
specification. Maybe you could take a look and see what could be done to  
"ease" the wording.

Currently, the spec seems to lack a good overview (from "above") of how  
everything works.



[1]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dnd.html#dnd
[2]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dnd.html#copy-and
[3]  
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-dnd.html#paste
[4] http://msdn2.microsoft.com/en-us/library/ms535220.aspx
[5] http://msdn2.microsoft.com/en-us/library/ms537658.aspx
[6]  
http://developer.apple.com/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/DragAndDrop.html
[7] http://msdn2.microsoft.com/en-us/library/ms536928.aspx
[8] http://developer.mozilla.org/en/docs/Drag_and_Drop


-- 
http://www.robodesign.ro

Received on Thursday, 20 September 2007 16:55:14 UTC