Changes between Version 1 and Version 12 of Ticket #11460


Ignore:
Timestamp:
Feb 27, 2014, 11:59:45 AM (6 years ago)
Author:
Piotr Jasiun
Comment:

I created set of samples for problems mentioned above.

  1. Retrieving HTML on dragstart.
    • readHtmlOnDragstart.html​. Works pretty well. Of course there are some edge cases (like fake selection) but these could be fixed later. I don't see any blocking issues here.
  2. Remembering dragged selection.

Both bookmark2 and range needs to be changed to the bookmark after drop, because we need to create a bookmark for a drop position which can destroy bookmark2 or range.

  1. Retrieving drop position.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #11460

    • Property Status changed from confirmed to assigned
    • Property Owner set to Piotr Jasiun
    • Property Summary changed from The editor#drop event - handling dropping content in editor to Handling dropping content in editor
  • Ticket #11460 – Description

    v1 v12  
    1 Part of #11437.
    2 
    3 === Spec (status: proposal) ===
    4 
    5 1. Editor#drop event has to be introduced. It has to be able to carry the same data as a native drop event, so e.g. multiple files as some blobs if spec assumes that (http://www.w3.org/TR/2010/WD-html5-20101019/dnd.html#dnd should be checked to see what's possible). So the first step of normalisation has to be done before firing editor#drop. Alternatively, a wrapped native event may be carried, in which normalisation would be done on demand in its getter methods. The decision has to be made depending on browsers' implementations compatibility. I guess that differences may be so significant that simple wrapper would not make sense. In both cases a class representing new data type has to be introduced, so in fact the final solution may be something between simple wrapper and initial normalisation.
    6 
    7 2. After drop was fired, if it wasn't cancelled, editor#paste has to be fired so editor#paste will be the single entry point for content inserted by user.
    8 
    9 3. Editor#paste accepts only HTML strings and it seems to be very unsafe to change this. So if non-HTML content has been dropped, it has to be translated to HTML string. For example - dropped image should be translated to '<img src="..." alt="">'. The source will be a reference to a blob carried as additional drop event data (files list). Editor#paste can be fired only if #drop returned a value of HTML type. See point 6.
    10 
    11 4. A general idea may be that drop event data is a value-type pair (+ additional value-types pairs for additional files, etc. if that will be required - see 1.) and the translation from non-HTML type to HTML string will mean changing value to HTML string and type to 'html'.
    12 
    13 5. The default translation should be done by a #drop listener with high priority (>10) or after #drop. It should be done only if #drop does not yet carry a data in HTML type. This way we'll allow overriding default translation behaviour, by attaching #drop listener performing it earlier. Also, in my opinion it will be better if default translation was done by a #drop event listener too, because it will allow to change something after it happened.
    14 
    15 6. We still need to analyse where to put what part of this feature. For example it would be nice if we could add basic dnd support to all standard presets and make the full support with files support optional. The basic part should be able to work without the optional part.
    16 
    17 7. Uploading files has to be handled by #paste (because files can be pasted and dropped and #paste is the single entry point). Ticket: #11461.
    18 
    19 8. Widgets dnd will have to be aligned to changes made in this ticket. Ticket: #11219.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy