On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren wrote:
> On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth 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.
>
On Tue, Jul 29, 2014 at 8:46 AM, Anne van Kesteren wrote:
> On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth 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
On Tue, Jul 29, 2014 at 5:29 PM, Adam Barth 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. However, I'm no
On Tue, Jul 29, 2014 at 5:14 AM, Anne van Kesteren wrote:
> On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng 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 racin
On Tue, Jul 29, 2014 at 9:51 AM, Daniel Cheng 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 non-deterministi
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
out-of-proc
On Mon, Jul 28, 2014 at 8:16 PM, Adam Barth 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
> moot.
Well if b
On Mon, Jul 28, 2014 at 9:03 AM, Anne van Kesteren wrote:
> (How are animation frames synchronized across
> boundaries?)
>
requestAnimationFrame specifies that the callback fires for all iframes
within the same task, but it's not black-box observable between
cross-origin iframes so it doesn't m
On Jul 28, 2014 10:58 AM, "Anne van Kesteren" wrote:
>
> On Mon, Jul 28, 2014 at 7:42 PM, Adam Barth 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.
>
> Do you mean if you ca
Caveat: I'm not really familiar with the fullscreen API implementation in
Chrome.
I imagine the synchronous checks would be implemented with a sync IPC from
the requesting renderer to the browser (which implies the browser process
must keep track of the fullscreen enabled flag and whether or not t
On Mon, Jul 28, 2014 at 7:42 PM, Adam Barth 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.
Do you mean if you can observe that the tasks in different documents
might run at the sam
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" wrote:
> There's two things the Fullscreen API does:
>
> 1. Resize the top-level browsing context's document's viewport. (I.e.
> resi
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. Poten
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 Jun 5, 2012, at 1:06 AM, Anne van Kesteren 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 resource. Requiring
On Tue, Jun 5, 2012 at 1:06 AM, Anne van Kesteren wrote:
> On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble 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 sh
On Mon, Jun 4, 2012 at 11:13 PM, Jer Noble 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 document? Is
ther
On 06/05/2012 09:31 AM, Jer Noble wrote:
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan 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 documen
On Jun 4, 2012, at 11:23 PM, Robert O'Callahan 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 for the Webkit i
On Tue, Jun 5, 2012 at 5:57 PM, Jer Noble 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 make this c
On Jun 4, 2012, at 10:43 PM, Robert O'Callahan wrote:
> On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble wrote:
> On Jun 1, 2012, at 6:45 PM, Chris Pearce wrote:
>
> > Because we exit fullscreen when the fullscreen element is removed from the
> > document, so if you dispatch events to the context e
On Tue, Jun 5, 2012 at 9:13 AM, Jer Noble wrote:
> On Jun 1, 2012, at 6:45 PM, Chris Pearce 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
On Jun 1, 2012, at 6:45 PM, Chris Pearce 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
> exit-on-remove case.
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 ful
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 (a
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 Mon, Apr 9, 2012 at 4:58 AM, Charles McCathieNevile wrote:
> On Fri, 06 Apr 2012 16:51:30 +0200, Anne van Kesteren
> wrote:
>
> On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers
>> wrote:
>>
>>> What's the rationale for restricting what authors (or users) can make
>>> fullscreen?
>>>
>>
>> Y
On Fri, 06 Apr 2012 16:51:30 +0200, Anne van Kesteren
wrote:
On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers
wrote:
What's the rationale for restricting what authors (or users) can make
fullscreen?
You cannot render arbitrary SVG elements without a root element as
far as I know.
On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson 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 elements fr
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
> () would probably be best. My reasoning was that it will not work for
> and such.
There's plent
On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers wrote:
What's the rationale for restricting what authors (or users) can make
fullscreen?
You cannot render arbitrary SVG elements without a root element as
far as I know.
--
Anne van Kesteren
http://annevankesteren.nl/
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
() would probably be best. My reasoning was that it will not work
for and such. Just now I noticed
https://bugzilla.mozilla.org/show_bu
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson wrote:
If this works, then I'll use this for .
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.
http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
Looking for
On Thu, Apr 5, 2012 at 3:58 AM, Anne van Kesteren 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,
> while a modal
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 l
On Thu, 05 Apr 2012 06:53:08 +0200, Ian Hickson 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 abstract. Bro
On 5/04/12 2:15 PM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 8:51 PM, Sean Hogan 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
On 5/04/12 2:39 PM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 9:33 PM, Sean Hogan 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 the, and perhaps just positioned explicitly
somewhere.
That doesn't sound like a goo
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.
On Wed, Apr 4, 2012 at 9:33 PM, Sean Hogan 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 the, and perhaps just positioned explicitly
>> somewhere.
>
> That doesn't sound like a good solution, but maybe I'm misund
On Wed, Apr 4, 2012 at 8:51 PM, Sean Hogan 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 wrap their s in a backgro
On Wed, Apr 4, 2012 at 9:50 PM, Sean Hogan wrote:
> Will non-modal `` have a backdrop?
Dunno! We've just been thinking about modal dialogs, since they're
the hard ones.
~TJ
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 support:
- Add a new stacking layer to the CSS 2.1 Appendix E layering model,
af
On 5/04/12 3:31 AM, Tab Atkins Jr. wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren wrote:
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson wrote:
If this works, then I'll use this for.
How does this work for nested browsing contexts? Currently using (not in HTML yet) you can fullscr
On Wed, Apr 4, 2012 at 10:39 AM, Anne van Kesteren wrote:
> On Wed, 04 Apr 2012 19:31:22 +0200, Tab Atkins Jr.
> wrote:
>> The thinking so far is that we don't do anything special for dialogs.
>> They don't escape their , and the doesn't have any
>> special response to a dialog spawning within i
On Wed, 04 Apr 2012 19:31:22 +0200, Tab Atkins Jr.
wrote:
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren
wrote:
How does this work for nested browsing contexts? Currently using allowfullscreen> (not in HTML yet) you can fullscreen elements embedded
via an . Would we then have to push th
On Wed, Apr 4, 2012 at 1:05 AM, Anne van Kesteren wrote:
> On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson wrote:
>>
>> If this works, then I'll use this for .
>
> How does this work for nested browsing contexts? Currently using allowfullscreen> (not in HTML yet) you can fullscreen elements embe
On Wed, 04 Apr 2012 01:14:43 +0200, Ian Hickson wrote:
If this works, then I'll use this for .
How does this work for nested browsing contexts? Currently using allowfullscreen> (not in HTML yet) you can fullscreen elements embedded
via an . Would we then have to push the element on the
st
On Wed, 4 Apr 2012, Robert O'Callahan wrote:
> On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson 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 i
On Tue, 3 Apr 2012, Ojan Vafai wrote:
> On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson 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 "emerg
On Tue, Apr 3, 2012 at 5:29 PM, Robert O'Callahan wrote:
> On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson 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 rend
This seems reasonable to me.
On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson 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 that they were
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 :
- Add a new stacking layer to the CSS 2.1 Appendix E layering model,
after the current layer 10. Let's call
On Tue, Nov 29, 2011 at 6:25 AM, João Eiras 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 elements.
>
> B
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 focus
On Tue, 15 Nov 2011 00:10:09 +0100, Robert O'Callahan
wrote:
On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr.
wrote:
I think we should go the route that the element did in Ted's
change proposal and have a pseudo-element that gets created when an
element is fullscreened. Simple and easy,
Robert O'Callahan wrote:
>> I think we should go the route that the 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.
>
> Intere
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
On Thu, Nov 17, 2011 at 8:20 AM, Edward O'Connor 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 instances of the same
>>> 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
>
On Tue, Nov 15, 2011 at 12:06 PM, Jeremy Apthorp wrote:
> On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan
> wrote:
>
>> On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp wrote:
>>
>>> One problem with the existing implementation in WebKit of fullscreen is
>>> that it is possible to focus with T
On Mon, Nov 14, 2011 at 3:46 PM, Robert O'Callahan wrote:
> On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr.
> 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
>> the old ::outside pseudo-elemen
On Tue, Nov 15, 2011 at 12:38 PM, Tab Atkins Jr. 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
> the old ::outside pseudo-element proposal. Then it's trivial.
>
The CP says "The dialog and its
On Mon, Nov 14, 2011 at 3:10 PM, Robert O'Callahan wrote:
> On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr.
> wrote:
>>
>> I think we should go the route that the element did in Ted's
>> change proposal and have a pseudo-element that gets created when an
>> element is fullscreened. Simple and
On Tue, Nov 15, 2011 at 10:54 AM, Tab Atkins Jr. wrote:
> I think we should go the route that the 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
On Tue, Nov 15, 2011 at 9:59 AM, Robert O'Callahan wrote:
> On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp wrote:
>
>> 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 eleme
On Tue, Nov 15, 2011 at 11:22 AM, Jeremy Apthorp wrote:
> 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.
>
>
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 Mon, 14 Nov 2011 21:25:38 +0100, Robert O'Callahan
wrote:
On Tue, Nov 15, 2011 at 1:38 AM, Anne van Kesteren
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 used.
That's
not ideal for backgro
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 sub
On Mon, Nov 14, 2011 at 12:54 PM, Robert O'Callahan
wrote:
> On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan
> wrote:
>
>> 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
On Tue, Nov 15, 2011 at 9:25 AM, Robert O'Callahan wrote:
> 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
> kinds of elemen
On Tue, Nov 15, 2011 at 1:27 AM, Anne van Kesteren 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 cases, I suggest
On Tue, Nov 15, 2011 at 1:38 AM, Anne van Kesteren 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 used. That's
> not ideal for backgrounds.
Can you elaborate on this?
> Since no color was define
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 dec
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
wrote:
When you say "No longer any attempts at integrating with "F11
fullscreen"", do you mean to rule out the possibilit
On Sat, Oct 29, 2011 at 10:47 PM, 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 full-screen and can contain an embedded
> Youtube video. (
On Tue, Nov 1, 2011 at 7:52 AM, James Graham 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 full-screen
On Mon, Oct 31, 2011 at 2:52 PM, James Graham 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 fullscreen element w
On Sat, 29 Oct 2011, Robert O'Callahan wrote:
On Wed, Oct 19, 2011 at 11:57 PM, James Graham 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
On Wed, Oct 19, 2011 at 11:57 PM, James Graham 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 think pun
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'
On Tue, Oct 25, 2011 at 12:04 AM, Anne van Kesteren wrote:
> On Tue, 25 Oct 2011 00:32:43 +0900, Glenn Maynard 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
On Tue, 25 Oct 2011 00:32:43 +0900, Glenn Maynard 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 always
be able to
On Mon, 24 Oct 2011 20:42:18 +0900, João Eiras 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 could change it
On Mon, Oct 24, 2011 at 6:38 AM, Anne van Kesteren wrote:
> On Fri, 21 Oct 2011 06:44:05 +0900, Chris Pearce
> 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 s
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
which
On Fri, 21 Oct 2011 06:44:05 +0900, Chris Pearce
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 are a lot of potential
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 onl
On Thu, 20 Oct 2011 17:10:03 +0200, Glenn Maynard wrote:
The background: black makes a basic case strange: fullscreening
hello 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.
The background: black makes a basic case strange: fullscreening
hello 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?
The curren
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)
gameDiv.ex
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 longe
On Thu, 20 Oct 2011 10:20:57 +0900, Chris Pearce
wrote:
On 19/10/2011 5:40 p.m., Anne van Kesteren 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
On 19/10/2011 5:40 p.m., Anne van Kesteren 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.
These modes cover different cases. F11 fullscreen mod
On Wed, Oct 19, 2011 at 5:21 PM, João Eiras wrote:
> I don't understand how that is an issue. It has been mentioned that
> navigating a document which has a fullscreen element would exit fullscreen,
> but not a document.
>
If you're saying that fullscreen won't be exited on navigation when
docum
On Thu, Oct 20, 2011 at 8:21 AM, João Eiras wrote:
> On Wed, 19 Oct 2011 17:15:11 +0100, Glenn Maynard wrote:
>
> On Wed, Oct 19, 2011 at 11:49 AM, João Eiras wrote:
>>
>> F11 and document.requestFullscreen() should produce exactly the same
>>> results, so, document.fullscreen would be enable
On Wed, 19 Oct 2011 17:15:11 +0100, Glenn Maynard wrote:
On Wed, Oct 19, 2011 at 11:49 AM, João Eiras 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 s
On Wed, Oct 19, 2011 at 11:49 AM, João Eiras 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 such thing as "
On Wed, 19 Oct 2011 17:31:40 +0200, Glenn Maynard wrote:
On Wed, Oct 19, 2011 at 11:00 AM, João Eiras 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, a
1 - 100 of 197 matches
Mail list logo
