Re: Comments on drag and drop

On Thu, 20 Sep 2007, Mihai Sucan wrote:
> 
> 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.

Yeah, this, and other clarifications of an informative nature, will be 
added to an introduction of that section in due course. I've added a 
placeholder for this.


> 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).

I've removed the restrictions on copy/paste that are given in the above 
comments.


> 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.

It does. Just use the drag-and-drop events. Copy-and-paste is a subset of 
drag-and-drop.


> 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.

Added.


> 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]

There's a note in the spec to add these. I'm waiting for the WebAPI 
working group to work out what should be going on with keys, so that I 
don't have to keep changing this to track progress over there. The story 
of keys in DOM Events is a very long and sad one so far.


> 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.

Agreed; however, this is out of scope for this spec. We may suggest it in 
the rendering section, though.


> 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.

Yeah, we'll add an introduction section with examples and diagrams in due 
course.

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

Received on Friday, 15 February 2008 01:12:49 UTC