W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2010

Re: TextEvent.data on pasting HTML.

From: Hajime Morita <morrita@google.com>
Date: Mon, 2 Aug 2010 14:02:39 +0900
Message-ID: <AANLkTik95ZnCdiC_ui5c8Y-p06=+oM4r+m=bmu2SQWkh@mail.gmail.com>
To: www-dom@w3.org
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.


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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:16 UTC