On Sun, 10 Apr 2011 18:20:35 +0200, timeless <timel...@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/
