Editing with native UI (was: [editing] CommandQuery Object and Event)

On 06/06/2014 18:39 , Ryosuke Niwa 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.

All of these are good points, but the fact remains that if a browser 
unilaterally decides to exposes a new editing behaviour that I as author 
don't know about, it could very easily break my script.

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.

Conversely, if I support something that the native UI does not expose 
(say, superscripting) it makes for a weird UI in which some things are 
exposed and others aren't.

There is an option that:

   • Can be styled in the page according to author wishes.
   • Can interact with native controls.
   • Can integrate with accessibility.

It relies on using all bits of new stuff in HTML: commands, contextMenu, 
and friends. I would *strongly* suggest that contentEditable=minimal 
would *only* have native UI based on things specified with this and not 
anything else by default. Native UI atop custom editing is really a 
solution for breakage.

We can also make it smart and able to tap into higher-level intention 
events such as knowing the platform's localised shortcut for a given action.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 23 June 2014 16:16:03 UTC