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

> From: Robin Berjon [mailto:robin@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.

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.

> 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.

Good point.

> 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 22:39:16 UTC