Re: Editing with native UI

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.

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

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.

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

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 24 June 2014 10:44:43 UTC