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

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?

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Monday, 2 May 2011 02:51:06 UTC