Re: [editing] CommandQuery Object and Event

On Jun 9, 2014, at 4:21 PM, Piotr Koszuliński <p.koszulinski@cksource.com> wrote:

> 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

I think you're presuming that we're going to keep all the features enabled by default, and let authors disable them later.  That would indeed cause a problem for editors such as code editor or semantic editor that need to have a more fine control over what goes into the editor.

On the other hand, features such as smart quotes, autocorrections, spellchecking are platform-wide features (on OS X and iOS).  Not having such features inside an editable region in a browser would only confuse users.  So editors that don't need to have full control over the content should be able to get these features for free, and editors that need more granular control should be able to opt-in.

For the latter case, we could come up with a set of categories for common editing features new platforms and browsers tend to introduce/support, and provide an API for each category of editing operations so that authors could intercept them as needed (e.g. a pair of replacement events for smart quotes) without having to explicitly support each and every platform-specific editing feature.

- R. Niwa

Received on Tuesday, 1 July 2014 00:04:18 UTC