Re: TextEvent.data on pasting HTML.

Tony, Ojan, thank you for your feedback.

I agree that adding new attribute can make things complicated,
especially if the attribute points a DOM node.
So I'll use only data attribute and keep that attribute empty for
copy/paste at this time,
for avoiding someone to depend on such "unspecified" behavior.
I think such implementation doesn't need to change the standard
and it would be fine.

--
morita


On Fri, Jul 30, 2010 at 6:37 AM, Ojan Vafai <ojan@chromium.org> wrote:
> 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
>>>
>>>
>>
>
>



-- 
morita

Received on Monday, 2 August 2010 05:03:10 UTC