Re: Clipboard API: Default content in copy/cut handlers
- Cancelling the event can result in one of two things: - If event.clipboardData is empty, nothing happens. The system clipboard does not change. Here, the spec differs from how browsers behave so I've chosen to document how browsers behave. Neither Firefox nor Chrome let you clear the contents of the clipboard by calling event.clipboardData.clearData(). IMO, we should update the spec to reflect this. I've reported https://www.w3.org/Bugs/Public/show_bug.cgi?id=23232 to make sure I don't forget this issue even though I'll mark your mail as read now ;-) -Hallvord
Re: Clipboard API: Default content in copy/cut handlers
Daniel, I personally think it is not at all a good idea to populate the clipboard when starting the drag! It makes sense when a copy operation is triggered, as the application may be vanishing. Most desktop DnDs I have observed only operate the transformation when the drop has occurred (hence a flavour is identified). A good way to test this is to take a heavy piece in a graphics programme and drop it outside. Those two specs have evolved independently and I always sow clipops to be a more refined version of html5's DnD but there you have spotted a non-extension point. Is there any reason to justify the requirement to populate before the dragstart? Paul On 12 juil. 2013, at 00:22, Daniel Cheng wrote: I've noticed that the way that drag-and-drop processing model is written, the default content that would be in the drag data store is available in the dragstart event. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-and-drop-processing-model specifies that the drag data store is populated before dispatching the dragstart event. Would it make sense to do something similar for http://dev.w3.org/2006/webapi/clipops/#processing-model? Right now, as I read it, we don't populate the clipboard until after the copy/cut event has been cancelled. It'd be nice to make it consistent with drags... the main problem is I'm not sure if this will break compatibility with sites that didn't expect this. Daniel
Re: Clipboard API: Default content in copy/cut handlers
The issue I've come up against is in keyboard access to the DnD model. Clipboard semantics exist in their own world, with OS quirks. DnD presupposed some kind of security-consent from the user. It's one of the most powerful gestures, allowing a user to grant read access to an entire directory tree. Unfortunately, we don't have that semantic easily accessed from the keyboard. On the desktop, copy and paste hot keys are often used for keyboard access to drag and drop, even though you can't copy a folder into a text document. That's the state of things. I do think browser vendors should be responsible for implementing DnD via keyboard. onclick works via keyboard but even with input file, WebKit has not extended the same support as a DnD onto an input element (vs click and file selection). Process has stalled, there's a stalemate between vendors. -Charles On Jul 12, 2013, at 12:56 AM, Paul Libbrecht p...@hoplahup.net wrote: Daniel, I personally think it is not at all a good idea to populate the clipboard when starting the drag! It makes sense when a copy operation is triggered, as the application may be vanishing. Most desktop DnDs I have observed only operate the transformation when the drop has occurred (hence a flavour is identified). A good way to test this is to take a heavy piece in a graphics programme and drop it outside. Those two specs have evolved independently and I always sow clipops to be a more refined version of html5's DnD but there you have spotted a non-extension point. Is there any reason to justify the requirement to populate before the dragstart? Paul On 12 juil. 2013, at 00:22, Daniel Cheng wrote: I've noticed that the way that drag-and-drop processing model is written, the default content that would be in the drag data store is available in the dragstart event. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-and-drop-processing-model specifies that the drag data store is populated before dispatching the dragstart event. Would it make sense to do something similar for http://dev.w3.org/2006/webapi/clipops/#processing-model? Right now, as I read it, we don't populate the clipboard until after the copy/cut event has been cancelled. It'd be nice to make it consistent with drags... the main problem is I'm not sure if this will break compatibility with sites that didn't expect this. Daniel
Re: Clipboard API: Default content in copy/cut handlers
On Fri, Jul 12, 2013 at 1:22 AM, Daniel Cheng dch...@google.com wrote: I've noticed that the way that drag-and-drop processing model is written, the default content that would be in the drag data store is available in the dragstart event. http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-and-drop-processing-model specifies that the drag data store is populated before dispatching the dragstart event. Would it make sense to do something similar for http://dev.w3.org/2006/webapi/clipops/#processing-model? Right now, as I read it, we don't populate the clipboard until after the copy/cut event has been cancelled. That's true, because the (legacy) model is that you only write to the clipboard by cancelling the default action of copying whatever is selected to the clipboard. This is probably mostly intended to be consistent with other DOM events, but it's a somewhat strange gotcha for authors and I've even made the mistake of forgetting to call preventDefault() myself. Regarding the question: I'm not sure what exactly you're asking for with something similar and what effect it would have. Is it about reading from clipboard (for example, since you mention DnD of files, like reading pasted file references in a paste event)? Writing to the clipboard? Is there any change the clipboard spec should make to make pasting files/folders easier to implement? If yes, how and why? Thanks in advance for any elaborations, but please note that my current E-mail address will stop working. Just send replies to the list and I'll find them. -Hallvord It'd be nice to make it consistent with drags... the main problem is I'm not sure if this will break compatibility with sites that didn't expect this. Daniel
Re: Clipboard API: Default content in copy/cut handlers
Right, I think this makes total sense. A common example might be to add your page's URL, copyright notice, etc. to the end of whatever text the user has selected WITHOUT having to query the Selection/Range APIs to [hopefully] retrieve their selected text. I am discouraged, however, to see someone who works for a browser vendor lamenting that doing it in what is likely the right way may be impossible because a number of browser vendors have already implemented the functionality. To me, it doesn't really seem like adding this new behavior would negatively affect the current APIs at all as no one is *expecting* to have that data provided on the Event right now; the only real change here is in the browser internals, and consumers can take advantage of such by eliminating their current Selection/Range queries once the Event is providing that data on their behalf. As someone who is not a browser vendor employee, this sounds very doable. ;) Sincerely, James Greene On Fri, Jul 12, 2013 at 2:05 PM, Daniel Cheng dch...@google.com wrote: On Fri, Jul 12, 2013 at 12:56 AM, Paul Libbrecht p...@hoplahup.net wrote: Is there any reason to justify the requirement to populate before the dragstart? My guess is that it's a convenience for authors to be able to modify the content from the default easily. On Fri, Jul 12, 2013 at 5:22 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: Regarding the question: I'm not sure what exactly you're asking for with something similar and what effect it would have. Is it about reading from clipboard (for example, since you mention DnD of files, like reading pasted file references in a paste event)? Writing to the clipboard? Is there any change the clipboard spec should make to make pasting files/folders easier to implement? If yes, how and why? My original idea is that prior to dispatching a copy/cut event, run if there is a selection, place the contents of the selection in the data store, then dispatch the copy/cut event. If the copy/cut event is not cancelled, then: - Write the data store to the clipboard. If the copy/cut event is cancelled: - Do nothing. The data store is discarded and the changes are not written to the clipboard. Unfortunately, this is completely opposite of how it's handled today by Firefox/Chrome/Safari so I don't think we can do this. Oh well. Daniel
Re: Clipboard API: Default content in copy/cut handlers
Sorry, I think I must've misunderstand what your original proposed changes were as I thought you meant that the DataTransfer interface's items weren't being pre-populated on the ClipboardEvent's clipboardData property for beforecopy/copy events. Now I'm thinking that THAT is already in place and you are just suggesting a change in what is considered the default behavior once there is a registered listener for the beforecopy/copy event(s). Node.js does a similar behavioral switch-up for uncaught exceptions. Normally an uncaught exception results in printing the stack trace and then exiting the process; however, if you add a listener for the `uncaughtException` event http://nodejs.org/api/process.html#process_event_uncaughtexception, then this default behavior will NOT happen and it's left up completely to the handler to choose whether to print a stack trace, exit the process, etc. Sincerely, James Greene On Fri, Jul 12, 2013 at 3:07 PM, Daniel Cheng dch...@google.com wrote: The problem is backwards compatibility. There are sites that use the copy/cut event handler, and the proposal reverses the behavior. Suppose it were implemented: On older browsers: You must call event.preventDefault() in order for your changes to be written to the clipboard. On newer browsers: You must NOT call event.preventDefault() in order for your changes to be written to the clipboard. This transition would be extremely confusing, even if the proposal does seem more intuitive =/ Daniel On Fri, Jul 12, 2013 at 12:20 PM, James Greene james.m.gre...@gmail.com wrote: Right, I think this makes total sense. A common example might be to add your page's URL, copyright notice, etc. to the end of whatever text the user has selected WITHOUT having to query the Selection/Range APIs to [hopefully] retrieve their selected text. I am discouraged, however, to see someone who works for a browser vendor lamenting that doing it in what is likely the right way may be impossible because a number of browser vendors have already implemented the functionality. To me, it doesn't really seem like adding this new behavior would negatively affect the current APIs at all as no one is expecting to have that data provided on the Event right now; the only real change here is in the browser internals, and consumers can take advantage of such by eliminating their current Selection/Range queries once the Event is providing that data on their behalf. As someone who is not a browser vendor employee, this sounds very doable. ;) Sincerely, James Greene On Fri, Jul 12, 2013 at 2:05 PM, Daniel Cheng dch...@google.com wrote: On Fri, Jul 12, 2013 at 12:56 AM, Paul Libbrecht p...@hoplahup.net wrote: Is there any reason to justify the requirement to populate before the dragstart? My guess is that it's a convenience for authors to be able to modify the content from the default easily. On Fri, Jul 12, 2013 at 5:22 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: Regarding the question: I'm not sure what exactly you're asking for with something similar and what effect it would have. Is it about reading from clipboard (for example, since you mention DnD of files, like reading pasted file references in a paste event)? Writing to the clipboard? Is there any change the clipboard spec should make to make pasting files/folders easier to implement? If yes, how and why? My original idea is that prior to dispatching a copy/cut event, run if there is a selection, place the contents of the selection in the data store, then dispatch the copy/cut event. If the copy/cut event is not cancelled, then: - Write the data store to the clipboard. If the copy/cut event is cancelled: - Do nothing. The data store is discarded and the changes are not written to the clipboard. Unfortunately, this is completely opposite of how it's handled today by Firefox/Chrome/Safari so I don't think we can do this. Oh well. Daniel