On Jun 30, 2014, at 4:19 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > 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
allowss > 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 >
