On Mon, Nov 28, 2011 at 9:18 AM, Kinuko Yasuda kin...@chromium.org wrote:
On Wed, Nov 23, 2011 at 1:58 AM, Glenn Maynard gl...@zewt.org wrote:
This would lead to interop problems if it's not consistent, though. For
example, if my application creates ZIP files, and the user drags two files
Robert O'Callahan wrote:
I think we should go the route that the dialog element did in Ted's
change proposal and have a pseudo-element that gets created when an
element is fullscreened. Simple and easy, and trivial for the author
to manipulate to get most effects they could want.
On Tue, 15 Nov 2011 00:10:09 +0100, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr.
jackalm...@gmail.comwrote:
I think we should go the route that the dialog element did in Ted's
change proposal and have a pseudo-element that gets created
Hi.
Perhaps keyboard focus should be limited only to the fullscreen element or
its descendants.
If you have a canvas or video fullscreen, alt-tabbing can move the focus
outside the fullscreen element, say into form elements.
But then this would require giving focus, and dispatching
On Tue, Nov 29, 2011 at 6:25 AM, João Eiras jo...@opera.com wrote:
Hi.
Perhaps keyboard focus should be limited only to the fullscreen element or
its descendants.
If you have a canvas or video fullscreen, alt-tabbing can move the focus
outside the fullscreen element, say into form
