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

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