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
