Re: Re: Re: [Clipboard API] The before* events
It's not only about the context menu (which could be scoped to whatever element was targeted by a right-click), it's also about the Edit menu or the inline commands in Chrome's normal application menu. Enabling the menu entries all the time breaks with existing UI conventions. But that's the point: if you do this, then a page adding a capturing listener on window or document will cause all of these things to happen up for every element on the page, because a capturing listener might affect anything. It's the same problem see if an event handler is registered-type solutions always cause. 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? (Sorry about any mangled quoting of previous messages - using a work webmail and I don't really trust its formatting..) -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: Re: [Clipboard API] The before* events
On Mon, Nov 5, 2012 at 8:49 AM, Hallvord Reiar Michaelsen Steen
hallv...@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
Re: Re: [Clipboard API] The before* events
On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: The most IMHO elegant solution is what we implemented in Opera: we simply keep relevant menu entries enabled if there are event listeners registered for the corresponding event. This sort of goes against the registering event listeners should not have side effects rule, but it's a UI effect the page can't detect so I guess it's ok. This doesn't really work when pages put their event listeners further up the tree, eg. capturing listeners on the document and other event delegation tricks, right? Why not? The UA can tell if there are copy/cut/paste listeners registered anywhere in the document. Besides, we have no way to tell whether the author's styling is implementing some faux object focus stuff, so we don't know where the user thinks the focus is. -- Hallvord R. M. Steen Core tester, Opera Software
Re: Re: [Clipboard API] The before* events
It should work just fine if you check the whole eventtarget chain (from the
target to the window object).
But that means adding a capturing listener on the window would apply this
affect
to every single element on the page. If that's an acceptable result, then
just
add the menu item all the time and forget about the event handler logic.
It's not only about the context menu (which could be scoped to whatever
element was targeted by a right-click), it's also about the Edit menu or the
inline commands in Chrome's normal application menu. Enabling the menu
entries all the time breaks with existing UI conventions. Even when using
Opera's implementation, most pages do of course not add copy/cut/paste event
listeners in the first place, so on most sites the menu is only enabled when
there is a selection, the way users expect. And integrating well with what
users expect from the native UI seems to be important for web apps. I believe
that for example Google Docxs maintains a selection in a hidden IFRAME with
editable content in order to manipulate the enabledness of copy/cut menu
entries. This is of course a horrible hack and
navigator.setCommandState('copy', true) would be much better.
--
Hallvord R. M. Steen
Core tester, Opera Software
Re: Re: [Clipboard API] The before* events
On Fri, Nov 2, 2012 at 10:45 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: It's not only about the context menu (which could be scoped to whatever element was targeted by a right-click), it's also about the Edit menu or the inline commands in Chrome's normal application menu. Enabling the menu entries all the time breaks with existing UI conventions. But that's the point: if you do this, then a page adding a capturing listener on window or document will cause all of these things to happen up for every element on the page, because a capturing listener might affect anything. It's the same problem see if an event handler is registered-type solutions always cause. -- Glenn Maynard
