Re: [clipboard] kill onbefore* events?

On Thu, Feb 4, 2016 at 1:52 PM, Hallvord Reiar Michaelsen Steen <
hsteen@mozilla.com> wrote:

> On Thu, Feb 4, 2016 at 2:43 AM, Grisha Lyukshin <glyuk@microsoft.com>
> wrote:
> >
> > Killing them doesn't sound like the right course of action. We would
> have to come up
> > with another API  so we can have an alternative to what before
> cut/copy/paste do.
>
> True, it's a use case we should handle.
>
> Options:
> * automagically enable commands if there are corresponding event
> listeners (Opera Presto model)
>   * Pros: "just works", no extra APIs, page authors don't need to
> learn nor do anything extra
>   * Cons: registering event listeners is not "supposed to" have side
> effects, W3C specs are not "supposed to" go into UX territory, web
> apps may want to sometimes leave the commands disabled after all when
> it doesn't make sense to execute them
>
> * Add a new API method like document.setCommandEnabled('paste', false)
>   * Pros: Simpler and more straightforward than the onbefore*
> event-based model, can be integrated with queryCommandEnabled(), gives
> web apps fine grained control of when to enable/disable stuff
>   * Cons: I think the editing spec people are trying to move away from
> those legacy document.* commands and may not be celebrating the
> opportunity of adding a new one.. Also, we don't really want to let
> sites disable these commands at will - we want them to *enable* them
> when it makes sense but not *disable* them when the UA would otherwise
> enable them, to prevent nuisance and "copyright protection"-style
> abuse.
>

It has been proposed to have something like this to enable/disable actions
from extra menus (clipboard actions in most cases, but safari also adds
several menus for formatting such as bold/italic/font size/font type/etc.

Without engaging in the discussion about execCommand again, in my
experience/view, the browser provided execCommand is currently unusable for
just about all editing operations (but required to operate with the
clipboard api). This seems to be the general view of all those JavaScript
developers creating editors, whereas some people working on the browser
side have a different view of this.


So based on the view of these JavaScript-people, the main usecase for being
able to disable actions is to make the extra menus go away if their editor
doesn't support a particular editing operation. First priority is really to
be able to remove all those menus. Second possibly "all menus except
clipboard". Especially on mobile devices these are a major problem
currently, as they gte in the way of things.

In the view of those who think execCommand can be used for most editing
operations, the main usecase would be to turn a particular action on or off.

 So in either case there is an argument for being able to turn them off.
However, I am not sure it is such a good idea to have to turn of for
example "paste" just to make a context menu go away.


> Are there any other options?
>
> > Why can't we fire these events regardless of content editability and do
> actual editability
> > check during the execution of the execcommands?
>
> That's the plan :) - the spec requires the browser to fire a paste
> event if the user for example presses ctrl-v regardless of whether the
> context can handle a paste or not. However, the *menu* command state
> (and thus the user's actual ability to trigger the command any other
> way than by shortcut keys) would depend on the onbefore* handling or
> some equivalent API we'd have to invent. Or the magic solution ;)
> -Hallvord R
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org