Re: Clipboard API: Default content in copy/cut handlers

2013-09-13 Thread Hallvord Steen
 - 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

2013-07-12 Thread Paul Libbrecht
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

2013-07-12 Thread Charles Pritchard
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

2013-07-12 Thread Hallvord Reiar Michaelsen Steen
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

2013-07-12 Thread James Greene
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

2013-07-12 Thread James Greene
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