Re: [editing] CommandQuery Object and Event

Responding to browser UI is one thing and I totally agree with the need for
user intent events. If user shakes iPhone editor should be notified that
user wanted to undo. But I does not tie this to commands at this point at
all. Events exist to notify app that something is going to happen. The
default behaviour of what happens may be hidden behind a command, method or
engine internals, but that's a separate topic.

As for CommandQuery Event, I commented it in [2] and indirectly in my
previous email. In my opinion it tries to hide symptoms of
contenteditable's sickness rather than cure it. "Existing commands break my
app or are useless for it, so let me allow to disable them".

1. Most editors will disable as much of them as possible (I wonder what
about paste/cut/copy) to hide native UI which may conflict with custom UI
(e.g. overlap it) or simply to block undesired, unclear feature.
2. If developer is forced to leave any of commands enabled (e.g. to not
lose clipboard support), he/she risks that native UI will be displayed and
will break his app.
3. If developer wants to enable some option (e.g. smart quotes) he/she
risks that native UI will break his app or that user will be able to
disable such option when should not be able to do that.
4. Some of these issues may be solved by special commands blocking native
UI without disabling specific commands.
5. In many scenarios native UI is useless, because it cannot be extended
and redesigned (new buttons, new types of UI elements), so it only
satisfies small subset of use cases.
6. Even if e.g. mobile Safari displays all buttons necessary for
developer's use case, if any other browser does not do that, then developer
has to override everything anyway. Without interoperability
 7. A11y is not a reason to make browser handle all the UI. If ARIA's roles
are not sufficient or some API is missing, then they should be added, not
native UI extended. As I said, most of (advanced) editors will need to hide
native UI, so if providing a11y using HTML and JavaScript is not possible
on some platform (mobile?), then this problem will need to be solved anyway.
8. What if some command should have configurable behaviour? For example
quote characters used by smart quotes feature might be configurable
(language dependent?). What API allows this? Assuming that we've got two
commands - disableSmartQuotes and enableSmartQuotes, which of them I have
to disable to get rid of them from the UI? Sure there's a solution for all
that, but extending commands APIs indefinitely will lead to even bigger
mess than now. And having bazillion options in tight high-level API,
without providing any primitives is a bad design choice.

None of these points is a deal breaker when considered separately. But all
of them (plus many we don't yet see) combined together makes the situation
look terrible. Commands, related APIs, native UI are useless or problematic
for editors (meaning real editors, not these adding contenteditable=true to
a div) and still will be useless. Commands API might look extensible,
because it uses strings as commands identifiers, but that's a very
high-level native API, so if any feature is not included (like setting
characters used by smart quotes), everything has to be implemented in JS
from scratch. Native UI is inextensible and uncontrollable and still will
be (command events cover only execution logic).

Someone said that contenteditable=true tries to be an entire WYSIWYG editor
(a poor one actually) at once and that that's bad. I couldn't agree more.
Is adding new options to tame the contenteditable=true going to fix this?
No. It will make the situation slightly more acceptable, but
contenteditable=true is still terminally ill, because it still pretends to
be an editor.

[2] http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0826.html

 On Mon, Jun 9, 2014 at 10:28 PM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

> Is it just browser UI that leads you to want to start over? The goal of
> CommandEvents is to allow sites/frameworks to work with browser UI, whether
> toolbars like Safari or gestures or speech or accessibility tools or
> whatever else in the future. I understand that browser UI can be a problem
> today since you can't respond to it, but once you have CommandEvents you'll
> be able to treat a bold button just like control+b by listening for a bold
> event. We are also working on coming up with a way (currently called
> CommandQuery Event [1]) to enable browsers to determine which commands are
> available, which would help browser UI display correctly and would also
> help accessibility tools tell users what they can do. Simply removing
> browser toolbars doesn't mean there are no other ways to interact with a
> page that users expect to work- take shake-to-undo in iOS for example.
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0791.html
>
>
-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer