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 <ann...@annevk.nl> wrote: > On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen > <hst...@mozilla.com> 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
