On 06/06/2014 18:39 , Ryosuke Niwa wrote:
On Jun 6, 2014, at 4:29 AM, Piotr Koszuliński
<p.koszulin...@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
