Changes between Initial Version and Version 1 of Ticket #11219, comment 1
- Timestamp:
- Nov 27, 2013, 9:13:12 AM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #11219, comment 1
initial v1 1 Yes, this is on purpose and it was consistent when I implemented that. Every DnD operation with widgets caused paste event. 1 Yes, this is on purpose and it was consistent when I implemented that. Every DnD operation with widgets caused paste event. It stopped to be consistent when we implemented block widgets DnD with lineutils. 2 2 3 The reason why I think DnD (all kind of DnD in the future) should fire paste is that this becomes a single entry point for content inserted directly to the editable. So editor is configured to force paste as plain text, then if someone DnDed an HTML from outside editor, that HTML will be "textified". So there will be an equality between pasting and dropping content.3 The reason why I think DnD (all kinds of DnD in the future) should fire paste event is that this becomes a single entry point for content inserted directly to the editable. So if e.g. editor is configured to force paste as plain text, then if someone DnDed an HTML from outside the editor, that HTML will be "textified". So there will be an equality between pasting and dropping content. 4 4 5 5 However, we're talking here about DnDing inside editor, which could behave differently. But on the other side distinguishing between dragging from outside editor and within it would be tricky. Also, paste event is fired always - no matter what's the source of the data. … … 10 10 2. in case of block widgets DnD, the selection would have to placed between blocks, what's not possible, so some hack would have to be used. 11 11 12 I had doubts before about using paste event, now (when block widgets are DnDed differently) I have more, but I still see a need to single point input. 12 I had doubts before about using paste event, now (when block widgets are DnDed differently) I have more, but I still see a need to single entry point. 13 14 So I'm afraid that we may need a complex solution. A new event ("input" maybe), which would inherit some behaviours from paste event (e.g. textifying and paste from word filters), but could be used by the original "paste" event and a new "drop" event and would not insert content itself (it would do only filtering), so "drop" won't be limited to selection (block widgets scenario). 13 15 14 16 I'll ask others for opinions.
