Re: [clipboard] document.execCommand and clipboard actions
On Thu, Aug 6, 2015 at 11:00 AM, wrote: > Hi, > Sorry if I might be out of scope, I am quite new in this mailing list. > Welcome, and sorry that I'm late at responding. > 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... > Right now the goal is to make things work better across the board and make things "safe enough" to enable certain clipboard functionality for *all scripts* out there - even without security prompts and explicit permissions. It's pretty obvious that we need quite a lot of limitations for this to work (including a limitation on writing whatever types and data you'd like to the clipboard). > I agree with the need to define a new clean Clipboard API But we'll get to that later - first we want implementations to support what we've got at the moment, and the spec is still changing based on implementor feedback like that from the Blink team saying allowing JS to write binary image data directly is too dangerous. Since implementations are in progress right now, we'll probably learn over the next year or so if the current stuff is safe enough, and build an improved API from what we learn. -Hallvord
Re: [clipboard] document.execCommand and clipboard actions
On Thu, Aug 6, 2015 at 1:36 PM, Hallvord Reiar Michaelsen Steen < hst...@mozilla.com> wrote: ... > > I haven't been following discussions in that group, so I don't know how > many developers they consulted. I'm sure we all understand the frustration > with the contentEditable implementations out there - ensuring this feature > generates sane code has not exactly been a high priority for browser > vendors. Certain editors (with Google Docs being a very high profile case) > have been through a phase of using contentEditable and have simply moved on > to do various hacks where they fake selections and cursors by modifying the > DOM directly to avoid dealing with the serious inconsistencies of > cross-browser contentEditable implementations. > ... In the discussion have been involved (to more or less of a degree) people from among others the following projects: - CKeditor (probably the oldest open soruce richtext JS editor) - TinyMCE (one of the largest open sourcce editors) - Microsoft office online team (through Benjamin when he was still on the project) - Aloha Editor (they were at a meeting in Berlin last fall, but decided to create an editor not based on contentEditable for their version 2.0) - Wikimedia Visualeditor - Fidus Writer (myself) - Codemirror (basic consultation on what features they would need) - Substance.io (basic consultation on what features they would need) - Google Docs team (through Benjamin; I am not entirely sure what came back from them) - OxygenXML We also tried to contact some others from whom I do not think we heard back from: - HalloJS (uses cE, but development seems to have stopped) - Firepad (not using most of cE) - Careta (test editor, not using most of cE) - ShareLatex (build on either ACE or Codemirror) - WriteLatex (build on ACE or Codemirror) All of the developers of all JS editors seem to be in full agreement that contentEdtiable=true/execCommand as it is now is a mess and that at best some parts of it can be used, also because this is the only alternative available at times, in combination with a lot of JavaScript to make up for the rest. As for browser developers, we have spoken with people from: - Chrome - Internet Explorer - Safari I am unsure if Firefox has been involved, but we did reach out to them. With this many different projects + browser people, there are bound to be different ideas about solutions. The discussions over the last year have brought us together behind somewhat of a compromise, I feel. We are not trying to advocate to remove execCommand or against it being standardized more across browsers, also by contiuing the development of that. But there seems to be a general agreement that it is a priority to get access to the last remaining primitives (such as clipboard access) rather than waiting for execCommand/cE to be fixed entirely, which may or may not be happening ever. On Thu, Aug 6, 2015 at 9:09 AM, Anne van Kesteren wrote: > On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen > wrote: > ... > > > Would implementors want to support [a new API]? > > I think we should first solve the hard problems around security and > format interoperability. We can always add new APIs once the > underlying primitives are well understood. Doing that before seems > rather dangerous. And as you point, without respect for historical > precedent showing it's a bad idea. > As far as I can tell, the security model should be the same for all script accessed solutions, whether through execCommand or otherwise. If you change it for one of them, you could change it for the other one as well, and it will break just as many sites (or not break them). That being said, let's remember that this is only about adding a custom UI button for the paste/cut actions. Standard right-click menu cut/paste or cut/paste via key combinations should not be affected. One of the most important reasons that people need to do it via custom buttons is that one needs to override the right-click menu for other reasons. So it ends up not really affecting all editors. -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Re: [clipboard] document.execCommand and clipboard actions
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
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', 'Hello world');
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
Re: [clipboard] document.execCommand and clipboard actions
On Thu, Aug 6, 2015 at 9:09 AM, Anne van Kesteren wrote:
> On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen
> wrote:
> > 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).
>
> So you're saying most of this is deployed and used by content?
>
Any editor which has "copy", "cut" or "paste" buttons in its UI have
exactly two ways to implement those commands, document.execCommand() or
Flash. I haven't seen any editor use Flash for this, but they may exist.
The editors I have tested have a sort of "fallback mode" where they check
if the command is enabled, and if not tell the user to press Ctrl-C/X/V
instead - in the "paste" case they tend to pop up a specific dialog with a
rich text element for the user to paste into.
So yes, this is deployed and used by content but with a poor cross-browser
compat story that typically requires workarounds.
>
> > 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.
>
> It seems that's wrong at least as far as copy/paste is concerned,
> given our recent successes in getting Flash replaced by execCommand()
> calls.
>
I haven't been following discussions in that group, so I don't know how
many developers they consulted. I'm sure we all understand the frustration
with the contentEditable implementations out there - ensuring this feature
generates sane code has not exactly been a high priority for browser
vendors. Certain editors (with Google Docs being a very high profile case)
have been through a phase of using contentEditable and have simply moved on
to do various hacks where they fake selections and cursors by modifying the
DOM directly to avoid dealing with the serious inconsistencies of
cross-browser contentEditable implementations.
>
> > Would implementors want to support [a new API]?
>
> I think we should first solve the hard problems around security and
> format interoperability. We can always add new APIs once the
> underlying primitives are well understood. Doing that before seems
> rather dangerous. And as you point, without respect for historical
> precedent showing it's a bad idea.
>
Makes sense to me.
-Hallvord
Re: [clipboard] document.execCommand and clipboard actions
On Wed, Aug 5, 2015 at 2:34 AM, MOHAN ARUN wrote: > Would implementors want to support (writing stuff to the clipboard)? > Yes, we really, really want to allow that - at least for simple cases. There are plenty of complex questions - for example "what formats is it safe to let JS place on the clipboard on any platform?" but we start with the easy ones and take it from there. I'm afraid I didn't really understand your other points, but thanks for responding. -Hallvord
Re: [clipboard] document.execCommand and clipboard actions
On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen
wrote:
> 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).
So you're saying most of this is deployed and used by content?
> 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.
It seems that's wrong at least as far as copy/paste is concerned,
given our recent successes in getting Flash replaced by execCommand()
calls.
> Would implementors want to support [a new API]?
I think we should first solve the hard problems around security and
format interoperability. We can always add new APIs once the
underlying primitives are well understood. Doing that before seems
rather dangerous. And as you point, without respect for historical
precedent showing it's a bad idea.
--
https://annevankesteren.nl/
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
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', 'Hello world');
> 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
