W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: CfC: new WD of Clipboard API and Events; deadline April 5

From: timeless <timeless@gmail.com>
Date: Sun, 10 Apr 2011 19:20:35 +0300
Message-ID: <BANLkTikr0LR1fca0+5aBEVTveo02L-6QcQ@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
On Tue, Mar 29, 2011 at 2:37 PM, Arthur Barstow <art.barstow@nokia.com> wrote:
>  http://dev.w3.org/2006/webapi/clipops/clipops.html
>
> If you have any comments or concerns about this proposal, please send them
> to public-webapps by April 5 at the latest.

Sorry, i've been doing other stuff....

[editorial]

> Mathematical information
> With content such as mathematics, simply copying rendered text and pasting it into another application generally leads to most of the semantics being lost.

I think "math" is more appropriate here.
And probably "leads to the loss of most of the semantics."

> Also, the XML source could be placed in the clipboard with the appropriate transformation occurring when pasting.

The XML source can also ...

I find "when pasting" problematic. "At paste time" might be better, or
some indication of which side is doing the transformation.

---
> 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.

> clipboardData of type DataTransfer, readonly
>    The clipboardData attribute is an instance of the DataTransfer interface which lets a script read and manipulate values on the system clipboard during user-initiated copy, cut and paste operations. 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.

> 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?

> Calling getData() too many or too few arguments should throw

calling foo() _with_ ....

> 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.

> 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.

> The event is asyncronous but must be dispatched before keyup events for the relevant keys.

asynchronous

> 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?

> The implementation must not download referenced online resources and expose their contents in the FileList.

s/and/or/

>     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

> 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)

> 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...

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.
Received on Sunday, 10 April 2011 16:21:03 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:44 GMT