Re: [editing] CommandQuery Object and Event

On Wed, Jun 4, 2014 at 8:31 PM, Ben Peters <Ben.Peters@microsoft.com> wrote:

> There has been some conversation about browser UI for Commands with
> ContentEdtiable=minimal. Some people seem to believe that UI should not be
> displayed because it may not be relevant.


I think that it was me talking about mobile Safari displaying its native
toolbar over contenteditable field. But this is not a solution I had in
mind.

Few weeks ago we started discussing about contentEditable=minimal. It was a
great relief for me, because I consider contentEditable=true being already
ideologically dead for a long time and I see no point in resurrecting it.
There was a common agreement that contentEditable=true is wrong because it
tries to be an entire application rather than just a base, a necessary
architecture for frameworks and applications built in JavaScript on top of
it.

Why I mention this now? Because I think that two wrong assumptions have
been made.

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.

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.

In a simple case, when I want my FontName command to apply <span
class="font[[Name]]"> to selected text instead of the default... <font
family="[[Name]]">, I need to:

a) Totally override the way how command is applied. I need to remove other
spans with classes starting with "font" class, and wrap content with my new
span.
b) Totally override command's state and value handling. It has to discover
correct span tags (only these with proper classes), read the font family
name from class name and handle it accordingly. Additionally, I don't have
to do that on every selectionchange event - I care only about
selectionchange events fired when an element in which selection starts
changes. This is a big performance improvement.

So what's left from a native command? Nothing. I can't even reuse algorithm
applying inline elements to selection. That actually would be useful, but
such algorithm also needs to be customisable, so it's better if it's
implemented in JavaScript.


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.


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer