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 unnecessary—it's up to developers to use the API in a usable manner, and up to UAs to provide an easy escape hatch if the developer fails to do so, just like in desktop environments. You're not crippled in this environment. In a kiosk, you write the content, choose your browser, OS and hardware platform. You can (and maybe should) use non-standard extensions to take a vice-like grip of the display and UI. David Singer Multimedia and Software Standards, Apple Inc.
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 example, basically refuse to use applications that have the hubris to assume that they should own the screen and cover all the parts they don't need with gray. I didn't buy a large display to see grey painted everywhere; I bought it so I *could* see multiple things at once. If the user does not wish to view the content in full-screen and the developer feels that content can only be reasonably viewed full-screen, The developer has no idea how big my screen is, how many I have, or a host of other questions. I feel the user has opted not to view that content at all. I don't mind at all that the user has no choice but to skip that content; it's similar behaviour to a user quitting a desktop application that insists on running full-screen. Indeed. David Singer Multimedia and Software Standards, Apple Inc.
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' and that the user should own that decision. I, for example, basically refuse to use applications that have the hubris to assume that they should own the screen and cover all the parts they don't need with gray. I didn't buy a large display to see grey painted everywhere; I bought it so I *could* see multiple things at once. I agree that such behaviour is not always desirable and that prudent application developers should design their applications such that full-screen is not necessary. If a user chooses not to enter full-screen, giving the developer that information permits them to provide a suitable alternative interface; transparently providing an in-window experience will simply limit the ability to use fullscreen mode for things like comprehension tests, games that capture the mouse/keyboard as input methods and must hide the cursor, etc. So long as the user has the ability to escape fullscreen simply, the fullscreen API would behave more or less the same way as the fullscreen API in desktop application environments. That developers have the ability to build horrible interfaces is an unfortunate but necessary side effect of giving them useful APIs. If the user does not wish to view the content in full-screen and the developer feels that content can only be reasonably viewed full-screen, The developer has no idea how big my screen is, how many I have, or a host of other questions. The developer has access to your screen size via the window.screen object. I agree that it's presumptuous of a developer to insist on full-screen in many (most?) situations, but for applications that require full-screen conceptually (as opposed to applications that need to run large) I don't believe screen size should be a factor. By the sounds of things I'm pretty certain we're in agreement that fullscreen capabilities should be used sparingly as a matter of UX; I too have multiple (large) monitors, and as a Mac user tend to layer windows instead of running anything maximised. 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 unnecessary—it's up to developers to use the API in a usable manner, and up to UAs to provide an easy escape hatch if the developer fails to do so, just like in desktop environments. —Kit
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. Why is that a problem? Or even if it's not refusing to display content, it may simply not scale the content up to the full window if the user neglects to give permission for full screen. If the user wants the content to be large, why would he withhold permission? 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. So these scenarios seem relevant: 1 A malicious site wishes to switch to full-screen view and spoof chrome. The user hadn't asked for full-screen, so withholds permission. The site may at this point refuse to display content as you put it, but since that content's only purpose is to trick the user, its non-display is a good thing. 2 A user wishes to display some content full-screen, so grants permission and views it. 3 A user doesn't wish to display some content full-screen, so ignores any attempt by the site to become full-screen, and continues to view it normal size. I'm struggling to come up with a scenario in which your concerns apply. Please could you elaborate. Thanks. Smylers -- Watch fiendish TV quiz 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/programmes/b00lskhg
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 the user gives it permission to enter fullscreen mode. Why is that a problem? Or even if it's not refusing to display content, it may simply not scale the content up to the full window if the user neglects to give permission for full screen. If the user wants the content to be large, why would he withhold permission? A user may want to view the content scaled up to the full size of the window, without it being full-screen. 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, but sites that insist on being displayed full screen. So these scenarios seem relevant: 1 A malicious site wishes to switch to full-screen view and spoof chrome. The user hadn't asked for full-screen, so withholds permission. The site may at this point refuse to display content as you put it, but since that content's only purpose is to trick the user, its non-display is a good thing. 2 A user wishes to display some content full-screen, so grants permission and views it. 3 A user doesn't wish to display some content full-screen, so ignores any attempt by the site to become full-screen, and continues to view it normal size. I'm struggling to come up with a scenario in which your concerns apply. Please could you elaborate. Thanks. Sure. At my previous job, I wrote immersive interactive educational multimedia. My boss was very insistent about content being displayed full screen, to make the experience more immersive and reduce distractions (given the content, this wasn't unreasonable; there were parts that were time-critical simulations in which you wouldn't want to be distracted part way through by a chat window popping up). Had we been developing for the web, I could imagine him asking us to start with something that said Please press the button to enter full-screen mode and start the program, and the program would not start until full-screen mode was entered. I could imagine games, and other content doing the same as well. I think that this behavior is fairly user hostile, however. There are some times when a user really doesn't want his entire screen filled, for a good reason. If there is content that won't start until the fullscreen event has fired, or fullscreen pseudo-class has been applied, then that user has no choice but to skip that content or allow it to enter fullscreen mode. 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, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content. In short, there are several scenarios in which certain functionality in a web content is not available unless you enter fullscreen mode. Content authors should not be able to force fullscreen mode on users, however, so I think it would be best if the spec allows UAs to send the fullscreen event and set the fullscreen pseudoclass even if the content is not actually filling the entire screen. How exactly the UAs implement this is up to them, though I would recommend scaling the content up to the full window and sending the fullscreen events immediately, if they are waiting for permission to scale to fill the full screen. All the spec would have to say to cover all of the possible implementations is that the fullscreen events may be sent even if the content isn't actually filling an entire screen, and that the screen size may be changed even if you are already in fullscreen mode (which would need to be the case anyhow, since you may change the resolution of the screen when attaching a projector, or for devices in which the screen can rotate). Does this make it any clearer? -- Brian
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, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content. I don't agree that this behaviour is not expected. Many kinds of full-screen applications (web/Flash or otherwise) require that they are run at the highest window level for the reasons you mentioned (distractions, time-sensitive response; a web-based IDE like Bespin could, with a full-screen mode, become a WriteRoom equivalent for the web). Imagine an educational website where the page gives the user a passage of text then asks to go full-screen to perform an examination on that material; having the ability to have other windows open concurrently defeats the purpose of the application. 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, a user denying the application access to that full-screen capability is a user who does not wish to engage with that application as designed. When it comes to the user wishing to view content scaled up to fill the window, that's functionality we can already provide and should continue to be the onus of the site's developer if the content is suitable for that kind of consumption (YouTube already has a similar mode, for example). The advantage to removing that sort of ambiguity is that the page can be clever about how or when it offers fullscreen modes. If, inspecting the window.screen object, the developer determines that the user's screen is not sufficiently large to display his or her game in fullscreen (e.g. on a mobile device), he or she can choose to not show a fullscreen button, ensuring that all UI elements of the game are accommodated. If the user's screen is large, but they choose to reject the application's wishes to go fullscreen, the game may not fit (in fullscreen mode) in the browser window. I think that this behavior is fairly user hostile, however. There are some times when a user really doesn't want his entire screen filled, for a good reason. If there is content that won't start until the fullscreen event has fired, or fullscreen pseudo-class has been applied, then that user has no choice but to skip that content or allow it to enter fullscreen mode. If the user does not wish to view the content in full-screen and the developer feels that content can only be reasonably viewed full-screen, I feel the user has opted not to view that content at all. I don't mind at all that the user has no choice but to skip that content; it's similar behaviour to a user quitting a desktop application that insists on running full-screen. —Kit
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, but sites that insist on being displayed full screen. OK. That's 'merely' an annoyance, not a security threat. There are lots of ways authors can be obnoxious if they choose; I'm not sure it's desirable, or even possible, to outlaw them. My boss was very insistent about content being displayed full screen, to make the experience more immersive and reduce distractions ... Please press the button to enter full-screen mode and start the program, and the program would not start until full-screen mode was entered. I could imagine games, and other content doing the same as well. I think that this behavior is fairly user hostile, however. In general user-agents are allowed to display content in anyway that a user has configured them to do, regardless of what the spec gives as the normal behaviour. If a user wishes to view content scaled up to fill the window, without the distractions of navigational links, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content. I've seen Firefox options (possibly in an extension) which allow users to tweak which toolbars and the like are still displayed when in full-screen view. If a browser (or an extension) wished to implement full-screen view as still having borders, the title bar, status bar, and so on then it could. And there's nothing an author could do about it. Content authors should not be able to force fullscreen mode on users, however, so I think it would be best if the spec allows UAs to send the fullscreen event and set the fullscreen pseudoclass even if the content is not actually filling the entire screen. To say that slightly differently: authors can dictate that certain output is only displayed when in full-screen view; but they have no control how full-screen view looks for a particular user and user-agent. All the spec would have to say to cover all of the possible implementations is that the fullscreen events may be sent even if the content isn't actually filling an entire screen, Allowing that behaviour is entirely reasonable. Though I think it should be covered by a more general statement that user-agents may display things however they want if so-configured, rather than just stating it for this particular narrow case. Smylers -- Watch fiendish TV quiz 'Only Connect' (some questions by me) Mondays at 20:30 on BBC4, or iPlayer: http://www.bbc.co.uk/programmes/b00lskhg
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 different scenario; not malicious sites per-se, but sites that insist on being displayed full screen. OK. That's 'merely' an annoyance, not a security threat. There are lots of ways authors can be obnoxious if they choose; I'm not sure it's desirable, or even possible, to outlaw them. Annoyances can turn into security threats if they train the user to click through security questions without thinking. And actually, this can be a security issue as well. A malicious site could entice the user by offering some sort of desirable content (a movie or TV show, porn, a game), but only if the user allows it to go fullscreen with keyboard access. It could then wait until the user has been idle for a bit, and display something that looks like a standard login screen for the operating system in question. The user may then be enticed to enter their password without realizing it's still the full-screen site they were using and not a real login screen. As ROC points out, it may be impossible to completely avoid a malicious site detecting whether you are fullscreen, as it can detect when the content is at one of the standard screen sizes; but we can make it a bit more difficult, and less likely that the user will be used to sites that require full screen, by providing the user an easy way to display full screen content in a window. My boss was very insistent about content being displayed full screen, to make the experience more immersive and reduce distractions ... Please press the button to enter full-screen mode and start the program, and the program would not start until full-screen mode was entered. I could imagine games, and other content doing the same as well. I think that this behavior is fairly user hostile, however. In general user-agents are allowed to display content in anyway that a user has configured them to do, regardless of what the spec gives as the normal behaviour. Yes. As I said, most of this is a UA issue, not a spec issue. I just want to encourage a usage that does not wind up with content locked behind requiring you to enter an actual full screen mode. If a user wishes to view content scaled up to fill the window, without the distractions of navigational links, comments, descriptions, and so on, they don't usually have a way to do this. If it were possible to use the full-screen button, but deny permission to actually go full screen, and have that simply display the content in the full window exactly as if it were full screen, it would give the users more control over how they view the content. I've seen Firefox options (possibly in an extension) which allow users to tweak which toolbars and the like are still displayed when in full-screen view. If a browser (or an extension) wished to implement full-screen view as still having borders, the title bar, status bar, and so on then it could. And there's nothing an author could do about it. Of course. Obviously, the UA gets the final say on how the content is displayed. I just want to encourage the UAs to have a mode that tells the application it's in fullscreen mode even if it really is not, and have that mode be easy to get into for the majority of users (thus, not depend on an extension or obscure configuration somewhere). Content authors should not be able to force fullscreen mode on users, however, so I think it would be best if the spec allows UAs to send the fullscreen event and set the fullscreen pseudoclass even if the content is not actually filling the entire screen. To say that slightly differently: authors can dictate that certain output is only displayed when in full-screen view; but they have no control how full-screen view looks for a particular user and user-agent. Yes, exactly. All the spec would have to say to cover all of the possible implementations is that the fullscreen events may be sent even if the content isn't actually filling an entire screen, Allowing that behaviour is entirely reasonable. Though I think it should be covered by a more general statement that user-agents may display things however they want if so-configured, rather than just stating it for this particular narrow case. Well, user agents may display things however they want, but I think it's worth pointing out that the events may not correspond to the time that the user actually gives permission to enter full screen mode, in those cases in which permission is required. Instead, content may be scaled to the full window and the events sent as soon as the button is pushed, and then the content resized to the actual full screen once permission has been granted. -- Brian
Re: [whatwg] api for fullscreen()
On Mon, Feb 1, 2010 at 4:41 PM, Brian Campbell lam...@continuation.org 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 a security dialog for this at all. The browser should be able to make the right decision here without user input -- indeed, user input probably isn't worth much, since many users will just click through the dialog. (And others will get confused or alarmed and not click, even though it's perfectly safe.) But I'm not sure why authors would need to know whether they're fullscreen or not.
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 the embedders to copy and paste anything fancy. * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. IIRC, it has been shown that at least as implemented in Flash Player, it is possible to draw enough distractions to make the users unable to read this message. Also, when the site is legitimate, it's quite annoying to have the overlay there. Personally, I'd rather have to click through a once per-Origin authorization bar (like geolocation in Firefox) than watch the press esc overlay every time. * make the location field available to the user so that they can see the URL even when in fullscreen This defeats the point of full screen. If I want a 16:9 video to go full screen on a 16:9 display, I want all screen pixels to be used for the video. * drop out of fullscreen if navigating to another page This would constrain slide shows do be unnecessarily Ajaxy and less linkable with per-slide JavaScriptless URLs. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
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 HTML5, Flash, ActiveX, etc. depending on UA without requiring the embedders to copy and paste anything fancy. Perhaps we'd enforce a same-origin rule where the iframe contents have to be from the same domain as the main page, then? * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. IIRC, it has been shown that at least as implemented in Flash Player, it is possible to draw enough distractions to make the users unable to read this message. That's why I said hard to spoof. The Flash overlay makes the mistake of not being contrasty enough. An improvement would be to dim out the rest of the content while showing this overlay. Also, when the site is legitimate, it's quite annoying to have the overlay there. Personally, I'd rather have to click through a once per-Origin authorization bar (like geolocation in Firefox) than watch the press esc overlay every time. That's a possibility, yes. * make the location field available to the user so that they can see the URL even when in fullscreen This defeats the point of full screen. If I want a 16:9 video to go full screen on a 16:9 display, I want all screen pixels to be used for the video. I said make available, not should be visible at all times. I was thinking of a behavior where it shows up at the top of the screen if the user moves the mouse close to the top. * drop out of fullscreen if navigating to another page This would constrain slide shows do be unnecessarily Ajaxy and less linkable with per-slide JavaScriptless URLs. Maybe a same-origin test could be used here too? But personally I think it's OK to force a fullscreen application to rely on AJAX and twiddling location.hash, rather than loading new pages. Simon
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 confirmation UI. This seems overly complicated. 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. Then the user won't have to jump through the hoops again when they return, but will still protect them from random websites going fullscreen and trying to phish things. This way blocking or restricting keyboard events isn't needed. Those kinds of dialogs are dangerous because users tend to just dismiss them without reading. Passive (ignorable and asynchronous) confirmation works better. The enableKeys option would let authors who don't need alphanumeric input (video playback) go fullscreen with a low confirmation bar (perhaps none at all, if the fullscreen request is in a click event handler). I know it's not the biggest concern right now, but I thought it's worth pointing out: on mobile touchscreen devices this hint does nothing as the site can spoof the keyboard as well. I don't see any harm in this hint, but I'd say the focus should be on ensuring it's clear to the user what's going on in either case.
Re: [whatwg] api for fullscreen()
On Thu, Jan 28, 2010 at 8:55 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns tensafefr...@google.com 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) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). Don't you think it would make more sense to dispatch the enterFullscreen event only when the element actually goes fullscreen? If the user clicks the fullscreen button, but then doesn't accept whatever options (likely a security dialog or something) then it doesn't make sense to broadcast an enterFullscreen event, as you'd just have to broadcast an exitFullscreen event right away to show that the user isn't actually in fullscreen. That was my intent in the last sentence of the paragraph you quoted. 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 confirmation UI. This seems overly complicated. 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. Then the user won't have to jump through the hoops again when they return, but will still protect them from random websites going fullscreen and trying to phish things. This way blocking or restricting keyboard events isn't needed. Those kinds of dialogs are dangerous because users tend to just dismiss them without reading. Passive (ignorable and asynchronous) confirmation works better. The enableKeys option would let authors who don't need alphanumeric input (video playback) go fullscreen with a low confirmation bar (perhaps none at all, if the fullscreen request is in a click event handler). Also consider what happens if the user focuses something on another display. Do you then drop out of fullscreen, or just blur() the fullscreen window? (I'd vote to leave it and just blur() it, so you can do things like watch fullscreen video on one display and continue working in the other). That sounds like a good idea, but I don't think it needs to be in the spec. It's up to the UA. Another thing to add in here I haven't seen discussed yet is what to show as the background to the fullscreen element. Consider the example of a 16:9 video going fullscreen on a 4:3 display. How do you tell the browser to fill in the extra space around the video with black (or whatever other color you want). Is this a custom css element? The video element already letterboxes. So you'd do something like this: div class=fullscreen style=background:black; position:relative; width:640px; height:480px; video style=position:absolute; width:100%; height:100%; src=.../video ... controls ... /div Making the div fullscreen would override the author geometry and produce the effect you want. 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? The case I'm thinking about is when a Canvas element is taken fullscreen; on that element changing the .width and .height properties changes the size of the backing store, but applying a CSS style to change its width and height causes the backing store to be scaled to fit. The desired behavior is for the backing store to be resized. -Ken Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen()
On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell k...@google.com 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? The latter. The window's viewport is aligned with the screen bounds, and by default the element is styled with position:fixed; left:0; right:0; top:0; bottom:0, which resizes it in CSS to fill the viewport. The case I'm thinking about is when a Canvas element is taken fullscreen; on that element changing the .width and .height properties changes the size of the backing store, but applying a CSS style to change its width and height causes the backing store to be scaled to fit. The desired behavior is for the backing store to be resized. The author would have to handle the beginfullscreen event and manually set the canvas width/height attributes, e.g. to getBoundingClientRect().width/height. I don't think we should change width/height attributes automatically, since that has the side effect of clearing the canvas. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen()
On Mon, Feb 1, 2010 at 11:05 AM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell k...@google.com 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? The latter. The window's viewport is aligned with the screen bounds, and by default the element is styled with position:fixed; left:0; right:0; top:0; bottom:0, which resizes it in CSS to fill the viewport. The case I'm thinking about is when a Canvas element is taken fullscreen; on that element changing the .width and .height properties changes the size of the backing store, but applying a CSS style to change its width and height causes the backing store to be scaled to fit. The desired behavior is for the backing store to be resized. The author would have to handle the beginfullscreen event and manually set the canvas width/height attributes, e.g. to getBoundingClientRect().width/height. I don't think we should change width/height attributes automatically, since that has the side effect of clearing the canvas. OK, that sounds reasonable. Thanks. -Ken Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
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) actually initiates fullscreen display of the element. The UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). I like this proposal overall. I'm looking forward to being able to display content full screen; this is one of the last features necessary to start moving the kind of content that I work on to the web. 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. Or even if it's not refusing to display content, it may simply not scale the content up to the full window if the user neglects to give permission for full screen. 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. If a user clicks a fullscreen button, and declines to give permission to the site to actually use the whole screen, the behavior should probably be to simply resize the element to the full viewport. A standard interface (close button, or escape key, or the like) could then take the element back out of fullscreen (or in this case, full viewport) mode; the application would behave the same as if it were in fullscreen mode, it would just be constrained within the window without knowing it. If the user does give permission, using an asynchronous notification drop down or similar interface, then the browser would have to send a resize event or something like that to let the application know that it needs to resize again. The beginfullscreen/endfullscreen events, and pseudoclass, would apply when resizing to the full window, if full screen permission hasn't been granted. This would also help applications deal more gracefully with users who don't give permission to go full screen; the application would likely have to do the resizing to the full window itself if it doesn't get permission to use the full screen, but it won't know how long to wait before deciding that the user hasn't given permission. This way, it would resize immediately and automatically to the viewport before permission is granted, and resize again to the full screen if permission has been granted. -- Brian
Re: [whatwg] api for fullscreen() - security issues
On Tue, Feb 2, 2010 at 5:00 AM, Simon Fraser s...@me.com 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 boilerplate to an iframe in order to be able to be able to serve HTML5, Flash, ActiveX, etc. depending on UA without requiring the embedders to copy and paste anything fancy. Perhaps we'd enforce a same-origin rule where the iframe contents have to be from the same domain as the main page, then? I think that wouldn't work because people will want to serve the IFRAME document from the video site. However, I'd very very reluctant to allow subframes to go fullscreen by default. I haven't got any specific attack scenarios in mind, but it seems to add to the power of clickjacking, which is the last thing we need. How about denying fullscreen from subdocuments by default, and allow opt-in with an attribute on iframe, say allowfullscreen? Note that same-origin IFRAMEs can reach into their parent document and make it fullscreen, and make the IFRAME position:fixed etc, to effectively make themselves fullscreen (albeit not very conveniently). Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen()
On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell lam...@continuation.orgwrote: 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. Or even if it's not refusing to display content, it may simply not scale the content up to the full window if the user neglects to give permission for full screen. We could simply modify the proposal to apply the fullscreen pseudoclass (but not fullscreen the window) if permission is denied. However, in general I don't think we can prevent Web content from detecting that it is not fullscreen. For example it could check whether the window size is one of a set of common screen sizes. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
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 lam...@continuation.org 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 permission to enter fullscreen mode. Or even if it's not refusing to display content, it may simply not scale the content up to the full window if the user neglects to give permission for full screen. We could simply modify the proposal to apply the fullscreen pseudoclass (but not fullscreen the window) if permission is denied. The user may never notice the notification and explicitly deny permission; the whole point of asynchronous notifications is that they are less obtrusive and not modal, but that means that users can ignore or fail to notice them and keep going without ever dismissing them. I think it would be best to immediately go as full screen as possible (so, full window if permission hasn't yet been given), and then resize to full screen if permission is granted. This will avoid content authors having to duplicate that same functionality themselves for their users that don't ever give or deny permission. Resizing when in full screen mode will need to be implemented anyhow, to support devices like the iPhone or iPad which can change orientation and will need to reshape the screen. However, in general I don't think we can prevent Web content from detecting that it is not fullscreen. For example it could check whether the window size is one of a set of common screen sizes. No, you can't stop someone who is truly dedicated from guessing based on the exact size. My concern is more with authors who feel that their content is best displayed in full screen, and so may simply refuse to play it until they've gotten the fullscreen event or have the fullscreen pseudoclass. That would be pretty easy to implement, if you have that functionality available to you. I know my previous director would have requested it; he is very particular about content being displayed in full screen, and while I would argue that we shouldn't lock people out who don't want to be in full screen mode, I may have been overruled if such functionality were available and so easy to use. Here are three possible scenarios, for the user clicking the fullscreen button on some content and then denying permission to allow full screen access: 1) The original proposal: * User clicks full screen button. * Notification pops up, no events are sent or classes applied. * User clicks deny, no events are sent or classes applied. * The user's full screen request has been ignored, and now the page author needs to do something special to resize to the full window if desired. 2) Your suggestion above, to apply the pseudoclass if permssion is denied: * User clicks full screen button. * Notification pops up, no events sent or classes applied. * User clicks deny, and fullscreen class is applied. * You didn't mention whether you intend for the event to also be sent, and content automatically resized to fit the viewport; if that doesn't happen, then the page author needs to add special handling for expanding the content to the full window, or something of the sort. * At this point, you have an odd effect, in which denying permission for full screen causes the content to scale to the full window. 3) My suggestion: * The user clicks full screen. * Notification pops up, content scales up to fill the window, pseudoclass is applied, event is sent. * The user clicks deny, which simply dismisses the notification. * The content is now accessible, in pseudo fullscreen mode, giving the user access to the controls and content for that mode. This may not be the most common use case, of the user clicking the fullscreen button and then denying permission, but I think that my proposal gives a fairly sensible behavior for that use case, encouraging a user friendly experience without requiring the author to do too much extra work, and without encouraging content to be unavailable outside of full screen mode. Of course, much of this discussion is of details that could be left up to the UA. As far as the spec is concerned, the main points to include would be that the fullscreen events, class, and resizing may occur even when the content is not actually being displayed on the full screen, and that resizing may occur after entering fullscreen mode. -- Brian
Re: [whatwg] api for fullscreen()
On Sun, 31 Jan 2010 03:43:49 +0100, Simon Fraser s...@me.com 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 object is passed implicitly to the method, so the UA knows which window to take fullscreen, right? Isn't the Screen object always associated with a single Window object? I.e. there's a 1:1 mapping. This talk of going into fullscreen on different screens at the same time makes me think that the screen should be an optional argument: void enterFullscreen(optional DOMElement element, optional Screen, optional boolean enableKeys); with the default screen being either the main screen, or window.screen. As far as I know there is no API to that deals with multiple monitors currently. This is a minor issue with e.g. Media Queries, the Screen object, etc. -- Anne van Kesteren http://annevankesteren.nl/
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 generated aren't. -Olli
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 displayingFullscreen;
beginfullscreen and endfullscreen events
Where beginfullscreen and endfullscreen are targeted at the element if
one was provided, or else at the window, and bubble. 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; }
*:not(:root):fullscreen { position:fixed; left:0; top:0; bottom:0; right:0; }
I'll go for that.
Another good argument to have this API on the window object is that fullscreen
is effectively a state on the window. It would not make any sense to go
fullscreen on one element, and then fullscreen on another element.
Should enterFullscreen() throw an exception if already fullscreen?
Simon
Re: [whatwg] api for fullscreen()
On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser s...@me.com 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 supportsFullscreen;
boolean attribute displayingFullscreen;
beginfullscreen and endfullscreen events
Where beginfullscreen and endfullscreen are targeted at the element
if one was provided, or else at the window, and bubble. 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; }
*:not(:root):fullscreen { position:fixed; left:0; top:0; bottom:0;
right:0; }
I'll go for that.
Another good argument to have this API on the window object is that
fullscreen is effectively a state on the window. It would not make any
sense to go fullscreen on one element, and then fullscreen on another
element.
Should enterFullscreen() throw an exception if already fullscreen?
To stop polluting the Window object, might it make sense to put the new
members (other than event handler attributes) on window.screen?
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] api for fullscreen()
On Thu, Jan 28, 2010 at 6:42 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com 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 resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. 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 be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission *** WARNING: totally half-baked proposal ahead! *** New API for all elements: void enterFullscreen(optional boolean enableKeys); void exitFullscreen(); boolean attribute supportsFullscreen; boolean attribute displayingFullscreen; beginfullscreen and endfullscreen events 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. 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 UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). 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 confirmation UI. In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens). enterFullscreen would throw an exception if fullscreen was definitely not going to happen for this element due to not being supported or currently permitted, or if all screens are already occupied. Note: The if all screens are already occupied implies acquiring some global lock before returning from this method. That's not so great for a multi-threaded UA. I'd prefer if we just defined an asynchronous error event that could be used to report rejections. -Darin supportsFullscreen returns false if it's impossible for this element to ever be shown fullscreen. It does not reveal whether permission will be granted. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen()
On Fri, Jan 29, 2010 at 11:54 PM, Robert O'Callahan
rob...@ocallahan.org 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; }
*:not(:root):fullscreen { position:fixed; left:0; top:0; bottom:0; right:0;
}
This sounds great to me. The :not(:root) required to select the
actual element was about to draw an objection from me, but then I
realized that actual authors are almost certainly going to have a good
hook to target the fullscreenable elements anyway, and so won't need
to write that fully-general version of the selector on their own.
Something like article:fullscreen or .widget:fullscreen would work
fine and be easy to write and understand.
~TJ
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 s...@me.com 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 supportsFullscreen;
boolean attribute displayingFullscreen;
beginfullscreen and endfullscreen events
Where beginfullscreen and endfullscreen are targeted at the element if
one was provided, or else at the window, and bubble. 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; }
*:not(:root):fullscreen { position:fixed; left:0; top:0; bottom:0; right:0;
}
I'll go for that.
Another good argument to have this API on the window object is that
fullscreen is effectively a state on the window. It would not make any sense
to go fullscreen on one element, and then fullscreen on another element.
Should enterFullscreen() throw an exception if already fullscreen?
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 object is passed implicitly to the
method, so the UA knows which window to take fullscreen, right?
This talk of going into fullscreen on different screens at the same time makes
me think that the screen should be an optional argument:
void enterFullscreen(optional DOMElement element, optional Screen, optional
boolean enableKeys);
with the default screen being either the main screen, or window.screen.
Simon
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 s...@me.com 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 resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. 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 be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission *** WARNING: totally half-baked proposal ahead! *** New API for all elements: void enterFullscreen(optional boolean enableKeys); void exitFullscreen(); boolean attribute supportsFullscreen; boolean attribute displayingFullscreen; beginfullscreen and endfullscreen events 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 confirmation UI. I'd like to start a discussion on steps that the UA may take to mitigate the risks of using the fullscreen API for phishing attacks. I'm not sure how much should be required of UAs in the spec, but I could imagine that steps that the UA could take may include some or all of the following: * require that enterFullscreen() is being called inside a user-event handler (e.g. click or keypress) to avoid drive-by fullscreen annoyances. * disallow enterFullscreen() from a frame or iframe * show an animation as the window enters fullscreen so the user can see the transition taking place * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. * show an affordance to allow the user to exit fullscreen (e.g. a close button) when the user moves the mouse * make the location field available to the user so that they can see the URL even when in fullscreen * drop out of fullscreen if navigating to another page * if focussed on an element, drop out of fullscreen if that element is removed from the DOM * limit arbitrary keyboard input unless 'enableKeys' is true * disallow window.open etc. while in fullscreen I'm just not sure which of these would be requirements in the spec. Simon
Re: [whatwg] api for fullscreen() - security issues
On Sat, Jan 30, 2010 at 9:08 PM, Simon Fraser s...@me.com 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-initiated click and a script-initiated one? * disallow enterFullscreen() from a frame or iframe Makes sense, though consider its interaction with sandboxed iframes (that is, you may actually *want* the ability to turn on fullscreen-ability for an iframe). * show an animation as the window enters fullscreen so the user can see the transition taking place How would this interact with an author hooking CSS Transitions to the element keyed on the :fullscreen pseudoclass? If we implement the actual fullscreen effect essentially purely in CSS, I'd prefer the minimum amount of magic here. * show an hard-to-spoof overlay with some text that tells the user that they can use the Escape key to exit fullscreen, and prevent the page from capturing this keypress. * show an affordance to allow the user to exit fullscreen (e.g. a close button) when the user moves the mouse Both of these make a lot of sense to me, and match the way fullscreen effects work today, so users will understand it. * make the location field available to the user so that they can see the URL even when in fullscreen This partially defeats the purpose of fullscreen. ^_^ Though, it may be worthwhile to do so anyway, as it would be a major indicator that something is being spoofed. * drop out of fullscreen if navigating to another page Sounds very reasonable. * if focussed on an element, drop out of fullscreen if that element is removed from the DOM Definitely a good idea. * limit arbitrary keyboard input unless 'enableKeys' is true Already has some history, so would probably be a decent idea. * disallow window.open etc. while in fullscreen I don't fully understand this restriction's justification. ~TJ
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 Frasers...@me.com 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-initiated click and a script-initiated one? Not sure about the spec, but popup blockers sure do. -Boris
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.gspan 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 context anyway More precisely would make them block-level in CSS terms. A block formatting context is something different. but what implications might that have for things like table cells/table rows being made full-screen? For table cells, none whatsoever. For table rows, that's a good question. If one just makes them position:fixed, that would basically mean you create an anonymous table inside the row (in particular, you redo column balancing on the row's cells while ignoring all the other rows of the table). Is that the desired behavior? If not, what is? There may be no good solutions here. The other interesting thing with table rows is what should happen with cells spanning into the row or out of it. With the position:fixed approach the former would not appear and the latter would just be visible in their entirety. Again, it's not clear to me whether there's a good behavior here. -Boris
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 s...@me.com 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 resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. 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 should leave this up to the page author. 3) Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission Agreed. New API for all elements: void enterFullscreen(optional boolean enableKeys); void exitFullscreen(); boolean attribute supportsFullscreen; boolean attribute displayingFullscreen; beginfullscreen and endfullscreen events Those seem reasonable for a proposal where a single element is taken 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 very element-focused API (as does the enterFullscreen() method on Element that you propose above). Another approach would be to leave it entirely up to the page author to style their page differently when in fullscreen, and not have the API force them to focus on one element. Then the API would probably be on the Window object, and the UA would simply transition the view to a fullscreen presentation. There could be a pseudo-class to the body, or a way to use media queries to allow the author can apply different styles for fullscreen. In this scenario the author is not forced to nest all their fullscreen content under one element, and can continue to show the rest of the page content (maybe dimmed out by a semi-transparent overlay div) in the background. The disadvantage of this approach is that it makes it much harder for the UA to do any kind of automatic transitions between the two presentations (though it's not clear to me that nice automatic transitions will be possible with the element-based API either). Simon
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 very element-focused API (as does the enterFullscreen() method on Element that you propose above). Another approach would be to leave it entirely up to the page author to style their page differently when in fullscreen, and not have the API force them to focus on one element. Then the API would probably be on the Window object, and the UA would simply transition the view to a fullscreen presentation. There could be a pseudo-class to the body, or a way to use media queries to allow the author can apply different styles for fullscreen. In this scenario the author is not forced to nest all their fullscreen content under one element, and can continue to show the rest of the page content (maybe dimmed out by a semi-transparent overlay div) in the background. Well, as an author, you can always choose to make the body element go fullscreen, wouldn't you? So you can have both: - use a single div with all it's content - use a video element - or use the body, so that the whole page goes fullscreen. And if there is a pseudo-class on this element, you can always style the content accordingly. Best regards, Frank Hellenkamp -- frank hellenkamp | interface designer solmsstraße 7 | 10961 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.3212.100 35 22 | fax jo...@depagecms.net http://www.depagecms.net http://immerdasgleiche.de http://everydayisexactlythesame.net/ signature.asc Description: OpenPGP digital signature
Re: [whatwg] api for fullscreen()
On Sat, Jan 30, 2010 at 5:49 AM, Simon Fraser s...@me.com 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 should leave this up to the page author.
Leaving it up to the page author was what I meant by in-page UI, I just
didn't phrase it well.
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 very element-focused API (as does the enterFullscreen()
method on Element that you propose above).
Another approach would be to leave it entirely up to the page author to
style their page differently when in fullscreen, and not have the API force
them to focus on one element. Then the API would probably be on the Window
object, and the UA would simply transition the view to a fullscreen
presentation. There could be a pseudo-class to the body, or a way to use
media queries to allow the author can apply different styles for fullscreen.
In this scenario the author is not forced to nest all their fullscreen
content under one element, and can continue to show the rest of the page
content (maybe dimmed out by a semi-transparent overlay div) in the
background.
The latter is easy to do with my proposed API too: just give the fullscreen
element a non-opaque background.
The disadvantage of this approach is that it makes it much harder for the UA
to do any kind of automatic transitions between the two presentations
(though it's not clear to me that nice automatic transitions will be
possible with the element-based API either).
I suggested an approach for transitions above: apply style changes, render
the element at the size of the screen, and then zoom that image out from the
element's old position to the screen size. Because video self-letterboxes,
you can make this always look good for video even if the screen has a
different aspect ratio to the original size of the video element.
There is an additional issue I just thought of: with either approach, you'll
normally want to hide the viewport scrollbar. You could just say that the UA
hides the viewport scrollbar while the viewport is in fullscreen mode. Or
you could use a pseudoclass to set overflow:hidden on the root element,
which would let the author override it, or make the user do that manually.
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 displayingFullscreen;
beginfullscreen and endfullscreen events
Where beginfullscreen and endfullscreen are targeted at the element if
one was provided, or else at the window, and bubble. 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; }
*:not(:root):fullscreen { position:fixed; left:0; top:0; bottom:0; right:0;
}
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]
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 hsivo...@iki.fi 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 a fresh WebKit nigthly) Interesting, but I'd still like to see the proposal. This should definitely be something that works on more than just media elements. The code referenced in that commit, and used by jilion.com, is NOT our proposal for a generic fullscreen mechanism. Rather, it's a new, webkit-prefixed method on the HTMLMediaElement which does the equivalent of the user clicking on the fullscreen button in the built-in controls. This is highly desirable for page that want to user their own custom controls, but would still like the user to go fullscreen. 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 resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. Simon
Re: [whatwg] api for fullscreen()
On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com 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 resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. 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 be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission *** WARNING: totally half-baked proposal ahead! *** New API for all elements: void enterFullscreen(optional boolean enableKeys); void exitFullscreen(); boolean attribute supportsFullscreen; boolean attribute displayingFullscreen; beginfullscreen and endfullscreen events 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. 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 UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). 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 confirmation UI. In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens). enterFullscreen would throw an exception if fullscreen was definitely not going to happen for this element due to not being supported or currently permitted, or if all screens are already occupied. supportsFullscreen returns false if it's impossible for this element to ever be shown fullscreen. It does not reveal whether permission will be granted. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
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 be fixed
size while other content fills the screen.
4) Should accommodate potential UA security concerns, e.g. by allowing the
transition to fullscreen mode to happen asynchronously after the user has
confirmed permission
A couple of points:
Regarding point 1, surely any fullscreen API should only support block-level
elements?
If I'm reading point 2 correctly, I disagree with it (except in cases like
video where a default style exists to manipulate the element itself). To me
(based on how I can envisage using this functionality, particularly regarding
touch-screen kiosks) the use-cases for full-screen capable elements should be
left out of the UA and in the hands of the author (e.g. as Javascript buttons
or links).
When it comes to point 3, I figure a good way to handle this might be to
introduce a CSS pseudo-class for fullscreen elements. Then the UA default style
would simply be *:fullscreen { position: fixed; left: 0; top: 0; right: 0;
bottom: 0; }. Some method for changing the layout of the element is going to be
required to handle cases where the aspect ratio of the screen doesn't match
that of the element in the document flow.
Should zoomed-up versions of a container scale elements like images and text or
merely the containing box? If the latter, does that limit the ability to
provide animation in-UA to naturally zoom the element to full-screen without
distracting re-flow of text? And does it limit the likely use-case for authors
of providing full-screen slideshows etc. where images would be expected to zoom
to fill their new, larger container.
One other brief concern; there's a chance (e.g. on mobile devices) that the
fullscreen layout is smaller than the element in the normal document flow
(where it can be scrolled). That may make it necessary to permit some user
manipulation of the fullscreen layout such as zooming and panning (which may
otherwise be restricted as per point 4).
—Kit
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 probably want some controls to be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission A couple of points: Regarding point 1, surely any fullscreen API should only support block-level elements? Block-level in what sense? img is not block-level in any sense; One could argue that video and object 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. -Boris
Re: [whatwg] api for fullscreen()
Block-level in what sense? img is not block-level in any sense; One could argue that video and object 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 element opens the door to full-screening inline text elements (e.g span elements). Looking at a few lists of all inline elements in HTML, there aren't any except img (except perhaps form inputs/textareas) that should obviously be permitted this sort of full-screen capability (without first being defined as display: block). I suppose the native style being position: fixed would put those elements in a block formatting context anyway, but what implications might that have for things like table cells/table rows being made full-screen? —Kit
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 UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). Don't you think it would make more sense to dispatch the enterFullscreen event only when the element actually goes fullscreen? If the user clicks the fullscreen button, but then doesn't accept whatever options (likely a security dialog or something) then it doesn't make sense to broadcast an enterFullscreen event, as you'd just have to broadcast an exitFullscreen event right away to show that the user isn't actually in 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 confirmation UI. This seems overly complicated. 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. Then the user won't have to jump through the hoops again when they return, but will still protect them from random websites going fullscreen and trying to phish things. This way blocking or restricting keyboard events isn't needed. In principle a UA could support multiple elements in fullscreen mode at the same time (e.g., if the user has multiple screens). That sounds complicated, but brings up the good point of how to choose which screen to go fullscreen on. I'd recommend going fullscreen on the same monitor that the element going fullscreen inhabits. (if there's overlap, I suppose you'd have to calculate which display contains most of the element). Also consider what happens if the user focuses something on another display. Do you then drop out of fullscreen, or just blur() the fullscreen window? (I'd vote to leave it and just blur() it, so you can do things like watch fullscreen video on one display and continue working in the other). Another thing to add in here I haven't seen discussed yet is what to show as the background to the fullscreen element. Consider the example of a 16:9 video going fullscreen on a 4:3 display. How do you tell the browser to fill in the extra space around the video with black (or whatever other color you want). Is this a custom css element?
Re: [whatwg] api for fullscreen()
On Fri, Jan 29, 2010 at 4:06 PM, Kit Grose k...@iqmultimedia.com.au 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 cases like
video where a default style exists to manipulate the element itself). To
me (based on how I can envisage using this functionality, particularly
regarding touch-screen kiosks) the use-cases for full-screen capable
elements should be left out of the UA and in the hands of the author (e.g.
as Javascript buttons or links).
Sorry I wasn't clear. By in-page UI I meant UI under the control of the
author.
When it comes to point 3, I figure a good way to handle this might be to
introduce a CSS pseudo-class for fullscreen elements. Then the UA default
style would simply be *:fullscreen { position: fixed; left: 0; top: 0;
right: 0; bottom: 0; }. Some method for changing the layout of the element
is going to be required to handle cases where the aspect ratio of the screen
doesn't match that of the element in the document flow.
Indeed. A CSS pseudo-class sounds like a reasonable idea.
Should zoomed-up versions of a container scale elements like images and text
or merely the containing box? If the latter, does that limit the ability to
provide animation in-UA to naturally zoom the element to full-screen without
distracting re-flow of text? And does it limit the likely use-case for
authors of providing full-screen slideshows etc. where images would be
expected to zoom to fill their new, larger container.
If you change the layout, zooming isn't really necessary. My guess is that
there are several interpolation strategies for transition effects that would
all work. For example, you could apply the style change, render the element
at the size of the screen, and then zoom that image out from the element's
old position to the screen size.
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]
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 Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] api for fullscreen()
On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns tensafefr...@google.comwrote: 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 UA may asynchronously display confirmation UI and dispatch the task when the user has confirmed (or never). Don't you think it would make more sense to dispatch the enterFullscreen event only when the element actually goes fullscreen? If the user clicks the fullscreen button, but then doesn't accept whatever options (likely a security dialog or something) then it doesn't make sense to broadcast an enterFullscreen event, as you'd just have to broadcast an exitFullscreen event right away to show that the user isn't actually in fullscreen. That was my intent in the last sentence of the paragraph you quoted. 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 confirmation UI. This seems overly complicated. 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. Then the user won't have to jump through the hoops again when they return, but will still protect them from random websites going fullscreen and trying to phish things. This way blocking or restricting keyboard events isn't needed. Those kinds of dialogs are dangerous because users tend to just dismiss them without reading. Passive (ignorable and asynchronous) confirmation works better. The enableKeys option would let authors who don't need alphanumeric input (video playback) go fullscreen with a low confirmation bar (perhaps none at all, if the fullscreen request is in a click event handler). Also consider what happens if the user focuses something on another display. Do you then drop out of fullscreen, or just blur() the fullscreen window? (I'd vote to leave it and just blur() it, so you can do things like watch fullscreen video on one display and continue working in the other). That sounds like a good idea, but I don't think it needs to be in the spec. It's up to the UA. Another thing to add in here I haven't seen discussed yet is what to show as the background to the fullscreen element. Consider the example of a 16:9 video going fullscreen on a 4:3 display. How do you tell the browser to fill in the extra space around the video with black (or whatever other color you want). Is this a custom css element? The video element already letterboxes. So you'd do something like this: div class=fullscreen style=background:black; position:relative; width:640px; height:480px; video style=position:absolute; width:100%; height:100%; src=.../video ... controls ... /div Making the div fullscreen would override the author geometry and produce the effect you want. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen()
2009/12/17 Maciej Stachowiak m...@apple.com 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 clean way. If content has to make layout changes by hand to limit itself to the specific fullscreen target, then it's extremely difficult, perhaps impossible, for the browser to do a single smooth animated transition without any unwanted flickering or layout thrash. We don't have a specific API proposal to make right now, but I'll try to get the people working on this to put forward a concrete proposal soon. Did that happen? The idea of making a particular element (ideally, any HTML element) fullscreen is intriguing, because as you say it's convenient for authors and it lets the browser provide useful UI cues for the transition to fullscreen mode. It's not completely clear to me what the actual behavior is, though. Does it mean you just scale up the bounding-box of the element to cover the screen? What if all or part of the element is scrolled out of view, display:none, etc? Are you drawing the element, or actually the contents of the whole window? (I.e., do effects imposed by container elements like 'opacity' take effect?) As for security, apparently Flash makes alphanumeric key input exit fullscreen mode, which seems adequate to avoid password spoofing, and still leaves a few keys usable for games. Perhaps the method to active fullscreen mode could have a parameter to request arbitrary key input, and that could require more explicit opt-in from the user. Although it just occurred to me that for devices without keyboards, disabling keyboard input isn't necessarily a useful anti-spoofing measure. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
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 m...@apple.com 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 make a specific *element* go full screen, rather than the whole Web page. Some use cases for fullscreen will indeed want to transition the whole page, for example, let's say a Web-based editor wants to provide a distraction-free fullscreen mode like WriteRoom. However, it seems like many common use cases will benefit most from taking only part of the page full-screen, for example video or games, where it's common for the original content to only be a small box in the page. Now, content could just manually hide the parts of the page in response to an event. Or you could provide a special media type or pseudo-class to use CSS to hide the unwanted content. In Opera, @media projection targets full-screen mode. It's possible though that a page would want different styles when the whole page is in full screen and when an element is in full screen. A page may also have multiple elements that could potentially be the focus when going full screen (for instance if it has multiple embedded videos) so it can't just use a single @media rule to hide all other content. - Maciej
Re: [whatwg] api for fullscreen()
2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com 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. e.g. you have to cal fullscreen() in response to a user gesture, you immediately get fullscreened, It's really easy to get users to click on things. but maybe there's some dorky bar up top that stays around until you click go away or never put up the dork bar again for this site. Maybe... Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen()
On Thu, Dec 17, 2009 at 12:12 AM, Robert O'Callahan rob...@ocallahan.org wrote: 2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com 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. e.g. you have to cal fullscreen() in response to a user gesture, you immediately get fullscreened, It's really easy to get users to click on things. but maybe there's some dorky bar up top that stays around until you click go away or never put up the dork bar again for this site. Maybe... 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 that. / Jonas
Re: [whatwg] api for fullscreen()
2009/12/17 Jonas Sicking jo...@sicking.cc 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 that. True, but if the API can't be implemented in an adequately secure manner, we shouldn't add it. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
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 Web page. Some use cases for fullscreen will indeed want to transition the whole page, for example, let's say a Web-based editor wants to provide a distraction-free fullscreen mode like WriteRoom. However, it seems like many common use cases will benefit most from taking only part of the page full-screen, for example video or games, where it's common for the original content to only be a small box in the page. Now, content could just manually hide the parts of the page in response to an event. Or you could provide a special media type or pseudo-class to use CSS to hide the unwanted content. But taking an element rather than a page full-screen has two benefits: 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 clean way. If content has to make layout changes by hand to limit itself to the specific fullscreen target, then it's extremely difficult, perhaps impossible, for the browser to do a single smooth animated transition without any unwanted flickering or layout thrash. We don't have a specific API proposal to make right now, but I'll try to get the people working on this to put forward a concrete proposal soon. Regards, Maciej On Dec 17, 2009, at 12:32 AM, Jonas Sicking wrote: On Thu, Dec 17, 2009 at 12:12 AM, Robert O'Callahan rob...@ocallahan.org wrote: 2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com 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. e.g. you have to cal fullscreen() in response to a user gesture, you immediately get fullscreened, It's really easy to get users to click on things. but maybe there's some dorky bar up top that stays around until you click go away or never put up the dork bar again for this site. Maybe... 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 that. / Jonas
Re: [whatwg] api for fullscreen()
On Thu, 17 Dec 2009 10:30:26 +0100, Maciej Stachowiak m...@apple.com 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 make a specific *element* go full screen, rather than the whole Web page. Some use cases for fullscreen will indeed want to transition the whole page, for example, let's say a Web-based editor wants to provide a distraction-free fullscreen mode like WriteRoom. However, it seems like many common use cases will benefit most from taking only part of the page full-screen, for example video or games, where it's common for the original content to only be a small box in the page. Now, content could just manually hide the parts of the page in response to an event. Or you could provide a special media type or pseudo-class to use CSS to hide the unwanted content. In Opera, @media projection targets full-screen mode. It's possible though that a page would want different styles when the whole page is in full screen and when an element is in full screen. But taking an element rather than a page full-screen has two benefits: 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 clean way. If content has to make layout changes by hand to limit itself to the specific fullscreen target, then it's extremely difficult, perhaps impossible, for the browser to do a single smooth animated transition without any unwanted flickering or layout thrash. We don't have a specific API proposal to make right now, but I'll try to get the people working on this to put forward a concrete proposal soon. Regards, Maciej -- Simon Pieters Opera Software
Re: [whatwg] api for fullscreen()
2009/12/17 Jonas Sicking jo...@sicking.cc: 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 annoying. I don't think going out of fullscreen is any more annoying than closing a popup, so I think the only issue is security. Requiring a click doesn't seem like it would do anything to stop spoofing, though. You could just put an onclick handler on the body. Users click on the page all the time, to follow links or select text. Spoofing seems like a hard problem for general-purpose full-screening. 2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com: maybe there's some dorky bar up top that stays around until you click go away or never put up the dork bar again for this site. So they only have to get you to watch one fullscreen video on their site and reflexively dismiss the dork bar before they can spoof you?
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 something by mistake else we will have a weak platform. We need to do what we can to educate and help as much as possible in the browsers. Following Flash blindly doesn't have to be good, but Flash *does* have great features for users and we shouldn't be blind to what they offer as a platform and take the best parts (and make it better). Cheers, Dion On Thu, Dec 17, 2009 at 3:33 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: 2009/12/17 Jonas Sicking jo...@sicking.cc: 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 annoying. I don't think going out of fullscreen is any more annoying than closing a popup, so I think the only issue is security. Requiring a click doesn't seem like it would do anything to stop spoofing, though. You could just put an onclick handler on the body. Users click on the page all the time, to follow links or select text. Spoofing seems like a hard problem for general-purpose full-screening. 2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com: maybe there's some dorky bar up top that stays around until you click go away or never put up the dork bar again for this site. So they only have to get you to watch one fullscreen video on their site and reflexively dismiss the dork bar before they can spoof you?
Re: [whatwg] api for fullscreen()
2009/12/16 Jonas Sicking jo...@sicking.cc: 2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: 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 screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian In addition to UI spoofing there is also the annoying websites factor. There is today API for pages to resize the browser window, which I know that some pages abuse to resize the browser window to be as big as possible. This API is one of very few that Firefox has specific API to turn off, because its one of the APIs that annoy users the most. As for flash going full screen. I heard something regarding that while in full screen mode flash disables certain capabilities, in order to reduce the risk of spoofing. Such as the ability to receive keyboard events. Haven't investigated this at all though. I looked into this when implementing fullscreen for O3D. Yes, they disable keyboard input entirely. That's acceptable for some applications, but quite limited for games, accessibility, etc. What we ended up doing was allowing the developer to designate a rectangular region of the window to be a clickable region that would trigger the fullscreen transition. When the user clicked it, we'd go fullscreen, then put up a banner for a few seconds that told them how to get out of it [hit Esc]. The Esc key was always the way out, intentionally matching Flash. The app developer was responsible for informing the user where to click, so that we didn't force a UI on them. Eric
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 permission to go full-screen. Why would that be better than the user just telling the UA to make the page full-screen directly? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] api for fullscreen()
On Thu, Dec 17, 2009 at 11:42 AM, Ian Hickson i...@hixie.ch 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 pop-ups) and then the user could grant that domain permission to go full-screen. Why would that be better than the user just telling the UA to make the page full-screen directly? -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' It may be used for full-screen playback of ogv/ogg videos (without using any addon - http://en.design-noir.de/mozilla/fullscreen-video/ ) Or something usefull to view a fullscreen image galary Or a svg/canvas Game. -- ┌─┐ │Narendra Sisodiya ( नरेन्द्र सिसोदिया ) │Society for Knowledge Commons │Web : http://narendra.techfandu.org └─┘
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 screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian 2009/12/16 Ian Hickson i...@hixie.ch 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 permission to go full-screen. Why would that be better than the user just telling the UA to make the page full-screen directly? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] api for fullscreen()
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: 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 screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian In addition to UI spoofing there is also the annoying websites factor. There is today API for pages to resize the browser window, which I know that some pages abuse to resize the browser window to be as big as possible. This API is one of very few that Firefox has specific API to turn off, because its one of the APIs that annoy users the most. As for flash going full screen. I heard something regarding that while in full screen mode flash disables certain capabilities, in order to reduce the risk of spoofing. Such as the ability to receive keyboard events. Haven't investigated this at all though. I'm also not sure what you mean by can probably figure out if they are in full-screen mode or not. How would you figure this out? Other than by installing a non-standard skin for your desktop or browser? / Jonas
Re: [whatwg] api for fullscreen()
2009/12/16 Jonas Sicking jo...@sicking.cc 2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: 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 screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian In addition to UI spoofing there is also the annoying websites factor. There is today API for pages to resize the browser window, which I know that some pages abuse to resize the browser window to be as big as possible. This API is one of very few that Firefox has specific API to turn off, because its one of the APIs that annoy users the most. You could tie it to user gestures, e.g. only allow a page to call fullscreen() in response to a user gesture, much as many browsers will block popups that do not result from a user gesture. Not perfect, but a large improvement. As for flash going full screen. I heard something regarding that while in full screen mode flash disables certain capabilities, in order to reduce the risk of spoofing. Such as the ability to receive keyboard events. Haven't investigated this at all though. correct I'm also not sure what you mean by can probably figure out if they are in full-screen mode or not. How would you figure this out? Other than by installing a non-standard skin for your desktop or browser? If you can only call fullscreen() in response to a user gesture, and there is some reasonably obvious thing that happens when you go full screen (hopefully a bit more obvious than what Flash currently does), then I'm hoping a sophisticated user who knows about noflash could figure out that they just went into fullscreen. As for the unsophisticated user, they're already at risk by flash, hopefully we could do better than flash, but if not, I think I would be willing to accept being on-par with Flash on this issue. / Jonas
Re: [whatwg] api for fullscreen()
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: 2009/12/16 Jonas Sicking jo...@sicking.cc 2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: 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 screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian In addition to UI spoofing there is also the annoying websites factor. There is today API for pages to resize the browser window, which I know that some pages abuse to resize the browser window to be as big as possible. This API is one of very few that Firefox has specific API to turn off, because its one of the APIs that annoy users the most. You could tie it to user gestures, e.g. only allow a page to call fullscreen() in response to a user gesture, much as many browsers will block popups that do not result from a user gesture. Not perfect, but a large improvement. As for flash going full screen. I heard something regarding that while in full screen mode flash disables certain capabilities, in order to reduce the risk of spoofing. Such as the ability to receive keyboard events. Haven't investigated this at all though. correct I'm also not sure what you mean by can probably figure out if they are in full-screen mode or not. How would you figure this out? Other than by installing a non-standard skin for your desktop or browser? If you can only call fullscreen() in response to a user gesture, and there is some reasonably obvious thing that happens when you go full screen (hopefully a bit more obvious than what Flash currently does), then I'm hoping a sophisticated user who knows about noflash could figure out that they just went into fullscreen. As for the unsophisticated user, they're already at risk by flash, hopefully we could do better than flash, but if not, I think I would be willing to accept being on-par with Flash on this issue. You need to ensure that the user is actively looking at the screen though. If the user is getting back to a screen that is now in fullscreen mode it seems hard to impossible to tell in the general case. Unless you slab a bar at the top screen that constantly says Fullscreen mode, take caution. I guess that if you enforced that fullscreen could only happen in response to a click then you are in better shape. I'd say you should try implementing this in chrome :) As for comparisons to flash, one of the goals of the mozilla project is to improve the web, not stay on par with flash ;) / Jonas
Re: [whatwg] api for fullscreen()
2009/12/16 Jonas Sicking jo...@sicking.cc 2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: 2009/12/16 Jonas Sicking jo...@sicking.cc 2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com: 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 screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). Obviously there are security considerations re: UI spoofing, but I'm beginning to wonder how much we should beat ourselves over this. If there are simple things that we can do to improve upon the model Flash uses (e.g. don't have a translucent overlay but instead use an opaque overlay, or use an overlay that doesn't go away until the user dismisses it, etc) without totally killing current use cases and discoverability, then let's consider that. Overall though, it feels like we are burying our head in the sand a bit by saying Well, as long as HTML doesn't provide a way to go full screen, the users are safe and it's not *our* fault if anything bad happens, when the reality is that Flash is installed on 98-99% of all machines out there and anyone who is really trying to phish people using this method could easily use flash instead of whatever we provide. (And yes I'm aware people can turn off flash, but those users sophisticated enough to use noflash can probably figure out if they are in full-screen mode or not.) -Ian In addition to UI spoofing there is also the annoying websites factor. There is today API for pages to resize the browser window, which I know that some pages abuse to resize the browser window to be as big as possible. This API is one of very few that Firefox has specific API to turn off, because its one of the APIs that annoy users the most. You could tie it to user gestures, e.g. only allow a page to call fullscreen() in response to a user gesture, much as many browsers will block popups that do not result from a user gesture. Not perfect, but a large improvement. As for flash going full screen. I heard something regarding that while in full screen mode flash disables certain capabilities, in order to reduce the risk of spoofing. Such as the ability to receive keyboard events. Haven't investigated this at all though. correct I'm also not sure what you mean by can probably figure out if they are in full-screen mode or not. How would you figure this out? Other than by installing a non-standard skin for your desktop or browser? If you can only call fullscreen() in response to a user gesture, and there is some reasonably obvious thing that happens when you go full screen (hopefully a bit more obvious than what Flash currently does), then I'm hoping a sophisticated user who knows about noflash could figure out that they just went into fullscreen. As for the unsophisticated user, they're already at risk by flash, hopefully we could do better than flash, but if not, I think I would be willing to accept being on-par with Flash on this issue. You need to ensure that the user is actively looking at the screen though. If the user is getting back to a screen that is now in fullscreen mode it seems hard to impossible to tell in the general case. Unless you slab a bar at the top screen that constantly says Fullscreen mode, take caution. tie to user gesture, or make it stay until the user actively dismisses it (click an x on it, i dunno). I guess that if you enforced that fullscreen could only happen in response to a click then you are in better shape. I'd say you should try implementing this in chrome :) As for comparisons to flash, one of the goals of the mozilla project is to improve the web, not stay on par with flash ;) yes, I'm all about improving it too. But at some point we need to stop throwing our hands up in the air and saying well, we will provide this safer way, which no one will use, and therefore we've made the web a better place. :) / Jonas
Re: [whatwg] api for fullscreen()
2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com 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 screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). We are also hearing this. Michael Dale's suggestion of using a passive, opt-in notification for this sounds reasonable to me. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] api for fullscreen()
2009/12/16 Robert O'Callahan rob...@ocallahan.org 2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com 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 screen button in YouTube, and when you take that away users can no longer figure out how to go full screen). We are also hearing this. Michael Dale's suggestion of using a passive, opt-in notification for this sounds reasonable to me. Rob 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.) I would much rather go for user gesture + opt-out. e.g. you have to cal fullscreen() in response to a user gesture, you immediately get fullscreened, but maybe there's some dorky bar up top that stays around until you click go away or never put up the dork bar again for this site. -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
