Re: Editing with native UI

On Tue, Jul 1, 2014 at 1:19 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> On Jun 24, 2014, at 3:44 AM, Robin Berjon <robin@w3.org> wrote:
>
>
> Second, it doesn't address the point made below about native UI exposing a
> likely non-natural subset of the commands I wish to support.
>
>
> That presumes an opt-out mechanism to enable native UI.  If we had used
> opt-in instead, then we wouldn't have this issue.
>

I think that it may happen in both cases. Developer won't know if on
platform X there's native UI for all commands that he/she wants to enable.
Mobile Safari displays numbered and bulleted lists buttons, but browser Y
may support only bold, italic and underline and in such case content
created on Safari will not be fully editable on browser Y.

That's why I can't imagine using native UI for more than a really simplest
use cases (e.g. comments on blog). But if native UI will stay, opt-in
mechanism is definitely the way to go.


>
>
> There is a list of problems with the current editing API:
>
>    - Undo/redo menu doesn't get enabled/disabled in accordance with the
>    app's intrernal undo stack.
>
>
Yes. It would be great if native undo/redo options were controllable. I'm
also hesitating whether cut and paste options should not be controllable.
That would give us similar control as we have over drag and drop.



BTW. It struck me recently that we're writing here about disabling commands
in order to remove them from native UI. But enabling/disabling command is
something different than removing (hiding/showing) option from native
toolbar or context menu.

For example - I may decide that inline styling (i.e. bold, italic) should
not be available in my editor. There's no point in having them in the
toolbar, so I want to remove them. On the other hand, my app has an
internal undo stack, so if it's empty I want to disable undo and redo
buttons. I don't want to hide them. I just want to change their state.

Similarly, different rules regarding what content is allowed may apply in
editable areas within one editor (having one toolbar). This is a very
popular scenario in CKEditor (see e.g. how toolbar behaves when moving
selection from main editing area to image's caption in [1]). In such case I
want to be able to disable some commands without hiding them, because
that's less confusing for users.

Therefore, I believe that we need two methods - one to control commands'
states and one to enable/disable features (meaning - showing/hiding). Also,
a feature isn't necessarily the same as command. We may have different set
of features that can be enabled and commands which states are controllable.


[1]
http://cdn.ckeditor.com/4.4.2/standard-all/samples/plugins/image2/image2.html

-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer