W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

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

From: Robin Berjon <robin@w3.org>
Date: Mon, 23 Jun 2014 18:15:53 +0200
Message-ID: <53A852B9.6030407@w3.org>
To: Ryosuke Niwa <rniwa@apple.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>, public-editing-tf@w3.org
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:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:25 UTC