Re: TextEvent.data on pasting HTML.

It would also be fine to have data be the empty string for pastes and drops.
The paste/drop events already exist and give that data. I think we should
keep textInput as simple as possible for now. Specifically, I think we
should only expose data for the input modes that can only insert plain text
(e.g. keyboard, speech, etc).

Using plain text for pastes/drops would be fine too, but I don't see what
use-case it fulfills and it's added complexity.

Ojan

On Thu, Jul 29, 2010 at 10:01 AM, Tony Chang <tony@chromium.org> wrote:

> For HTML pastes, I think it is sufficient to just provide the plain text in
> TextEvent.data.  Providing a DOM node can be tricky because there might be
> script tags or other JS event handlers that get evaluated when parsed.
>
> If a site wants to cancel the event based on the HTML being pasted, it can
> use the existing onbeforepaste event.  The same is true for drop operations:
> they can be canceled during the ondrop event.
>
> tony
>
> On Mon, Jul 26, 2010 at 3:11 AM, Hajime Morita <morrita@google.com> wrote:
>
>> Hi,
>>
>> I'm extending TextInput implementation of WebKit.
>> And I'm wondering how should we do when HTML is pasted (or dropped)
>> into the contentEditable area.
>> Specifically, What value should be given for TextEvent.data attribute?
>>
>> Then, to handle the HTML correctly, TextEvent.data is not enough anyway
>> because its type is DOMString, not DocumentFragment.
>> We need a pasted HTML itself. It's vital part of customizing editing
>> behavior in JS world.
>>
>> Here is an idea:
>> - for data attribute, give a DocumenetFragment.textContent equivalent.
>> - to accessing the pasted DocumentFragment, add an "newValue"
>> attribute, whose type is Node.
>> -- It's no longer a "Text" event. So subclassing might be sufficient.
>>
>> How do you think?
>> Any suggestions are appreciated.
>>
>> Regards.
>> --
>> morita
>>
>>
>>
>