W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: DnD vs CnP (was Copy/Paste Events)

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 31 Aug 2009 02:44:06 +0000 (UTC)
To: Paul Libbrecht <paul@activemath.org>
Cc: "public-webapps@w3.org Group WG" <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0908310238080.6775@hixie.dreamhostps.com>
On Sat, 22 Aug 2009, Paul Libbrecht wrote:
> Le 22-août-09 à 07:51, Ian Hickson a écrit :
> > > 
> > >  copy-and-paste is aimed at long term storage: if you write to the 
> > > clipboard you have to write all the flavours you think a recipient 
> > > would ever make use of! The clipboard often survives 
> > > computer-restarts.
> > 
> > Drag-and-drop can also be for long-term storage -- drag whatever it is 
> > you were going to copy to your clipboard to your clipboard
> 
> erm... can you give me the pixel coordinates of my clipboard please?

It's wherever your clipboard program's window is.


> > ... same result. And with the DND model in HTML5, you have to "write 
> > all the flavours you think a recipient would ever make use of" in the 
> > same way as you describe for copy-and-paste.
> 
> To me, as a server implementor, this is a problem: I will not offer any 
> expensive type for DnD then, while I could offer them if I knew the 
> target wishes to get, say, a PDF of the formula that was just dragged.

I agree that this is a problem; we can fix it in a future version.

Note that copy-and-paste doesn't mean generating everything at copy time 
either. Just like with drag-and-drop, you could easily model copy-and- 
paste as a promise model.


> > DND in HTML5 generates the data at drag time, not drop time.
> 
> Well, this is the choice of HTML 5 I am debating, precisely. It all 
> comes (consistently) together as a problem.

We don't really have much choice over what the API is -- it's whatever IE 
implemented about 10 years ago. We can add more features, but we should 
wait until we have good interop with this version first.


> > > So I would insist to split the two set of events while keeping 
> > > common, of course, some of the interfaces to denote what can be 
> > > transferred.
> > 
> > I see no reason to split them.
> 
> Maybe a reasonable approach would be to have on "simplified" API that 
> corresponds to this one which merges the two while a finer grained API 
> would differentiate them?

I see no benefit to differentiating the two.


On Thu, 27 Aug 2009, Paul Libbrecht wrote:
>
> While re-reading the spec:
> 	http://dev.w3.org/html5/spec/Overview.html#drag-and-drop-processing-model
> I seem to understand that "supply data immediately" is the alternative
> proposed currently by HTML5. Right?

Yes.


> If yes, then it's clear that most server-implementors will not be able 
> to offer rich flavours as possible conversion targets since you don't 
> want to wait on a network load for a drag-start to fire!

Correct.


> Honestly, I find the whole DnD and CnP treatment in HTML5 quite much 
> ad-hoc. It's welcome to have such an addition but it makes too many 
> arrangements and still is hard to read.

Yes, it's a horrible model. It's one that had been implemented multiple 
times before the spec existed, and implementations trump pretty much 
everything except security problems when it comes to deciding what the 
spec should say.


> What I would wish, and I think many many many others is a readable 
> specification for copy-and-paste that meets large implementations and 
> maybe later something for drag-and-drop.

I agree that the drag-and-drop spec should be easier to read. I'm hoping 
that maybe Lachlan's authoring document will include help on how to use 
the API.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 31 August 2009 02:42:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT