Re: [editing] CommandQuery Object and Event

On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński <p.koszulinski@cksource.com> wrote:
> 1. That we need any native UI related to cE at all.
> We don't. We can display our own toolbars, with our own buttons, with our own icons and implementing our own logic. So the easiest solution to the problem with irrelevant native UI is to not display it at all.

You may not need native UI working at all in your app, but that doesn't mean all other developers don't want it at all.  Furthermore, enabled-ness of items in desktop browser's edit menu should reflect the current state of the editor; otherwise, it would degrade the user experience.

Furthermore, we shouldn't design our API only for existing platforms.  We need to make it so that new, completely different paradigm of UIs and devices could be built using new API we design.

Another important use case for browsers to know the state of the editor is for accessibility.  AT may, for example, want to enumerate the list of commands available on the page for the user.

> 2. That we need any native architecture for commands.
> We don't. What a command is? It's a name, function and a state+value refreshed on selection change. A command repository can be implemented in JavaScript in few lines of code. CKEditor has one (and I guess that all advanced editors have), because it is a necessary component on which we must have full control. What it does, when it does, how a command is executed, what arguments it accepts, which commands are available for specific editor instance, etc.

Providing default editing behavior may not be desirable for that reason.  However, it would be still of connivence to provide some helper functions to do the work automatically when the author opts-in so that he/she doesn't have to write every single editing logic himself/herself.

- R. Niwa

Received on Friday, 6 June 2014 16:39:32 UTC