> From: Robin Berjon [mailto:ro...@w3.org]
>
> On 06/06/2014 18:39 , Ryosuke Niwa wrote:
> > On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński
> > 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
