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?

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

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.

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?

paul

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to