Re: [whatwg] api for fullscreen()

On Feb 4, 2010, at 16:53 , Kit Grose wrote: > I also develop kiosk and medical applications where fullscreen is not only > desirable but necessary behaviour. Crippling the API such that the developer > cannot determine whether or not the user permitted their application to run > fullscreen is u

Re: [whatwg] api for fullscreen()

On 05/02/2010, at 8:08 AM, David Singer wrote: > On Feb 3, 2010, at 15:03 , Kit Grose wrote: >> I feel that the user shouldn't have the ability to enter into some sort of >> "pseudo-fullscreen". If the content needs to be displayed full-screen, > > I don't believe that there is any such 'need' an

Re: [whatwg] api for fullscreen()

On Feb 3, 2010, at 15:03 , Kit Grose wrote: > I feel that the user shouldn't have the ability to enter into some sort of > "pseudo-fullscreen". If the content needs to be displayed full-screen, I don't believe that there is any such 'need' and that the user should own that decision. I, for exa

Re: [whatwg] api for fullscreen()

On Feb 3, 2010, at 7:19 PM, Smylers wrote: > Brian Campbell writes: > >>> As I understand it, the risk with full-screen view is that a >>> malicous site may spoof browser chrome, such as the URL bar, thereby >>> tricking a user who isn't aware the site is full-screen. >> >> This is addressing a

Re: [whatwg] api for fullscreen()

Brian Campbell writes: > > As I understand it, the risk with full-screen view is that a > > malicous site may spoof browser chrome, such as the URL bar, thereby > > tricking a user who isn't aware the site is full-screen. > > This is addressing a different scenario; not malicious sites per-se, >

Re: [whatwg] api for fullscreen()

> Another scenario applies to most video player sites. Almost all video player > sites using Flash have a full screen button. Many of them do not have a full > window button, however. If a user wishes to view content scaled up to fill > the window, without the distractions of navigational links,

Re: [whatwg] api for fullscreen()

On Feb 3, 2010, at 5:04 AM, Smylers wrote: > Brian Campbell writes: > >> I'm a bit concerned about when the fullscreen events and styles apply, >> though. If the page can tell whether or not the user has actually >> allowed it to enter fullscreen mode, it can refuse to display content >> until th

Re: [whatwg] api for fullscreen()

Brian Campbell writes: > I'm a bit concerned about when the fullscreen events and styles apply, > though. If the page can tell whether or not the user has actually > allowed it to enter fullscreen mode, it can refuse to display content > until the user gives it permission to enter fullscreen mode.

Re: [whatwg] api for fullscreen()

On Mon, Feb 1, 2010 at 4:41 PM, Brian Campbell wrote: > This could lead to the problem that Hixie mentions, of training users to > click through security dialogs, even if this is done through a drop-down > asynchronous notification instead of a modal dialog. I'd hope that browsers don't go with

Re: [whatwg] api for fullscreen()

On Feb 1, 2010, at 5:38 PM, Robert O'Callahan wrote: > On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell > wrote: > I'm a bit concerned about when the fullscreen events and styles apply, > though. If the page can tell whether or not the user has actually allowed it > to enter fullscreen mode, i

Re: [whatwg] api for fullscreen()

On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell wrote: > I'm a bit concerned about when the fullscreen events and styles apply, > though. If the page can tell whether or not the user has actually allowed it > to enter fullscreen mode, it can refuse to display content until the user > gives it perm

Re: [whatwg] api for fullscreen() - security issues

On Tue, Feb 2, 2010 at 5:00 AM, Simon Fraser wrote: > On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote: > > > On Jan 31, 2010, at 05:08, Simon Fraser wrote: > > > >> * disallow enterFullscreen() from a frame or iframe > > > > This might be a problem if video sites transition their embedding > boil

Re: [whatwg] api for fullscreen()

On Jan 28, 2010, at 9:42 PM, Robert O'Callahan wrote: > enterFullscreen always returns immediately. If fullscreen mode is currently > supported and permitted, enterFullscreen dispatches a task that a) imposes > the fullscreen style, b) fires the beginfullscreen event on the element and > c) act

Re: [whatwg] api for fullscreen()

On Mon, Feb 1, 2010 at 11:05 AM, Robert O'Callahan wrote: > On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell wrote: >> >> When you say that the DOM viewport of the element is aligned with the >> screen when it goes fullscreen, does that mean that the .width and >> .height properties are changed? O

Re: [whatwg] api for fullscreen()

On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell wrote: > When you say that the DOM viewport of the element is aligned with the > screen when it goes fullscreen, does that mean that the .width and > .height properties are changed? Or does it mean that the element's > size is changed by a CSS style

Re: [whatwg] api for fullscreen()

On Thu, Jan 28, 2010 at 8:55 PM, Robert O'Callahan wrote: > On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns > wrote: >>> >>> enterFullscreen always returns immediately. If fullscreen mode is >>> currently supported and permitted, enterFullscreen dispatches a task that a) >>> imposes the fullscreen

Re: [whatwg] api for fullscreen()

> > > The enableKeys parameter to enterFullscreen is a hint to the UA that the >>> application would like to be able to receive arbitrary keyboard input. >>> Otherwise the UA is likely to disable alphanumeric keyboard input. If >>> enableKeys is specified, the UA might require more severe confirmat

Re: [whatwg] api for fullscreen() - security issues

On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote: > On Jan 31, 2010, at 05:08, Simon Fraser wrote: > >> * disallow enterFullscreen() from a frame or iframe > > This might be a problem if video sites transition their embedding boilerplate > to an iframe in order to be able to be able to serve HTM

Re: [whatwg] api for fullscreen() - security issues

On Jan 31, 2010, at 05:08, Simon Fraser wrote: > * disallow enterFullscreen() from a frame or iframe This might be a problem if video sites transition their embedding boilerplate to an iframe in order to be able to be able to serve HTML5, Flash, ActiveX, etc. depending on UA without requiring t

Re: [whatwg] api for fullscreen() - security issues

On 1/31/10 6:38 AM, Tab Atkins Jr. wrote: This one seems kind of weird. Does the spec currently distinguish significantly between a user-initiated click and a script-initiated one? DOM 3 Events draft does have the concept of trusted events; UA/user generated events are trusted, script generat

Re: [whatwg] api for fullscreen()

On Sun, 31 Jan 2010 03:43:49 +0100, Simon Fraser wrote: On Jan 30, 2010, at 1:24 PM, Anne van Kesteren wrote: To stop polluting the Window object, might it make sense to put the new members (other than event handler attributes) on window.screen? This would require that the current window obj

Re: [whatwg] api for fullscreen() - security issues

On 1/30/10 11:38 PM, Tab Atkins Jr. wrote: On Sat, Jan 30, 2010 at 9:08 PM, Simon Fraser wrote: * require that enterFullscreen() is being called inside a user-event handler (e.g. click or keypress) to avoid drive-by fullscreen annoyances. This one seems kind of weird. Does the spec currently

Re: [whatwg] api for fullscreen() - security issues

On Sat, Jan 30, 2010 at 9:08 PM, Simon Fraser wrote: > * require that enterFullscreen() is being called inside a user-event handler > (e.g. click or keypress) to avoid drive-by fullscreen annoyances. This one seems kind of weird. Does the spec currently distinguish significantly between a user-i

Re: [whatwg] api for fullscreen() - security issues

On Jan 28, 2010, at 6:42 pm, Robert O'Callahan wrote: > On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser wrote: > We have been discussing a more general fullscreen API that lets you take the > page fullscreen (perhaps with the ability to focus on a single element), as > Maciej mentions. We have n

Re: [whatwg] api for fullscreen()

On Jan 30, 2010, at 1:24 PM, Anne van Kesteren wrote: > On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser wrote: >> On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote: >>> So how about a Window API with an optional element component: >>> void enterFullscreen(optional DOMElement element, optional

Re: [whatwg] api for fullscreen()

On Fri, Jan 29, 2010 at 11:54 PM, Robert O'Callahan wrote: > While a window is > fullscreen, the root element and the designated fullscreen element, if any, > are given a pseudoclass "fullscreen". Then you can have some default rules > in the UA style sheet: > *:root:fullscreen { overflow:hidden;

Re: [whatwg] api for fullscreen()

On Thu, Jan 28, 2010 at 6:42 PM, Robert O'Callahan wrote: > On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser wrote: > >> We have been discussing a more general fullscreen API that lets you take >> the page fullscreen (perhaps with the ability to focus on a single element), >> as Maciej mentions. We

Re: [whatwg] api for fullscreen()

On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser wrote: On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote: So how about a Window API with an optional element component: void enterFullscreen(optional DOMElement element, optional boolean enableKeys); void exitFullscreen(); boolean attribute

Re: [whatwg] api for fullscreen()

On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote: > So how about a Window API with an optional element component: > void enterFullscreen(optional DOMElement element, optional boolean > enableKeys); > void exitFullscreen(); > boolean attribute supportsFullscreen; > boolean attribute displaying

Re: [whatwg] api for fullscreen()

On Sat, Jan 30, 2010 at 5:49 AM, Simon Fraser wrote: > On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote: > > 1) Should be convenient for authors to make any element in a page display > fullscreen > 2) Should support in-page activation UI for discoverability > > > I agree with Boris that we sh

Re: [whatwg] api for fullscreen()

>> While an element is fullscreen, the UA imposes CSS style >> "position:fixed; left:0; top:0; right:0; bottom:0" on the element and >> aligns the viewport of its DOM window with the screen. Only the >> element and its children are rendered, as a single CSS stacking context. > > So this makes it a

Re: [whatwg] api for fullscreen()

On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote: > On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser wrote: > We have been discussing a more general fullscreen API that lets you take the > page fullscreen (perhaps with the ability to focus on a single element), as > Maciej mentions. We have n

Re: [whatwg] api for fullscreen()

On 1/28/10 10:41 PM, Kit Grose wrote: True, but surely saying "any element" opens the door to full-screening inline text elements (e.g elements). I don't see why this is a problem, offhand. I suppose the native style being "position: fixed" would put those elements in a block formatting co

Re: [whatwg] api for fullscreen()

On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns wrote: > enterFullscreen always returns immediately. If fullscreen mode is currently >> supported and permitted, enterFullscreen dispatches a task that a) imposes >> the fullscreen style, b) fires the beginfullscreen event on the element and >> c) act

Re: [whatwg] api for fullscreen()

On Thu, 28 Jan 2010, Geoff Stearns wrote: > > I think it would suffice to simply show a dialog the first time a user > wants to go fullscreen within a domain with an option to "remember this > choice for this domain." Users click through dialogs without looking, so that wouldn't work. -- Ian H

Re: [whatwg] api for fullscreen()

On Fri, Jan 29, 2010 at 4:06 PM, Kit Grose wrote: > Regarding point 1, surely any fullscreen API should only support > block-level elements? > I don't see why. Setting position:fixed does what you want in the cases I can think of. If I'm reading point 2 correctly, I disagree with it (except in

Re: [whatwg] api for fullscreen()

> > enterFullscreen always returns immediately. If fullscreen mode is currently > supported and permitted, enterFullscreen dispatches a task that a) imposes > the fullscreen style, b) fires the beginfullscreen event on the element and > c) actually initiates fullscreen display of the element. The U

Re: [whatwg] api for fullscreen()

> Block-level in what sense? is not block-level in any sense; One > could argue that and are "block-level" in HTML terms, > but it's context-dependent (they can contain blocks if their parent > can). None of these are block-level in the CSS sense, by default. True, but surely saying "any e

Re: [whatwg] api for fullscreen()

On 1/28/10 10:06 PM, Kit Grose wrote: 1) Should be convenient for authors to make any element in a page display fullscreen 2) Should support in-page activation UI for discoverability 3) Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors p

Re: [whatwg] api for fullscreen()

> 1) Should be convenient for authors to make any element in a page display > fullscreen > 2) Should support in-page activation UI for discoverability > 3) Should support changing the layout of the element when you enter/exit > fullscreen mode. For example, authors probably want some controls to

Re: [whatwg] api for fullscreen()

On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser wrote: > We have been discussing a more general fullscreen API that lets you take > the page fullscreen (perhaps with the ability to focus on a single element), > as Maciej mentions. We have not decided on a final form for this API, nor > have we res

Re: [whatwg] api for fullscreen()

On Jan 28, 2010, at 3:38 PM, Robert O'Callahan wrote: > On Thu, Jan 28, 2010 at 8:34 PM, Henri Sivonen wrote: > I haven't seen a proposal, but it looks like code has landed: > http://trac.webkit.org/changeset/50893 > > Demo: http://jilion.com/sublime/video > (option-click the full screen button

Re: [whatwg] api for fullscreen()

On Thu, Jan 28, 2010 at 8:34 PM, Henri Sivonen wrote: > I haven't seen a proposal, but it looks like code has landed: > http://trac.webkit.org/changeset/50893 > > Demo: http://jilion.com/sublime/video > (option-click the full > screen button in

Re: [whatwg] api for fullscreen()

On Jan 28, 2010, at 04:38, Robert O'Callahan wrote: > 2009/12/17 Maciej Stachowiak >> 1) It handles some very common use cases (including likely one of the *most* >> common, video) in a way that's much simpler for the content author. >> 2) The browser will have the option to animate the transiti

Re: [whatwg] api for fullscreen()

2009/12/17 Maciej Stachowiak > 1) It handles some very common use cases (including likely one of the > *most* common, video) in a way that's much simpler for the content author. > 2) The browser will have the option to animate the transition to fullscreen > starting from the target element, in a

Re: [whatwg] api for fullscreen()

On Dec 17, 2009, at 1:52 AM, Simon Pieters wrote: On Thu, 17 Dec 2009 10:30:26 +0100, Maciej Stachowiak wrote: Some of us at Apple have discussed fullscreen APIs, and we think a user gesture requirement plus clear indication of what has happened is likely sufficient. As to the API i

Re: [whatwg] api for fullscreen()

2009/12/16 Jonas Sicking : > 2009/12/16 Ian Fette (イアンフェッティ) : >> I think what I've heard from application developers over and over again is >> that, while the UA may provide some way to go into full screen from in the >> browser chrome, it is much more discoverable when that capability exists >> f

Re: [whatwg] api for fullscreen()

I love the idea of fullscreen() and on* events for developers and letting the browsers come up with smart ways to do as much as they can to protect users (as they have done countless times before with popups, phishing, etc). We can't say no to every feature because "some poor user may click on som

Re: [whatwg] api for fullscreen()

2009/12/17 Jonas Sicking : > I guess that if you enforced that fullscreen could only happen in > response to a click then you are in better shape. Browsers already have heuristics just like this for opening popup windows, don't they? They seem to work pretty well to prevent pages from being too a

Re: [whatwg] api for fullscreen()

On Thu, 17 Dec 2009 10:30:26 +0100, Maciej Stachowiak wrote: Some of us at Apple have discussed fullscreen APIs, and we think a user gesture requirement plus clear indication of what has happened is likely sufficient. As to the API itself: we tentatively think a good API would be to ma

Re: [whatwg] api for fullscreen()

Some of us at Apple have discussed fullscreen APIs, and we think a user gesture requirement plus clear indication of what has happened is likely sufficient. As to the API itself: we tentatively think a good API would be to make a specific *element* go full screen, rather than the whole We

Re: [whatwg] api for fullscreen()

2009/12/17 Jonas Sicking > Technically speaking this isn't something that needs to be > standardized. All we need is a standardized fullscreen() function > somewhere, and possibly standardized "fullscreenon"/"fullscreenoff" > events. Browsers are free to implement whatever UI they want after > th

Re: [whatwg] api for fullscreen()

On Thu, Dec 17, 2009 at 12:12 AM, Robert O'Callahan wrote: > 2009/12/17 Ian Fette (イアンフェッティ) >> >> I'm not convinced we actually need opt-in, though if we did have opt-in it >> should allow the user to persist that choice (don't ask me for permission >> each time i try to fullscreen a youtube vid

Re: [whatwg] api for fullscreen()

2009/12/17 Ian Fette (イアンフェッティ) > I'm not convinced we actually need opt-in, though if we did have opt-in it > should allow the user to persist that choice (don't ask me for permission > each time i try to fullscreen a youtube video.) > Sure. > I would much rather go for user gesture + opt-out

Re: [whatwg] api for fullscreen()

2009/12/16 Robert O'Callahan > 2009/12/17 Ian Fette (イアンフェッティ) > >> I think what I've heard from application developers over and over again is >> that, while the UA may provide some way to go into full screen from in the >> browser chrome, it is much more discoverable when that capability exists

Re: [whatwg] api for fullscreen()

2009/12/17 Ian Fette (イアンフェッティ) > I think what I've heard from application developers over and over again is > that, while the UA may provide some way to go into full screen from in the > browser chrome, it is much more discoverable when that capability exists > from within the content area (e.g.

Re: [whatwg] api for fullscreen()

2009/12/16 Jonas Sicking > 2009/12/16 Ian Fette (イアンフェッティ) : > > 2009/12/16 Jonas Sicking > >> > >> 2009/12/16 Ian Fette (イアンフェッティ) : > >> > I think what I've heard from application developers over and over > again > >> > is > >> > that, while the UA may provide some way to go into full screen f

Re: [whatwg] api for fullscreen()

2009/12/16 Ian Fette (イアンフェッティ) : > 2009/12/16 Jonas Sicking >> >> 2009/12/16 Ian Fette (イアンフェッティ) : >> > I think what I've heard from application developers over and over again >> > is >> > that, while the UA may provide some way to go into full screen from in >> > the >> > browser chrome, it is

Re: [whatwg] api for fullscreen()

2009/12/16 Jonas Sicking > 2009/12/16 Ian Fette (イアンフェッティ) : > > I think what I've heard from application developers over and over again > is > > that, while the UA may provide some way to go into full screen from in > the > > browser chrome, it is much more discoverable when that capability exis

Re: [whatwg] api for fullscreen()

2009/12/16 Ian Fette (イアンフェッティ) : > I think what I've heard from application developers over and over again is > that, while the UA may provide some way to go into full screen from in the > browser chrome, it is much more discoverable when that capability exists > from within the content area (e.g.

Re: [whatwg] api for fullscreen()

I think what I've heard from application developers over and over again is that, while the UA may provide some way to go into full screen from in the browser chrome, it is much more discoverable when that capability exists from within the content area (e.g. people are used to clicking on the full s

Re: [whatwg] api for fullscreen()

On Thu, Dec 17, 2009 at 11:42 AM, Ian Hickson wrote: > On Wed, 16 Dec 2009, Michael Dale wrote: >> >> It would be really nice if the html5 spec supported a javascript call to >> set a target window to fullscreen. The browser would then issue a >> security warning at the top of the page (similar to

Re: [whatwg] api for fullscreen()

On Wed, 16 Dec 2009, Michael Dale wrote: > > It would be really nice if the html5 spec supported a javascript call to > set a target window to fullscreen. The browser would then issue a > security warning at the top of the page (similar to pop-ups) and then > the user could grant that domain per