Re: Editing with native UI

On Jun 24, 2014, at 3:44 AM, Robin Berjon <robin@w3.org> wrote:

> On 24/06/2014 00:38 , Ben Peters wrote:
>>> Also, if the browser includes a "bold" command by default and I
>>> don't support bolding and therefore cancel the event, the user who
>>> has been relying on the native UI is getting the worst possible
>>> experience: native controls that do nothing at all.
> >
>> This doesn't seem like an insurmountable problem. We can provide a
>> way for sites to indicate that they support certain commands and not
>> others, similar to queryCommandEnabled(), which has a return value
>> that could be modified by javascript (perhaps by an event, say
>> QueryCommandEvent). Then the browser could choose not to show buttons
>> for commands that are disabled.
> 
> Yes, this is possible, but I see problems with it.
> 
> First, it has to be white-list based. An option to just disable things would not be resilient in the face of browser vendors adding stuff.
> 
> 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.

> Third, I sense the sort of list that tends to acquire proprietary extensions over time (apple-touch-your-nose, ms-insert-clippy-wisdom, etc.) that leads developers to have to keep adding new values if they want a half-sane native UI that matches their usage (for reference, see the current favicon mess).

On the contrary, white-listing a list of editing command that an editor supports UA to disable menu items corresponding for those supported editing actions.  This is crural for not confusing end users.

> Finally, it feels an architecturally bad idea to require developers to specify the same information more than once. If my own toolbar has bold and italic, and I tell the browser that I want its native UI to expose bold and italic, then go ahead and add underlining to my toolbar I can easily forget to also tell the UA (granted, libraries can paper over that, but it becomes a tools-will-save-us situation).
> 
> Building on top of the infrastructure that HTML is providing to define menus and commands, we can get something that is:
> 
>  • White-list based;
>  • Has the exact set of commands I wish to expose;
>  • Does not lend itself to proprietary drift;
>  • Is specified once.
> 
> Note that if what HTML 5.1 is currently doing in this area isn't good enough, we can (and should) definitely improve it. Right now it's not, to the best of my knowledge, implemented broadly enough that we can't change it.

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.

- R. Niwa