Re: Re: Re: [Clipboard API] The before* events

On Mon, Nov 5, 2012 at 8:49 AM, Hallvord Reiar Michaelsen Steen <
hallvord@opera.com> wrote:

>  Glenn, I think we both fully understand the way this works and fails -
> the UI quirks and why they happen. Do you have any further thoughts on the
> navigator.setCommandState() proposal? Would this be better somewhere else
> in the API (some new execCommand() argument, perhaps?)? Do you think we
> loose anything if we don't spec before* events?
>

Hallvord, that wasn't clear to me from the discussion, and I also wanted to
make sure that anyone following along understands why inspecting the event
chain like this for anything non-transparent (like optimization) has
problems.

These events do work for me in IE9.  See
https://zewt.org/~glenn/test-with-onbefore.html and
https://zewt.org/~glenn/test-without-onbefore.html.  Right-clicking the
image or the text in "with" enables cut and paste, which are greyed out in
"without".

The events are fired in Chrome, but don't appear to do anything; cut and
paste never show up in the context menu at all.

I'm not quite sure why Opera needs to know whether elements have a listener
for this event.  According to MSDN and my testing in IE9, merely attaching
a listener to these events does nothing; you have to cancel the event in
order to have any effect (eg. enabling menu items).

I don't think events are a good approach to this problem, and this only
seems to be functionally implemented in a single browser (IE), so I'd
recommend not specifying these events.

> Another problem with using before* event to control the state of
copy/cut/paste UI is that it only works for UI that is shown/hidden on
demand (like menus) and not for UI that is always present (like toolbar
buttons). I'm not aware of web browsers that have UI with copy/cut/paste
buttons by default, but some browsers are customizable and some might have
toolbar buttons for this.

It seems to work for toolbars.  It just means you'd need to fire these
events whenever focus changes, instead of only when a menu is opened.
That's ugly, but I'm not sure that it would actually cause obvious problems
(though it may cause unobvious web-compatibility ones).

However, enumerating every cuttable item on the page would mean firing an
event on every single element, which would probably cause trouble.  For
example, a possible alternative UI would be a "cut" button which then
highlights all cuttable items on screen, allowing the user to click on
which one he wants to cut, or to drag a box around a bunch of items and cut
them all.

I'm wondering if specifying something like
>
> navigator.setCommandState('copy', false); // any "copy" UI is now disabled
> until app calls setCommandState('copy', true) or user navigates away from
> page
>

This gives no way to allow clipboard operations for elements that don't
receive focus, such as allowing "cut" on an image.  It also doesn't let you
find out if a particular element wants to allow copying, other than
focusing it and waiting to see if setCommandState is called, which might
not happen synchronously.

I think the right solution is attributes; for example,

<div id=my-editable-box enable-clipboard="cut copy paste">

which enables the selected operations for the element and its children.  (I
don't know if it's useful to be able to undo this in children; that would
make it a bit more complicated.)  This allows finding out whether an
element wants clipboard operations without any scripting side-effects, and
easily enumerating cuttable elements.

I don't know if this would actually want to be its own attribute, or if
there's an existing attribute that this can be added to.  I don't think
"enable-clipboard" is actually a good name.

-- 
Glenn Maynard