W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [editing] CommandQuery Object and Event

From: Piotr Koszuliński <p.koszulinski@cksource.com>
Date: Fri, 6 Jun 2014 15:48:14 +0200
Message-ID: <CAFk9nexiM7CLAOtDsi9hmfnTDo7gZAvDNcQNaXCxXMpVSQ3GOA@mail.gmail.com>
To: Ben Peters <Ben.Peters@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Fri, Jun 6, 2014 at 1:29 PM, Piotr Koszuliński <
p.koszulinski@cksource.com> wrote:

> 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
Received on Friday, 6 June 2014 13:48:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:25 UTC