On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth w...@adambarth.com wrote:
I meant a black-box experiment (i.e., no access to browser internal state).
Put another way, can you describe a sequence of events in which the author
or the user could observe the difference? If not, then the question is
Either:
1) The frames attempt no synchronization and both just call
requestFullscreen(). In that case, the observable difference is largely
moot. It shouldn't be surprising that racing operations like this cross
origin returns a non-deterministic result. This is the position the Chrome
On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng dch...@google.com wrote:
1) The frames attempt no synchronization and both just call
requestFullscreen(). In that case, the observable difference is largely
moot. It shouldn't be surprising that racing operations like this cross
origin returns a
On Tue, Jul 29, 2014 at 5:14 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng dch...@google.com wrote:
1) The frames attempt no synchronization and both just call
requestFullscreen(). In that case, the observable difference is largely
moot. It
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote:
Given that you haven't produced a black-box experiment that
distinguishes the two approaches, different implementations can use
different approaches and be interoperable.
I guess. That still doesn't help us much defining it.
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote:
Given that you haven't produced a black-box experiment that
distinguishes the two approaches, different implementations can use
different approaches
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth w...@adambarth.com wrote:
Given that you haven't produced a black-box experiment that
distinguishes the two approaches, different implementations can use
different
There's two things the Fullscreen API does:
1. Resize the top-level browsing context's document's viewport. (I.e.
resizing the window of the browser.)
2. Change state of that document and its descendant documents.
1 needs to happen asynchronously. 2 needs to happen from a task
per-document.
Can you explain what experiment you could run to determine whether (2)
happens synchronously or asynchronously?
Adam
On Jul 28, 2014 9:03 AM, Anne van Kesteren ann...@annevk.nl wrote:
There's two things the Fullscreen API does:
1. Resize the top-level browsing context's document's viewport.
On Jul 28, 2014 10:58 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jul 28, 2014 at 7:42 PM, Adam Barth w...@adambarth.com wrote:
Can you explain what experiment you could run to determine whether (2)
happens synchronously or asynchronously?
I'm not sure I understand the question.
On Mon, Jul 28, 2014 at 9:03 AM, Anne van Kesteren ann...@annevk.nl wrote:
(How are animation frames synchronized across iframe
boundaries?)
requestAnimationFrame specifies that the callback fires for all iframes
within the same task, but it's not black-box observable between
cross-origin
What do you do when element A goes fullscreen and then element B in the
same document goes fullscreen on top of it? Do you fire a single
fullscreenchange event at B? Or do you fire a fullscreenchange event at A
and then at B? Or something else?
Rob
--
“You have heard that it was said, ‘Love your
On Tue, Jun 5, 2012 at 5:57 PM, Jer Noble jer.no...@apple.com wrote:
Actually, in WebKit, we explicitly also message the document from which
the element was removed in that case. I don't see why this behavior
couldn't be standardized.
Did you inform the spec editor(s) when you decided to
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote:
If you implemented that proposal as-is then authors would usually need a
listener on the document as well as the element, and as Chris pointed out,
it's simpler to just always listen on the document.
Is that true
On 06/05/2012 09:31 AM, Jer Noble wrote:
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan rob...@ocallahan.org wrote:
If you implemented that proposal as-is then authors would usually need a
listener on the document as well as the element, and as Chris pointed
out, it's simpler to just always
On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble jer.no...@apple.com wrote:
Actually, in WebKit, we explicitly also message the document from which the
element was removed in that case. I don't see why this behavior couldn't be
standardized.
Why should we standardize this if we always notify the
On Tue, Jun 5, 2012 at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble jer.no...@apple.com wrote:
Actually, in WebKit, we explicitly also message the document from which the
element was removed in that case. I don't see why this behavior couldn't
On Jun 5, 2012, at 1:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
Why should we standardize this if we always notify the document? Is
there a benefit to notifying both the element and the document?
I think Vincent put forward a reasonable argument. The document is a finite,
shared
On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote:
Because we exit fullscreen when the fullscreen element is removed from the
document, so if you dispatch events to the context element, the
fullscreenchange event never bubbles up to the containing document in the
On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote:
On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote:
Because we exit fullscreen when the fullscreen element is removed from
the document, so if you dispatch events to the context element, the
On Jun 4, 2012, at 10:43 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble jer.no...@apple.com wrote:
On Jun 1, 2012, at 6:45 PM, Chris Pearce cpea...@mozilla.com wrote:
Because we exit fullscreen when the fullscreen element is removed from the
I'm currently implementing Pointer Lock [1] in WebKit, which was
adjusted recently to mimic Fullscreen [2].
The Fullscreen specification calls for events to be dispatched to the
document, but the WebKit implementation dispatches fullscreenchange
and fullscreenerror events to the context element
On 2/06/2012 11:19 a.m., Vincent Scheib wrote:
IMHO Pointer Lock would be more convenient to use if events are sent
to the target element as well, and not just the document.
Is there a reason the Fullscreen specification doesn't dispatch events
to the most relevant element?
Because we exit
On Fri, 06 Apr 2012 16:51:30 +0200, Anne van Kesteren ann...@opera.com
wrote:
On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers schep...@w3.org
wrote:
What's the rationale for restricting what authors (or users) can make
fullscreen?
You cannot render arbitrary SVG elements without a root
On Mon, Apr 9, 2012 at 4:58 AM, Charles McCathieNevile cha...@opera.comwrote:
On Fri, 06 Apr 2012 16:51:30 +0200, Anne van Kesteren ann...@opera.com
wrote:
On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers schep...@w3.org
wrote:
What's the rationale for restricting what authors (or users)
Ojan wrote:
Escape usually calls cancel on dialogs, no? Seems to me that if you
have a dialog open, esc should cancel the dialog, otherwise it should
yank all fullscreened elements.
Doesn't this suffer from the same sort of security attack that requires
us to leave all fullscreened elements
On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson i...@hixie.ch wrote:
Fullscreen then defines that when you make an element fullscreen, it's
pushed onto the top layer, and when an element is unfullscreened, it's
yanked from the top layer. The user emergency escape UI yanks all
fullscreened
Hey,
The other day I was wondering whether I should change Fullscreen to not be
applicable to all elements. I was thinking HTMLElement and SVGSvgElement
(svg:svg) would probably be best. My reasoning was that it will not work
for svg:rect and such. Just now I noticed
On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers schep...@w3.org wrote:
What's the rationale for restricting what authors (or users) can make
fullscreen?
You cannot render arbitrary SVG elements without a root svg element as
far as I know.
--
Anne van Kesteren
http://annevankesteren.nl/
On Fri, 6 Apr 2012, Anne van Kesteren wrote:
The other day I was wondering whether I should change Fullscreen to not be
applicable to all elements. I was thinking HTMLElement and SVGSvgElement
(svg:svg) would probably be best. My reasoning was that it will not work for
svg:rect and such.
On Thu, 05 Apr 2012 06:53:08 +0200, Ian Hickson i...@hixie.ch wrote:
Those sound like non-modal dialogs. Do you have any examples of modal
dialogs on the Web that have these behaviours? As above, screenshots and
URLs to such examples would be really helpful.
I can see how it makes sense in the
On 5/04/12 2:53 PM, Ian Hickson wrote:
On Thu, 5 Apr 2012, Sean Hogan wrote:
So the ::backdrop could be styled to not cover the whole page?
Could it default to a top layer, but optionally be given a z-index?
The ::backdrop specifically would just be immediately below its element in
the top
On Thu, Apr 5, 2012 at 3:58 AM, Anne van Kesteren ann...@opera.com wrote:
I can see how it makes sense in the abstract. Browsers moved away from
application-global modal dialogs to tab modal dialogs. I could see Twitter
still wanting to you let you switch to @Connect or #Discover or search,
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson i...@hixie.ch wrote:
If this works, then I'll use this for dialog.
Thanks for figuring this out. I was kind of hoping this would end up in a
CSS draft, but Fullscreen works for now I guess.
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson i...@hixie.ch wrote:
If this works, then I'll use this for dialog.
How does this work for nested browsing contexts? Currently using iframe
allowfullscreen (not in HTML yet) you can fullscreen elements embedded
via an iframe. Would we then
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson i...@hixie.ch wrote:
If this works, then I'll use this for dialog.
How does this work for nested browsing contexts? Currently using iframe
allowfullscreen (not in HTML
On Wed, 04 Apr 2012 19:31:22 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren ann...@opera.com
wrote:
How does this work for nested browsing contexts? Currently using iframe
allowfullscreen (not in HTML yet) you can fullscreen elements
On Wed, Apr 4, 2012 at 10:39 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 04 Apr 2012 19:31:22 +0200, Tab Atkins Jr. jackalm...@gmail.com
wrote:
The thinking so far is that we don't do anything special for dialogs.
They don't escape their iframe, and the iframe doesn't have any
On 5/04/12 3:31 AM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesterenann...@opera.com wrote:
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hicksoni...@hixie.ch wrote:
If this works, then I'll use this fordialog.
How does this work for nested browsing contexts? Currently
On 4/04/12 9:14 AM, Ian Hickson wrote:
So based on our discussions on IRC and in person earlier today, I think
the following additions to the Fullscreen specification would provide the
necessary infrastructure to supportdialog:
- Add a new stacking layer to the CSS 2.1 Appendix E layering
On Wed, Apr 4, 2012 at 9:50 PM, Sean Hogan shogu...@westnet.com.au wrote:
Will non-modal `dialog` have a backdrop?
Dunno! We've just been thinking about modal dialogs, since they're
the hard ones.
~TJ
On Wed, Apr 4, 2012 at 8:51 PM, Sean Hogan shogu...@westnet.com.au wrote:
So the ::backdrop could be styled to not cover the whole page?
Yes. It's there for convenience only, since people often want an
element that does exactly this. If we didn't provide it explicitly,
they'd just awkwardly
On Wed, Apr 4, 2012 at 9:33 PM, Sean Hogan shogu...@westnet.com.au wrote:
On 5/04/12 2:15 PM, Tab Atkins Jr. wrote:
Both of your examples would be done by using elements that are
children of thedialog, and perhaps just positioned explicitly
somewhere.
That doesn't sound like a good solution,
On Thu, 5 Apr 2012, Sean Hogan wrote:
So the ::backdrop could be styled to not cover the whole page?
Could it default to a top layer, but optionally be given a z-index?
The ::backdrop specifically would just be immediately below its element in
the top layer stack, at least as proposed. Could
On 5/04/12 2:15 PM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 8:51 PM, Sean Hoganshogu...@westnet.com.au wrote:
So the ::backdrop could be styled to not cover the whole page?
Yes. It's there for convenience only, since people often want an
element that does exactly this. If we didn't
On 5/04/12 2:39 PM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 9:33 PM, Sean Hoganshogu...@westnet.com.au wrote:
On 5/04/12 2:15 PM, Tab Atkins Jr. wrote:
Both of your examples would be done by using elements that are
children of thedialog, and perhaps just positioned explicitly
somewhere.
So based on our discussions on IRC and in person earlier today, I think
the following additions to the Fullscreen specification would provide the
necessary infrastructure to support dialog:
- Add a new stacking layer to the CSS 2.1 Appendix E layering model,
after the current layer 10.
This seems reasonable to me.
On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote:
This layer consists of a stack of elements, which each CSS viewport
maintains. These stacks are initially empty. When the layer is painted,
the elements in the stack are rendered in the order
On Tue, Apr 3, 2012 at 5:29 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote:
This layer consists of a stack of elements, which each CSS viewport
maintains. These stacks are initially empty. When the layer is painted,
the
On Tue, 3 Apr 2012, Ojan Vafai wrote:
On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson i...@hixie.ch wrote:
Fullscreen then defines that when you make an element fullscreen, it's
pushed onto the top layer, and when an element is unfullscreened,
it's yanked from the top layer. The user
On Wed, 4 Apr 2012, Robert O'Callahan wrote:
On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote:
This layer consists of a stack of elements, which each CSS viewport
maintains. These stacks are initially empty. When the layer is
painted, the elements in the stack are
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
Another thing: I've heard from developers that it would be useful to allow
popup windows to open in fullscreen mode. For example, in Google Docs
presentations, the 'start presentation' button should open a new window in
fullscreen, so that users can use the editor in the main Chrome window and
see
Hm, why would it require stacking-level changes? One obvious way to
get it to act correctly is to make it wrap around the element, like
the old ::outside pseudo-element proposal. Then it's trivial.
The CP says The dialog and its cover, taken together, are siblings within a
new stacking
On Thu, Nov 17, 2011 at 8:20 AM, Edward O'Connor eocon...@apple.com wrote:
It seems like we shouldn't assume that these are the only two features
that will ever need this sort of rendering support. I'll get a www-style
thread going.
Thanks. If multiple specs (or even multiple running
Sorry for the late reply. Getting to and from TPAC and TPAC itself is
basically the reason. I hope you understand.
On Wed, 26 Oct 2011 04:06:28 +0200, Robert O'Callahan
rob...@ocallahan.org wrote:
When you say No longer any attempts at integrating with F11
fullscreen, do you mean to rule
I have removed background:black as the way the rendering is defined at the
moment is that it cannot be overridden unless !important is used. That's
not ideal for backgrounds. Since no color was defined that did not help
either.
I added margin:0; box-sizing:border-box so the height/width
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
Having the rest of the page visible under the fullscreen element is not
expected and I think we should default to avoiding it. background:black
seemed like the right thing for video and a reasonable default for other
On Tue, Nov 15, 2011 at 1:27 AM, Anne van Kesteren ann...@opera.com wrote:
Sorry for the late reply. Getting to and from TPAC and TPAC itself is
basically the reason. I hope you understand.
Yeah no worries mate.
About your nested-fullscreen proposal, I do not see how
To fix the nested
On Mon, Nov 14, 2011 at 12:54 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
Having the rest of the page visible under the fullscreen element is not
expected and I think we should default to avoiding it.
One problem with the existing implementation in WebKit of fullscreen is
that it is possible to focus with Tab elements that are not contained
within the fullscreened element. This is a problem for assistive devices in
particular.
Perhaps we should specify that elements outside the fullscreened
On Mon, 14 Nov 2011 21:25:38 +0100, Robert O'Callahan
rob...@ocallahan.org wrote:
On Tue, Nov 15, 2011 at 1:38 AM, Anne van Kesteren ann...@opera.com
wrote:
I have removed background:black as the way the rendering is defined at
the moment is that it cannot be overridden unless !important is
On 11/15/11 11:25 AM, Anne van Kesteren wrote:
UA does not have an important level.
In Gecko it actually does: it's a level that overrides the user
important level. Such a level is sort of needed in some cases, no
matter what you actually choose to call it.
-Boris
On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote:
One problem with the existing implementation in WebKit of fullscreen is
that it is possible to focus with Tab elements that are not contained
within the fullscreened element. This is a problem for assistive devices in
On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote:
One problem with the existing implementation in WebKit of fullscreen is
that it is possible to focus with Tab elements that are not
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 when an
element is fullscreened. Simple and easy, and trivial for the author
to
On Mon, Nov 14, 2011 at 3:10 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. jackalm...@gmail.com
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
On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
Hm, why would it require stacking-level changes? One obvious way to
get it to act correctly is to make it wrap around the element, like
the old ::outside pseudo-element proposal. Then it's trivial.
The CP says The
On Mon, Nov 14, 2011 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Hm, why would it require stacking-level changes? One obvious way to
get it to act correctly is to make it wrap around the element, like
On Tue, Nov 15, 2011 at 12:06 PM, Jeremy Apthorp jere...@chromium.orgwrote:
On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan
rob...@ocallahan.orgwrote:
On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp jere...@chromium.orgwrote:
One problem with the existing implementation in WebKit of
On Sat, 29 Oct 2011, Robert O'Callahan wrote:
On Wed, Oct 19, 2011 at 11:57 PM, James Graham jgra...@opera.com wrote:
On 10/19/2011 06:40 AM, Anne van Kesteren wrote:
Is that an acceptable limitation? Alternatively we could postpone the
nested fullscreen scenario for now (i.e. make
On Mon, Oct 31, 2011 at 2:52 PM, James Graham jgra...@opera.com wrote:
Presumably the embeded video could detect that it was already in a
fullscreen environment and deal with it accordingly.
If you exit fullscreen so you can fullscreen the video, you won't be able
to restore the original
On Tue, Nov 1, 2011 at 7:52 AM, James Graham jgra...@opera.com wrote:
On Sat, 29 Oct 2011, Robert O'Callahan wrote:
I don't think punting on nested fullscreen is a good idea. It's not some
edge case that most applications can't hit. For example, it will come up
with any content that can go
On Sat, Oct 29, 2011 at 10:47 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
I don't think punting on nested fullscreen is a good idea. It's not some
edge case that most applications can't hit. For example, it will come up
with any content that can go full-screen and can contain an embedded
On Wed, Oct 19, 2011 at 11:57 PM, James Graham jgra...@opera.com wrote:
On 10/19/2011 06:40 AM, Anne van Kesteren wrote:
Is that an acceptable limitation? Alternatively we could postpone the
nested fullscreen scenario for now (i.e. make requestFullscreen fail if
already fullscreen).
I
On Tue, Oct 25, 2011 at 12:04 AM, Anne van Kesteren ann...@opera.comwrote:
On Tue, 25 Oct 2011 00:32:43 +0900, Glenn Maynard gl...@zewt.org wrote:
Doing this synchronously means nobody can ever implement ask-first. Don't
permanently lock everyone into a permission scheme with known problems.
Thanks for working on this.
When you say No longer any attempts at integrating with F11 fullscreen,
do you mean to rule out the possibility that UAs do that? E.g., would you
allow UAs to have UI that makes the current document fullscreen and sets the
fullscreen element to the root element?
I'm
On Fri, 21 Oct 2011 06:44:05 +0900, Chris Pearce cpea...@mozilla.com
wrote:
On 21/10/2011 4:10 a.m., Glenn Maynard wrote:
The current spec doesn't seem to allow asking permission to fullscreen
in advance, since the fullscreen element is set synchronously. This
should be supported; there
Hi.
The requestFullscreen steps tells to dispatch a fullscreenchange event on
the context object, and all containing objects (frames).
First, there should be a better clarification of 'context object'. While
is remarked that it is the object used for the last requestFullScreen call
On Mon, Oct 24, 2011 at 6:38 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 21 Oct 2011 06:44:05 +0900, Chris Pearce cpea...@mozilla.com
wrote:
On 21/10/2011 4:10 a.m., Glenn Maynard wrote:
The current spec doesn't seem to allow asking permission to fullscreen in
advance, since the
On Mon, 24 Oct 2011 20:42:18 +0900, João Eiras jo...@opera.com wrote:
The requestFullscreen steps tells to dispatch a fullscreenchange event
on the context object, and all containing objects (frames).
Actually, it says on the context object and all ancestor browsing
context's documents. We
On Tue, 25 Oct 2011 00:32:43 +0900, Glenn Maynard gl...@zewt.org wrote:
Doing this synchronously means nobody can ever implement ask-first.
Don't permanently lock everyone into a permission scheme with known
problems.
Since the events are not dispatched synchronously I think we should
I revised the specification based on the comments thus far:
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
I made the following changes:
* The root element is no longer a special case
* No longer any attempts at integrating with F11 fullscreen
* requestFullscreen() can no longer
2011-10-19 17:45 EEST: Glenn Maynard:
b.onclick = function(e) {
if(document.fullscreen)
document.exitFullscreen();
else
gameDiv.enterFullScreen();
}
In fact, the most obvious code should be
b.onclick = function(e) {
if(gameDiv.fullscreen)
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense, but it
doesn't seem right in general.
Should margin: 0; padding: 0; be set by :fullscreen?
On Thu, 20 Oct 2011 17:10:03 +0200, Glenn Maynard gl...@zewt.org wrote:
The background: black makes a basic case strange: fullscreening
divhello/div will result in black text on a black background. Maybe
having that on video:fullscreen and maybe img:fullscreen makes sense,
but it
doesn't
On 21/10/2011 4:10 a.m., Glenn Maynard wrote:
The current spec doesn't seem to allow asking permission to fullscreen in
advance, since the fullscreen element is set synchronously. This should be
supported; there are a lot of potential problems with the ask-after model
and it shouldn't be the
On Tue, Oct 18, 2011 at 9:40 PM, Anne van Kesteren ann...@opera.com wrote:
1) How much should UI-based and API-based fullscreen interact? To me it
seems nice if pressing F11 would also give you fullscreenchange events and
that Document.fullscreen would yield true. Why would you not want to
2) Chris brought forward the case of nesting. You have a fullscreen
presentation (lets assume API-based activated for now) and in that
presentation there's some video that the presenter wants to display
fullscreen (lets assume the video player is a custom widget with
API-based
fullscreen
Hi.
The spec tells that fullscreenchanged is dispatched for API initiated
fullscreen.
It should too specify that fullscreenchanged should be dispatched for
fullscreen toggled by the user like pressing F11 ou double clicking
a video element.
Thanks.
On 10/19/2011 06:40 AM, Anne van Kesteren wrote:
Is that an acceptable limitation? Alternatively we could postpone the
nested fullscreen scenario for now (i.e. make requestFullscreen fail if
already fullscreen).
I think punting on this makes sense. Pages can detect the failure and do
On Wed, Oct 19, 2011 at 12:40 AM, Anne van Kesteren ann...@opera.comwrote:
1) How much should UI-based and API-based fullscreen interact? To me it
seems nice if pressing F11 would also give you fullscreenchange events and
that Document.fullscreen would yield true. Why would you not want to
On Wed, 19 Oct 2011 16:45:34 +0200, Glenn Maynard gl...@zewt.org wrote:
On Wed, Oct 19, 2011 at 12:40 AM, Anne van Kesteren
ann...@opera.comwrote:
1) How much should UI-based and API-based fullscreen interact? To me it
seems nice if pressing F11 would also give you fullscreenchange events
On Wed, Oct 19, 2011 at 11:00 AM, João Eiras jo...@opera.com wrote:
I think you just solved your own issue :) Your if check is wrong given your
use case.
No, that's missing the point. These obscure corner cases should be
minimized (in any API, and especially web APIs). People won't know to
On Wed, 19 Oct 2011 17:31:40 +0200, Glenn Maynard gl...@zewt.org wrote:
On Wed, Oct 19, 2011 at 11:00 AM, João Eiras jo...@opera.com wrote:
I think you just solved your own issue :) Your if check is wrong given
your
use case.
No, that's missing the point. These obscure corner cases
On Wed, Oct 19, 2011 at 11:49 AM, João Eiras jo...@opera.com wrote:
F11 and document.requestFullscreen() should produce exactly the same
results, so, document.fullscreen would be enabled. And there's no reason not
to (and otherwise would make the spec needlessly more complex).
There's no
On Wed, 19 Oct 2011 17:15:11 +0100, Glenn Maynard gl...@zewt.org wrote:
On Wed, Oct 19, 2011 at 11:49 AM, João Eiras jo...@opera.com wrote:
F11 and document.requestFullscreen() should produce exactly the same
results, so, document.fullscreen would be enabled. And there's no
reason not
to
1 - 100 of 183 matches
Mail list logo
