Re: [whatwg] HTML5 cut/copy

[Maciej Stachowiak]

On Jan 23, 2010, at 3:19 AM, Ian Hickson wrote:

> On Fri, 22 Jan 2010, Maciej Stachowiak wrote:
>> 
>> I don't think it makes sense to have cut/copy/paste use drag events.
>> 
>> 1) Browsers already have specific events for cut/copy/paste - those 
>> three plus beforepaste are used in content, including in major sites, so 
>> they must be implemented for Web compatibility regardless of anything 
>> else. It seems unwise for HTML5 to document a brand new untested way to 
>> do events for cut/copy/paste, but not document the existing way that is 
>> needed for Web compatibility. Thus, even if cut/copy/paste operations 
>> continue to fire the drag events, the pre-existing events should be 
>> documented.
> 
> Are there sites that use them for useful purposes but that do not support 
> drag and drop? (If so, I'd like to study them to see what can be learnt 
> from them. Last I checked, use of the copy/paste events was almost 
> uniformly for anti-user reasons, and I couldn't find any sites that made 
> good use of them.)

Here are some sites that use cut/copy/paste event listeners. Given the nature 
of the sites, I do not believe these event listeners are set for user-hostile 
purposes. But the way I got this information (by instrumenting my copy of 
WebKit) does not lend itself to revealing the particular purpose for which the 
listeners are set:

https://mail.google.com/ (only when you call up the compose window)
beforecut
beforepaste
cut
paste

http://google.com/
paste  (it's on the main input field, but the JS is obfuscated so I can't 
tell what it does - no drag event listeners)

http://mail.yahoo.com/ (after logging in, and additional listeners are set when 
you focus the compose window)
paste
cut

http://docs.google.com/  (when viewing a Document)
beforecut
beforepaste
cut
copy
paste

http://docs.google.com/  (create a new presentation and click an editable text 
area)
beforecut
beforepaste
cut
paste

http://hotmail.com/ (when opening compose window)
cut
paste

http://livejournal.com/ (in the "Post a New Entry" view)
paste

http://me.com/ (Sign in page; likely more after that but that would cost money 
to test)
paste




> 
>> 2) In native UI, it is not always the case that drag-and-drop is 
>> possible whenever cut/copy/paste is. For example, in Preview on Mac OS 
>> X, if you select a rectangular piece of an image, you can cut or copy 
>> it, but you can't drag it.
> 
> Is there a good reason for this?

The bottom line is that it's a design choice and shouldn't be forced by the 
API. Although I'm not the UI designer responsible for this decision, my best 
guess is that this would interfere with the lasso selection gesture. Whether 
it's a really great reason or not, I'd be hesitant to design an API that 
second-guesses our UI designers.


> 
>> 3) In native UI, even when cut/copy/paste and drag are both possible, 
>> they do not always have the same effect. For example, it's common that 
>> in reorderable lists you can drag to reorder, but on the Mac at least 
>> they rarely allow reordering via cut/copy/paste. Instead there are 
>> specific key bindings for reordering (often including up or down arrows 
>> with modifiers).
> 
> 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. Sounds like 
something to fix, not something to compound with another design flaw.

> 
> 
>> Drag and drop also has positional information that is lacking for 
>> cut/copy/paste. When dragging files in a file manager's icon view, you 
>> can drop the icon at the exact position of your choice, but 
>> cut/copy/paste often inserts in a position based on the current 
>> arrangement. This requires an actual distinction between operations.
> 
> The API does support that distinction -- when the operation was performed 
> without position information, the screenX and screenY coordinates will be 
> zero.

That's exactly the problem. Paste is not equivalent to a drop at (0, 0) in 
screen coordinates (unless you assume that a valid drop target can never be at 
(0, 0), but that is not a correct assumption in general). Granted, this could 
be fixed by having an explicit flag to indicate "no position".


> 
>> 4) In native UI, it is not always the case that cut/copy/paste is 
>> possible whenever drag-and-drop is. For example, bookmarks in Safari's 
>> Bookmarks Bar can be dragged to reorder, but cannot be cut and pasted. 
>> The keyboard-accessible interface for reordering the bookmarks bar is 
>> via the bookmarks manager.
> 
> Is t

[whatwg] event.dataTransfer formats

[Daniel Cheng]

>
> 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 has this to say about MIME types:

> The type, subtype, and parameter attribute names are case-insensitive.


IE also ignores case for format strings:

> 

  window.clipboardData.setData('Text', 'FAILURE');

  window.clipboardData.setData('tEXT', 'SUCCESS');

  alert(window.clipboardData.getData('Text'));



results in an alert saying 'SUCCESS'.

Given that, would it make sense to change the spec to make format strings
case-insensitive?

Daniel

Re: [whatwg] Drag-and-drop feedback

[Eduard Pascual]

On Sat, Jan 23, 2010 at 11:30 AM, Ian Hickson  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] HTML5 cut/copy

[Ian Hickson]

On Fri, 22 Jan 2010, Maciej Stachowiak wrote:
> 
> I don't think it makes sense to have cut/copy/paste use drag events.
> 
> 1) Browsers already have specific events for cut/copy/paste - those 
> three plus beforepaste are used in content, including in major sites, so 
> they must be implemented for Web compatibility regardless of anything 
> else. It seems unwise for HTML5 to document a brand new untested way to 
> do events for cut/copy/paste, but not document the existing way that is 
> needed for Web compatibility. Thus, even if cut/copy/paste operations 
> continue to fire the drag events, the pre-existing events should be 
> documented.

Are there sites that use them for useful purposes but that do not support 
drag and drop? (If so, I'd like to study them to see what can be learnt 
from them. Last I checked, use of the copy/paste events was almost 
uniformly for anti-user reasons, and I couldn't find any sites that made 
good use of them.)


> 2) In native UI, it is not always the case that drag-and-drop is 
> possible whenever cut/copy/paste is. For example, in Preview on Mac OS 
> X, if you select a rectangular piece of an image, you can cut or copy 
> it, but you can't drag it.

Is there a good reason for this?


> 3) In native UI, even when cut/copy/paste and drag are both possible, 
> they do not always have the same effect. For example, it's common that 
> in reorderable lists you can drag to reorder, but on the Mac at least 
> they rarely allow reordering via cut/copy/paste. Instead there are 
> specific key bindings for reordering (often including up or down arrows 
> with modifiers).

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.


> Drag and drop also has positional information that is lacking for 
> cut/copy/paste. When dragging files in a file manager's icon view, you 
> can drop the icon at the exact position of your choice, but 
> cut/copy/paste often inserts in a position based on the current 
> arrangement. This requires an actual distinction between operations.

The API does support that distinction -- when the operation was performed 
without position information, the screenX and screenY coordinates will be 
zero.


> 4) In native UI, it is not always the case that cut/copy/paste is 
> possible whenever drag-and-drop is. For example, bookmarks in Safari's 
> Bookmarks Bar can be dragged to reorder, but cannot be cut and pasted. 
> The keyboard-accessible interface for reordering the bookmarks bar is 
> via the bookmarks manager.

Is there any reason to disallow that model though? If it was free to 
support it, would you still have disabled it?


> 5) The drag and drop event sequence is way too complicated to use for 
> the simple case of customizing copy/paste behavior. Many of its fiddly 
> details are simply not applicable.

The drag and drop event sequence is way too complicated to use for drag- 
and-drop, let alone copy/paste. But if you've done the work to get drag- 
and-drop working, it seems silly to have to do even _more_ work to get 
copy/paste working as well.


In any case, while the above points are all good points, the reason for 
emulating copy/paste using the drag-and-drop model is actually to ensure 
that pages that use the (primarily mouse-based) drag-and-drop model are 
still accessible to keyboard users, and to ensure that the model is indeed 
in fact device-independent, and as such, I don't think they are a 
convincing argument to remove the feature. While it is true that Apple can 
be trusted to provide a keyboard-accessible UI, I think it would be 
optimistic of us to assume that everyone who provides a drag-and-drop UI 
thinks about how it can be used by non-mouse users.

Independent of this, though, I agree that we should specify the copy/paste 
events, if they are indeed used on pages that don't support drag-and-drop. 
Are these events documented anywhere?


> Filed as .

FWIW, sending a mail to the WHATWG list has the same effect as filing a 
bug, there's no need to do both.

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

[whatwg] Drag-and-drop feedback

[Ian Hickson]

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 l

Re: [whatwg] Authoring feedback on

[Kit Grose]

I agree with Aryeh in principle; when you're updating the suggestions on every 
keypress, extra processing and DOM manipulation at the Javascript level would 
be good to avoid.

As far as Aryeh's lack of other use-cases for comboboxes in general, a good 
place to use one would be for inline additions of keywords/metadata tags in a 
web application or on a web site. It would allow for trivial entry of new 
metadata tags using existing ones if available or any arbitrary new one if 
required.

I've also built apps that have used autocompletes for things like email 
addresses/usernames in private messaging fields and other similar situations. 
Unlike search applications, these fields are often used inline within other 
fields/containers. I would hope that Maciej's example (using the standard OS X 
combo box) would permit significant CSS styling to fit that scenario.

—Kit