Hi,
Sorry if I might be out of scope, I am quite new in this mailing list.
The clipboard is aimed to exchange any? data between any apps running on
your computer. It is not a browser stuff, it is an OS stuff that any app,
including a browser, may use. I would like to use it in such a way I could
programatically cut/paste any (even not usual mime types) data, not only
contenteditable items data.
Now the problem is that the way a browser uses the clipboard has a lot of
limitations due first to security reasons and secondly to the fact that no 2
UA implement it the same way... Today it is really hard, IMHO, to write
cut/paste code working on all UA in order to exchange data with the "outside
the browser" world. If it is to cut/paste data "inside my webapp" then I
would not use the clipboard...
I agree with the need to define a new clean Clipboard API like the example
given by Hallvord that all UA will follow.
And I would add to the example something like that :
items.add(any_mime_type, serialized_data);
The serialized data could be like the base64 data URI scheme :
items.addDataURI(base64_data_uri);
Yves
-----Message d'origine-----
From: MOHAN ARUN
Sent: Wednesday, August 5, 2015 2:34 AM
To: WebApps WG
Subject: Re: [clipboard] document.execCommand and clipboard actions
Would implementors want to support (writing stuff to the clipboard)?
Actually, no - "The Simpsons already did it."
Lets not think about windows clipboard. Those are Windows.
We are browser.
I feel clipboard is something that contains copy of
contenteditable items of the same web page.
We seem to be forgetting our basics.
Thx,
MohanArun.com
@cintanotes2
On Wed, Aug 5, 2015 at 3:01 AM, Hallvord Reiar Michaelsen Steen
<hst...@mozilla.com> wrote:
Hi,
so I hit a bit of an issue: I've written some parts of the clipboard spec
with the assumption that it will be invoked from a
document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
require some extra permission work which no UA but IE has attempted so
far).
Meanwhile, the editing task force has gathered feedback on developing
editor
features from implementors and drawn the conclusion that the current
"stuff"
including contentEditable=true and document.execCommand() is
unsalvageable.
So their aim is to deprecate and remove execCommand(). If it were to be
removed, I obviously can't expect it to be used for clipboard actions. On
the other hand, my expectation that I can build stuff on top of
execCommand() makes life more complicated for them when they aim to
deprecate it.. Some discussion ensues:
https://github.com/w3c/editing/issues/61
https://lists.w3.org/Archives/Public/public-editing-tf/2015Aug/0001.html
I'm not sure how to proceed. Now, "the old stuff isn't good enough, let's
have a clean slate and do new and shiny things" is an approach that hasn't
worked very well so far when writing specs for the web. This time might of
course be different. (Personally I doubt it though. I'm not even sure if
they developers who told them "the old stuff is something we don't want to
touch, let's forget about contentEditable=true" had given this enough
thought..)
It's also true that the current approach in the clipboard spec -
especially
for writing stuff to the clipboard - is a bit hackish. Perhaps I (unlike
the
Editing task force) have been *too* deferential to the existing
implementations, including stuff like onbefore* events that no browser so
far did a good job implementing. (Nope, not even IE although it was
invented
there). I can see why Johannes Wilm suggests making a new API instead..
If we came up with a completely new "write to clipboard" API - for example
something like
if(window.clipboard){
var items = new DataTransferItems(); // ignore that we can't currently
construct this..
items.add('text/plain', 'Hello world');
items.add('text/html', '<p>Hello world</p>');
items.imageFromElement('image/jpeg', document.images[0]);
window.clipboard.write(items).then(function(){
alert('Copied all parts to clipboard!');
});
}
Would implementors want to support that?
- Hallvord
