Re: [editing] CommandQuery Object and Event

On Fri, Jun 6, 2014 at 6:39 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> 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.
>
>
I am sorry for the dramatic tone of this message, but I am honestly shocked
by my today's discovery. Namely, I checked what Safari displays in
contenteditable's context menu. For those who don't have access to Safari:

* Substitutions (set of options like smart copy/paste, smart quotes, smart
dashes, smart links, etc. plus "show substitutions" option displaying a
native popup).
* Transformations (make upper/lower case, capitalize).
* Fonts (two options that do not work ("show fonts" and "show colors") plus
bold, italic, etc.).
* Paragraph direction (ltr, rtl).

So what I saw on a mobile Safari (the floating toolbar) was only a tip of
an iceberg.

I don't want to say that these options should never be added. I don't also
want to say that they should be first standardised, then implemented
(though that would be perfect of course) or that they should be now dropped
(backward compatibility is a requirement I understand very well). My point
is that we would need to take all this into account when thinking about
fixing contenteditable=true. It must stop be surprising and unpredictable
for developers. That I think should be our goal - to make it predictable
and controllable.

There are two paths to achieve this goal:

1. Make all what's already implemented controllable, or at least possible
to disable.
2. Start from scratch (meaning contenteditable=minimal as an option, not as
a concept).

When the first option seems to be tempting I still believe it's not the
right way. It will force us to think about all the crazy stuff like native
toolbars, fonts, transformations, text direction, automatic substitutions,
ability to add new options, setting icons, a11y, localisable labels for new
options etc. All these things are complicated just by themselves and
besides them we still need to fit input or intent events, commands, their
states, etc. Even if we'll focus only on making all these controllable
(without defining expected behaviour) then we'll have to solve problems
like - should a command be executable if I disabled it? No? What if I want
to remove that option from native context menu/toolbar but reuse the
implementation?

That's why I think that the second option is better.
Contenteditable=minimal should not only be a concept - we need an option.
Option which will allow us, while creating a spec, to forget about legacy
features and not care about backward compatibility (which will be left in
form of contenteditable=true). In a shorter period we'll be able to come
out with a solution to at least part of the current problems and the
solution should also be cleaner. Otherwise, I'm afraid that the new spec
will end like the old one did.

Simultaneously, contenteditable=true will still be usable. In use cases not
satisfied by contenteditable=minimal developers will be able to use
contenteditable=true. Moreover, there will be a possibility to "backport"
features (like APIs and maybe command events) to contenteditable=true. But
the primary goal should be to make contenteditable=minimal useful, not to
enrich contenteditable=true.


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer