Le 22-août-09 à 07:51, Ian Hickson a écrit :
copy-and-paste is aimed at long term storage: if you write to theclipboard you have to write all the flavours you think a recipient wouldever make use of! The clipboard often survives computer-restarts.Drag-and-drop can also be for long-term storage -- drag whatever it is youwere going to copy to your clipboard to your clipboard
erm... can you give me the pixel coordinates of my clipboard please?
... same result. Andwith 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 forcopy-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
smime.p7s
Description: S/MIME cryptographic signature