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