- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Mon, 05 Sep 2011 00:04:53 +0200
- To: public-webapps@w3.org
On Sun, 10 Apr 2011 18:20:35 +0200, timeless <timeless@gmail.com> wrote: >> http://dev.w3.org/2006/webapi/clipops/clipops.html >> Also, the XML source could be placed in the clipboard with the >> appropriate transformation occurring when pasting. > > The XML source can also ... Fixed. > I find "when pasting" problematic. "At paste time" might be better, or > some indication of which side is doing the transformation. Not sure which is better but accepted your suggestion. > --- >> interface ClipboardEvent : Event { >> void initClipboardEvent (in DOMString eventType, in boolean >> canBubble, in boolean cancelable, in DOMString dataType, in DOMString >> data); > > doesn't seem to allow for multiple flavors. It doesn't. I don't think the use case for a script sending multiple "flavours" of data to itself through a synthetic event is all that interesting. I guess we could do something like evt.initClipboardEvent('paste', true, true, {'text/plain':'Hello world', 'text/html':'<b>Hello world</b>'} ); but I don't think we need the added complexity.. >> The associated drag data store is a live but filtered view of the >> system clipboard, exposing all data types the implementation knows the >> script can safely access. > > "safely" seems underspecified, you probably should clarify that this > includes not exposing anything for synthetic events. Improved ;-) There is that requirement for synthetic events elsewhere though, so I don't think it needs repeating here. >> 5.3 Determining the target property for clipboard events >> In an editable context, the event object's target property must refer >> to the element that contains the start of the selection in document >> order, i.e. the end that is closer to the beginning of the document. > > iirc DOMRanges can have start after end to indicate that the user has > made a selection in reverse. Is there a reason to ignore that > information and give different targets each time the user extends the > selection? As far as I remember this is just based on current implementations. >> Calling getData() too many or too few arguments should throw > > calling foo() _with_ .... Seems fixed. >> Calling clearData() empties the system clipboard, or removes the >> specified type of data from the clipboard. See HTML5 for details >> [HTML5]. > > This has issues. If the user has inserted something the user cares > about into the system clipboard, then allowing a web page to stomp on > it is annoying. Something needs to protect the user from such web > apps. That's outside the realm of the spec. There is a section on nuisance potential, and I'd myself perhaps prefer a UA that implemented some limitations, but in general the spec tries to enable cool things rather than worrying about the few naughty sites that would cause nuisance. >> Calling getData() from within a paste event handler will return the >> clipboard data in the specified format. See HTML5 for details [HTML5]. > > doesn't explain what should happen when the web app tries to paste a > content type the user agent has decided it shouldn't have access to. That's up to HTML5 but AFAIK it will just return an empty string. >> The event is asyncronous but must be dispatched before keyup events for >> the relevant keys. > > asynchronous Ops, thanks. >> The user might paste hidden data which the user is not aware of. > > ".. not aware of" is kinda messy. Also, perhaps "hidden data" already > indicates the user doesn't know about it? Improved. >> The implementation must not download referenced online resources and >> expose their contents in the FileList. > > s/and/or/ OK >> Objects implementing the DataTransfer interface to return clipboard >> data must not be available outside the ClipboardEvent event handler. >> If a script stores a reference to an object implementing the >> DataTransfer interface to use from outside the ClipboardEvent event >> handler, all methods must be no-ops when called outside the expected >> context >> Implementations must not let scripts create synthetic clipboard >> events to get access to real clipboard data > > the last two points are missing <period>s Fixed. >> Implementations must handle scripts that try to place excessive amounts >> of data on the clipboard gracefully. > > I hope "gracefully" is flexible. If my impl wants to terminate the > page, it should be able to do so. (I don't expect it to do so, but I > reserve the right) Certainly. "Gracefully" basically means something like "don't crash the OS, don't crash yourself, and don't make the computer run very, very slowly while you're busy". >> Remove all of the following elements: SCRIPT, APPLET, OBJECT, FORM, >> INPUT, BUTTON, TEXTAREA, SELECT, OPTION, OPTGROUP and comment nodes. >> For all mentioned elements except FORM, also remove all child nodes. > > I can imagine doing magical things with a <style> tag... So you think STYLE should be added? > However, removing the active value from a select seems suboptimal. > > If you see: > > State: [ .... |v] > > And use it to get: > > State: [ Washington |v] > > When you copy it, do you expect: > > "State: " or "State: Washington"? I expect the latter, it's > considerably more useful. Yes. I'm still considering removing the form elements from that list though. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Received on Sunday, 4 September 2011 22:08:16 UTC