On 01/31/2011 11:02 AM, Ryosuke Niwa wrote:
On Tue, Jan 25, 2011 at 9:26 PM, Hallvord R. M. Steen
<hallv...@opera.com <mailto:hallv...@opera.com>> wrote:
On Thu, 06 Jan 2011 07:41:01 +0900, Ryosuke Niwa <rn...@webkit.org
<mailto:rn...@webkit.org>> wrote:
In an editable context, the paste event's target property
refers to the
element that contains the start of the selection. In a
non-editable
document, the event is targeted at a node focused by
clicking or by an
interactive cursor. If the node that has focus is not a text
node, the event is targeted at the BODY element.
I'm not sure if it makes sense for the element to be the start
of selection.
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.
I think Webkit's and Gecko's behavior makes more sense.
You paste to some location in the editable area, not to root of it.
-Olli
Mentioning of clicking or cursor is unnecessary. One can use
keyboard to move focus selection and copy / paste should still work.
Yes, it's meant to be an example - I added the words 'for example'.
Okay.
compatible with
http://msdn.microsoft.com/en-us/library/ms535220(v=vs.85).aspx
but I guess getData and setData's return type prevent this.
I guess at least setData() and clearData() could easily return a
boolean in HTML5 too. Ian? (I assume it indicates whether the
clipboard operation succeeded or not).
Right.
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.
This sounds quite reasonable things to do but I'm not sure if we
should
spec it. Vendors can decide what to do by themselves. For
example, I'd
imagine browsers can implement some interactive UI that lets
user decide
whether or not he/she wants to paste / copy certain content on
demand.
Allowing access only within the event handler might be too
restrictive.
I think we should spec the most common and safest case. Vendors are
free to do what they like anyway.
For the above reason, I'm strongly against such security mechanism /
policy woven into the spec.
On Thu, 06 Jan 2011 16:27:33 +0900, Ryosuke Niwa <rn...@webkit.org
<mailto:rn...@webkit.org>> wrote:
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. It also seems a bit
redundant, given that the event listener has access to the
selection, can read data from there and do whatever fixes are
required, then use setData(). So I'd personally prefer the currently
spec'ed text, but if others want to chime in and "vote for" the
"show what we'll place on the clipboard" option I'd like to hear any
arguments..
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?
- Ryosuke
