Re: Copy to Clipboard - ambush and abuse by javascript

Le 10-juin-10 à 02:35, David Booth a écrit :

>> The ability to manipulate what a user is copying is also important
>> for applications on the Web.  If you're using a Web app like Google
>> Docs, you want copy to copy a useful representation, not the
>> internal representation that the editor uses.
>
> But it is the *browser* that renders things like HTML, plain text,  
> PDF,
> etc. -- not javascript.  Why should javascript be given the ability to
> mess with it *after* the user has selected and told the browser to
> *copy* it?
>
> When I tell my browser to copy, I expect my browser to *copy* -- not
> copy-and-adulterate-under-web-site-control.  When I paste, whatever I
> copied may be converted to the destination format for compatibility,  
> but
> that's a different issue.

That was the reason MathML has a *markup-based* clipboard approach: an  
element called semantics where the first child is the sub-tree to be  
processed normally and other annotation(-xml) children are alternate  
representations.
Some of these alternate representations are in the page, some can be  
fetched from other URIs.

This does not fully prevent the scripts to change the markup if  
listening to the selection anyways (I guess a "copy without service"  
should actually put a random selection and call the selection  
listeners before really doing the copy).

The reason you want alternate representations to be fetched, or  
scripts to run to provide the alternate representations, is that a  
copy is an operation that happens considerably less often than a  
fragment production. For example, producing a vector graphics output  
of a formula, for example, would only be done if the copy is invoked.

I personally tend to prefer a markup based approach but HTML5 is  
bathing in javascript APIs, so it's just another.
(plus html5 had a microdata attempt which got removed)
RDFa for clipboards? This I did not see.

paul

Received on Thursday, 10 June 2010 07:41:50 UTC