Re: clipboard events

Thanks for working on this!

On Wed, Jan 5, 2011 at 2:41 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:
>
>  If the cursor is in an editable element, the default action is to insert
>> clipboard data in the most suitable format supported for the given context.
>>
>> In an editable context, the paste event's target property refers to the
>> element that contains the start of the selection. In a non-editable
>> document, the event is targeted at a node focused by clicking or by an
>> interactive cursor. If the node that has focus is not a text node, the event
>> is targeted at the BODY element.
>>
> I'm not sure if it makes sense for the element to be the start of
> selection.  Why not just pass the root editable element?  The website
> already have access to the selection so it can get start/end of selection.
>  Mentioning of clicking or cursor is unnecessary.  One can use keyboard to
> move focus / selection and copy / paste should still work.  I'm not sure why
> we're special-casing text node / non-text node.  Is there some reason to
> this?  (i.e. compatibility with Internet Explorer?)
>

Ditto on all points. Also, why does this clause not apply to the cut/copy
events as well? What does "start" mean here? Start in document order e.g. as
opposed to the anchor/base of the selection?

> This .types spec is slightly different from the HTML5 DnD .types -
consistent enough to make sense to authors and implementers?

What's the benefit of being different? In general, the closer we can be to
HTML5 DnD, the easier it will be for everyone.

> Implementations are encouraged to also support text/html for dealing with
HTML-formatted data.

In an ideal world, implementations would support any string type. This would
allow for creating custom clipboard formats as well as common mime types
(e.g. image types). Do most operating systems support setting generic string
types on the clipboard?

Ojan