Re: paste events and HTML support - interest in exposing a DOM tree?

I see this as a possibly useful feature, even if it may not bring a 
sensible difference for CKEditor.

In CKEditor we do clipboard data manipulation through the following steps:

  1. Take the data string and send it to the browser, so it can clean up 
things a bit (we set innerHTML for a <div>).

  2. Take the innerHTML of that <div>.

  3. Pass it through a custom string parser, which doesn't involve DOM 
operations.

We do not use the DOM directly, because of its performance. Our custom 
parser does a better job in that sense.

If we have the DOM from the clipboard directly, we would at least avoid 
the above point 1, which could bring some performance benefits.

Thanks,
Fred

Frederico Caldeira Knabben
CEO, CKSource
----
http://cksource.com


Hallvord R. M. Steen wrote:
> Hi,
> a question related to the evolving draft on
> http://www.w3.org/TR/clipboard-apis/ (which actually is slightly better
> styled on http://dev.w3.org/2006/webapi/clipops/clipops.html - I should
> figure out why ;-))
>
> We want to enable some sort of access to HTML code if the user pastes
> formatted text from an application that places HTML on the clipboard.
> However, the browser will have to implement some security restrictions
> (see relevant section of the spec - though it's just a draft), and in
> some cases process the HTML to deal with embedded data when there are
> sub-parts on the clipboard.
>
> To handle both security algorithms and any embedded data, the browser
> will probably need to parse the HTML. So actually, when you call
> event.clipboardData.getData('text/html') the browser will get HTML from
> the clipboard, parse it, do any work required by security and data
> embeds rules on the DOM, and then serialize the code (possibly after
> modifying the DOM) to pass it on to the script. Of course the script
> will want to do its own processing, which will probably at some point
> require parsing the code again..
>
> So, to make things more efficient - would it be interesting to expose
> the DOM tree from the browser's internal parsing? For example, we could
> define
>
> event.clipboardData.getDocumentFragment()
>
> which would return a parsed and when applicable sanitized view of any
> markup the implementation supports from the clipboard. Rich text editors
> could now use normal DOM methods to dig through the contents and
> remove/add cruft as they wish on the returned document fragment, before
> doing an appendChild() and preventing the event's default action.
>
> Thoughts?
>

Received on Monday, 2 May 2011 20:08:14 UTC