On Jun 24, 2014, at 3:44 AM, Robin Berjon <ro...@w3.org> wrote: > On 24/06/2014 00:38 , Ben Peters wrote: >>> 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. > > Yes, this is possible, but I see problems with it. > > First, it has to be white-list based. An option to just disable things would > not be resilient in the face of browser vendors adding stuff. > > Second, it doesn't address the point made below about native UI exposing a > likely non-natural subset of the commands I wish to support.
That presumes an opt-out mechanism to enable native UI. If we had used opt-in instead, then we wouldn't have this issue. > Third, I sense the sort of list that tends to acquire proprietary extensions > over time (apple-touch-your-nose, ms-insert-clippy-wisdom, etc.) that leads > developers to have to keep adding new values if they want a half-sane native > UI that matches their usage (for reference, see the current favicon mess). On the contrary, white-listing a list of editing command that an editor supports UA to disable menu items corresponding for those supported editing actions. This is crural for not confusing end users. > Finally, it feels an architecturally bad idea to require developers to > specify the same information more than once. If my own toolbar has bold and > italic, and I tell the browser that I want its native UI to expose bold and > italic, then go ahead and add underlining to my toolbar I can easily forget > to also tell the UA (granted, libraries can paper over that, but it becomes a > tools-will-save-us situation). > > Building on top of the infrastructure that HTML is providing to define menus > and commands, we can get something that is: > > • White-list based; > • Has the exact set of commands I wish to expose; > • Does not lend itself to proprietary drift; > • Is specified once. > > Note that if what HTML 5.1 is currently doing in this area isn't good enough, > we can (and should) definitely improve it. Right now it's not, to the best of > my knowledge, implemented broadly enough that we can't change it. There is a list of problems with the current editing API: Undo/redo menu doesn't get enabled/disabled in accordance with the app's intrernal undo stack. - R. Niwa
