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

Re: TextEvent.data on pasting HTML.

From: Tony Chang <tony@chromium.org>
Date: Thu, 29 Jul 2010 10:01:20 -0700
Message-ID: <AANLkTimMUXs8gRRABT+kEB=Le9bH+F3w--M4QSWN1pyd@mail.gmail.com>
To: Hajime Morita <morrita@google.com>
Cc: www-dom@w3.org
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.


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 Thursday, 29 July 2010 17:02:07 UTC

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