On Fri, Jun 6, 2014 at 1:29 PM, Piotr Koszuliński < p.koszulin...@cksource.com> wrote:
> > TL;DR > 1. Let's drop execCommand and queryCommandState. They have no real value > for developers and clearly conflict with cE=minimal. JavaScript frameworks > will be created which will allow implementing totally custom and > customisable commands. > 2. Expose necessary APIs and architecture so all necessary commands can be > implemented in JavaScript. Currently I can think only about copy, cut, > paste which someone may want to disabled in some conditions. Maybe also > undo and redo, because I can imagine that advanced editor's logic may be > too complex to use native undo manager (but maybe I'm wrong - I haven't > read undo manager's spec). Basically, it would be nice if we were able to > control state of commands that should appear in browser menu bar or context > menu, but that does not have to be based on currently existing commands API. > > To give an example. 1. User presses down key. 2. A command event with commandType == 'moveSelectionDown' is fired. 3 a. If app does not execute preventDefault(), then the default action is executed by browser. The default action means executing e.g. selection.move( DIRECTION_DOWN ) or any other more complex code but using exposed APIs. 3 b. If app executes preventDefault(), then it can call selection.move( DIRECTION_DOWN ) and the result should be identical. Or it can preventDefault() and e.g. execute selection.move( DIRECTION_END_OF_DOCUMENT ) The idea is to expose necessary functions in form of selection/element/whatever methods and use these methods. The same may be achieved by execCommand() and related methods, but: a) backward compatibility, b) not standardised, c) too high-level in some cases, d) not the best API design ever, e) problem with extensibility. -- Piotrek Koszuliński CKEditor JavaScript Lead Developer