- From: Hallvord R. M. Steen <hallvord@opera.com>
- Date: Mon, 31 Jan 2011 18:31:07 +0900
- To: "Ryosuke Niwa" <rniwa@webkit.org>
- Cc: public-webapps@w3.org, "Paul Libbrecht" <paul@hoplahup.net>, "Dmitry Titov" <dimich@chromium.org>, "Robert O'Callahan" <robert@ocallahan.org>, "Ian Hickson" <ian@hixie.ch>, "Ojan Vafai" <ojan@chromium.org>
On Mon, 31 Jan 2011 18:02:34 +0900, Ryosuke Niwa <rniwa@webkit.org> wrote: >> It's simply spec'ed that way because both Firefox and WebKit agree on >> doing so ;) >> >> Why not just pass the root editable element? >>> >> >> That's what IE does. > > > I think IE's behavior makes more sense. OK. Any particular reason? Are you looking at it from the implementor's or the script author's perspective? Because of your E-mail address, I sort of assume that WebKit would be happy to change if we spec IE's behaviour :). Perhaps someone from Gecko could comment too? Relevant tests are for example http://dev.w3.org/2006/webapi/clipops/testsuite/034.html (event target when selection spans several elements - paste event on 'a') http://dev.w3.org/2006/webapi/clipops/testsuite/040.html (event target when selection spans several elements - reversed selection - paste event on document) (the latter does not work in IE - no way to reverse selection. There is a range of tests for this, listening for the events at different elements.) >>> Internet Explorer already implements most of this spec but >>> ClipboardData is >>> implemented as a property of window object. Why deviate? >> To me it seems to express much more clearly that this stuff is only >> available as a consequence of those events being triggered by the user. >> As >> such, event.clipboardData seems nicer than window.clipboardData. >> (Besides, >> both WebKit and Gecko already made this decision and it seems a useful >> way >> to let developers object-detect HTML5's stuff versus legacy IE stuff.) >> > > I'm not sure we should allow access to clipboard only when those events > are > fired. I can see browsers that support application stores might want to > allow purchased apps to be able to access clipboard access. Also, > browser > vendors can permit users to grant clipboard access permissions to certain > websites that act more like natives apps. And for those apps, > event.clipboardData isn't sufficient. And I don't think we should be > limiting such use cases by the spec. I think that is outside the scope of this spec. It's a spec for clipboard *events*, not for general clipboard access, and I'd like to keep that scope. >> If getData() is not called from within a paste event handler, or if the >>>> type is not available, the method returns undefined >>>> >>> >> What should we do if getData is called within a copy event handler? >> We >>> have an outstanding bug that requests that getData returns the content >>> that's about to be copied into the clipboard ( >>> https://bugs.webkit.org/show_bug.cgi?id=22017). Should we consider >>> such >>> a behavior? >>> >> >> Thanks for the bug reference, an interesting and very relevant issue. I >> don't think it really makes sense to do what the bug reporter requests, >> because the copy event fires *before* the copy operation takes place. >> At the >> time, whatever data was on the clipboard previously will still be there, >> returning that in getData() doesn't seem to have much of a use case. >> Returning the new data you're about to copy seems a bit confusing since >> it's >> not actually the data that is on the clipboard. (Did you agree with this reasoning, by the way? You didn't comment on this.) > Another thing. Should getData guarantee to return the same result each > time called within the same event handler? i.e. if some external > applications > overrode clipboard's data between two calls to getData, what should > happen? IMO getData() should be 'live' - i.e. return what's on the clipboard. Do you think that is harder to implement or less performant than the other possible behaviour? I guess it might give less performance, but I doubt repeated calls to getData() is a use case worth optimising for. Thanks again for your feedback :) -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Received on Monday, 31 January 2011 09:31:44 UTC