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?
