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
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
On 11/02/2012 12:56 AM, Glenn Maynard wrote:
On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com
mailto: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
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
On Fri, Nov 2, 2012 at 3:06 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
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
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
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.
: WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern Hoehrmann;
Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen
hallv...@opera.commailto:hallv...@opera.com wrote:
I'm looking at the beforecut, beforecopy
. M. Steen
*Cc:* WebApps WG; Ryosuke Niwa; Aryeh Gregor; Daniel Cheng; Bjoern
Hoehrmann; Sebastian Markbåge
*Subject:* Re: [Clipboard API] The before* events
** **
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen hallv...@opera.com
wrote:
I'm looking at the beforecut
; Aryeh Gregor; Daniel Cheng;
Bjoern Hoehrmann; Sebastian Markbåge
Subject: Re: [Clipboard API] The before* events
On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead
travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I
; Ryosuke Niwa; Aryeh Gregor;
Daniel Cheng; Bjoern Hoehrmann; Sebastian Markbåge
*Subject:* Re: [Clipboard API] The before* events
** **
On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
I'm looking at the beforecut, beforecopy and beforepaste
¥ge
Subject: Re: [Clipboard API] The before* events
On Thu, Nov 1, 2012 at 4:02 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I
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
On Tue, Oct 30, 2012 at 9:42 AM, Hallvord R. M. Steen hallv...@opera.comwrote:
I'm looking at the beforecut, beforecopy and beforepaste events. I don't
entirely understand their intent, it seems even more obscure than I
expected..
Nothing in the official MSDN documentation [1] really
14 matches
Mail list logo
