Re: [whatwg] Full screen for the video element
At 5:47 + 30/10/07, Ian Hickson wrote: Also, if the setting exists, it's far easier to trick users into setting it than if it doesn't. Out of curiousity, is an automatic switch to full screen without the user's consent considered an annoyance/usability problem or a security/fishing attack/vulnerability problem or both? FWIW, it's only the former IMO. The former, yes. I think if you can collect keystrokes then phishing is also on the cards, alas. If someone does ask why scripts can't switch to full screen, what would the reason(s) be? 1. There doesn't seem to be much demand for it. 2. It's not clear what would be the best way for UAs to provide the functionality while preventing sites from taking advantage of the feature and annoying users. Both, and also that it's considered ok for the user to have to tell the UA that he wants to go fullfreen (rather than the script having to tell the UA that the user wants to go fullscreen). I think there's both demand and precedent; and if it's not in the spec., as I say, it should be explicitly excluded with its reasons, so browser makers don't simply all add it as an extension. That way, we'd get all the problems again, plus an interoperability problem as well. -- David Singer Apple/QuickTime
Re: [whatwg] Full screen for the video element
On Tue, 30 Oct 2007, Dave Singer wrote: I think if you can collect keystrokes then phishing is also on the cards, alas. True. 2. It's not clear what would be the best way for UAs to provide the functionality while preventing sites from taking advantage of the feature and annoying users. Both, and also that it's considered ok for the user to have to tell the UA that he wants to go fullfreen (rather than the script having to tell the UA that the user wants to go fullscreen). I think there's both demand and precedent; and if it's not in the spec., as I say, it should be explicitly excluded with its reasons, so browser makers don't simply all add it as an extension. That way, we'd get all the problems again, plus an interoperability problem as well. Good point. Added a note. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
On Oct 30, 2007 9:20 PM, Dave Singer [EMAIL PROTECTED] wrote: I think if you can collect keystrokes then phishing is also on the cards, alas. FWIW, Flash and Silverlight try to address this by leaving full-screen mode when keys are pressed. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Full screen for the video element
If we don't have a way for content to request full screen (markup, script, whatever), I'm OK with that. But I think that we should say why we left it out, in the spec., and not be silent. Otherwise we'll merely see browser makers doing their own extensions to do it anyway, and then we'll also have non-interoperable methods as well as the security issues... -- David Singer Apple/QuickTime
Re: [whatwg] Full screen for the video element
Ivo Emanuel Gonçalves wrote: As far as I understand this issue, the best solution is to leave it up to the user-agent. If they want to provide a full screen option let them have it. If users find it annoying or if it's heavily abused, they either disable it or move to another browser that knows what it's doing(tm). Basically, full screen video should be a client thing. The HTML 5 spec should merely suggest user-agents not to start in full screen mode by default. I think that's a good compromise. Not elegant, but probably works. Agreed. However I wasn't talking about fullscreen in my previous email in this thread. I was talking about full-window. Something that has entierly different security constraints and something that webpages will be able to do even if we don't provide an API. But as I said, I'm fine with leaving full-window to a later version of the spec if we see there's a need for it. / Jonas
Re: [whatwg] Full screen for the video element
On 10/29/07, Dave Singer [EMAIL PROTECTED] wrote:
If we don't have a way for content to request full screen (markup,
script, whatever), I'm OK with that. But I think that we should say
why we left it out, in the spec., and not be silent. Otherwise we'll
merely see browser makers doing their own extensions to do it anyway,
and then we'll also have non-interoperable methods as well as the
security issues...
--
David Singer
Apple/QuickTime
I could imagine it this way:
Global javascript option: allow scripts to enable full screen for
video element = (default unchecked)
user-created site preference for cool.site.com: allow scripts to
enable full screen for video element = checked
Then, the trusted pages could use if (video.canToggleFullScreen()) to
see if they are allowed to toggle full screen. Then, they would use
video.toggleFullScreen() to automatically turn on full screen (they
might use a stored cookie preference or whatever) and or provide a
full screen button on the page.
I could imagine that easily working in Opera and FF3 with site preferences.
The spec would just have to support canToggleFullScreen() and
toggleFullScreen(). It would not have to mention site preferences
specifically. Maybe just recommend that it should be turned off by
default and recommend that UAs supporting toggleFullScreen() should
provide *some* mechanism to enable it on a per-site basis.
A tiny issue with toggleFullScreen() is that if a button on the page
is provided, once you're in full screen, you'll have to use the
browser-provided way to get out. But, toggleFullScreen() would still
be useful for the script to switch back to normal view automatically
when the clip is done playing or toggle for certain clips.
One thing with toggleFullScreen() that might not be funny would be:
while(1) {
video.toggleFullScreen();
}
If so, then perhaps it should not be a toggle and only be
enableFullScreen() (which would do nothing if already in full screen,
which would also make more sense for the tiny button issue mentioned
above, but would make coming out of full screen not possible by the
script.)
Now, for me personally, I just want to be able to double-left-click on
the video area to enter full screen and then do the same in full
screen (or esc) to get back. I probably wouldn't want to automatically
enter full screen. However, sites and others might want that and it
might be cool.
Either way it seems like there's an acceptable way to allow scripts to
switch to full screen, if there's a need for it.
--
Michael
Re: [whatwg] Full screen for the video element
On Sat, 27 Oct 2007, Ivo Emanuel Gonçalves wrote: As far as I understand this issue, the best solution is to leave it up to the user-agent. If they want to provide a full screen option let them have it. If users find it annoying or if it's heavily abused, they either disable it or move to another browser that knows what it's doing(tm). Basically, full screen video should be a client thing. The HTML 5 spec should merely suggest user-agents not to start in full screen mode by default. I think that's a good compromise. Not elegant, but probably works. Agreed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
At 23:39 -0500 25/10/07, Greg Houston wrote: Roughly, one solution might be: The user is playing a video within a web page. They click on full screen mode. You are describing something initiated by user action, which any browser is quite free to support. But if that user action is mediated through HTML, or the fullscreen request originates in the HTML, the position is rather harder. What you write below is only 'obviously' an embedded video for a few seconds, alas. But the question remains: should we provide standard markup to do fullscreen, since most browsers will provide an extension to do it anyway, or not? And if so, how much do we say about the security issues (and what)? And if not, how do we still need to say about the security issues for browsers that do it anyway through UI, extension, or both? The toolbar, status bar, menu bar, and so forth are removed, leaving just the title bar and close, minimize, and restore controls. If there is no movement of the mouse for 2-5 seconds the title bar disappears. With movement of the mouse again, the title bar reappears. If the user clicks on the close control, the window returns to its original state while continuing to play the video within the page. Also, If the video comes to an end the window returns to its original state. If you don't want the title bar to control closing full screen mode, the browser could display a special video bar during full screen mode directly underneath the title bar. This bar could have play controls on it. Again, the video bar (as well as the title bar) would disappear after so many seconds of no mouse movement. In addition to redisplaying the title bar (and potentially the video bar) on mouse movement, it might be helpful to have a way to overlay play controls (pause, stop, and so forth) on top of the video at this time giving the designer a way to add those controls or supplement those that would be in the video bar if the video bar was implemented. Standard hotkeys in full screen mode might be nice, e.g., space bar (play, pause). With javascript it is already possible to make full screen web pages. If advertisers were going to exploit this they would have by now. Standardizing full screen video mode seems like a good idea since users will learn what to expect and how to navigate it. Otherwise, you potentially have a 1000 different implementations of fullscreen mode devised by designers requiring the end user to figure out each time how to navigate that particular implementation. On 10/25/07, Jonas Sicking [EMAIL PROTECTED] wrote: Dave Singer wrote: At 19:50 -0700 25/10/07, Jonas Sicking wrote: Dave Singer wrote: At 0:48 + 26/10/07, Ian Hickson wrote: On Sat, 13 Oct 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). Given how often popups are abused today even with those requirements, I hesitate to do this. (Can you imagine if every time you clicked a link to go to a new site, a full-window or full-screen advert played?) If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. I just can't think of a solution that doesn't fall into at least one of these categories: 1) Some sort of user-confirmation that most users will not understand (such as the dialog) 2) Uses annoying ugly UI that will make no sites want to use it (such as a blinking red border) 3) Is unsafe 4) Will be annoying since advertisers are going to abuse it. You may be right. But a lack of imagination on my part may not be a good reason to leave out the feature,
Re: [whatwg] Full screen for the video element
Greg Houston wrote: With javascript it is already possible to make full screen web pages. If advertisers were going to exploit this they would have by now. On my browser it is not. In firefox I can and do disable the ability for javascript to move or resize windows because web pages insist on annoying me by resizing to fullscreen. The only reason we don't disable this by default in firefox is that a lot of sites have come to depend on being able to resize windows. So lots of users are paying the price of annoying maximizing windows in order for us to support the few legitimate websites that resize windows. Had the resize api not been there in the first place those legitimate websites would have come to depend on it and would have worked fine. Lets not do the same mistake again. Standardizing full screen video mode seems like a good idea since users will learn what to expect and how to navigate it. Otherwise, you potentially have a 1000 different implementations of fullscreen mode devised by designers requiring the end user to figure out each time how to navigate that particular implementation. I imagine what will happen is that pages will create a video that covers the whole content area of the current window and then have some mechanism that minimizes the video again. I could see an argument for having an API that maximizes the video within the content area of the current window and adds some sort of browser specific UI to minimize it again. However, it isn't clear that sites will prefer that over having their users choose 'fullscreen' from the context menu (or whatever other UI the browser chooses to use). Actually, the more I think about it the more I like the idea of an API for fullwindow. What do other people think? / Jonas
Re: [whatwg] Full screen for the video element
On Fri, 26 Oct 2007, Dave Singer wrote: If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. In general I agree, but when we don't have a single solution we can think of that's any good, it seems highly experimental (and thus inappropriate for HTML5) to have the requirement in the spec. On Thu, 25 Oct 2007, Jonas Sicking wrote: I just can't think of a solution that doesn't fall into at least one of these categories: 1) Some sort of user-confirmation that most users will not understand (such as the dialog) 2) Uses annoying ugly UI that will make no sites want to use it (such as a blinking red border) 3) Is unsafe 4) Will be annoying since advertisers are going to abuse it. Neither can I. On Fri, 26 Oct 2007, Dave Singer wrote: You may be right. But a lack of imagination on my part may not be a good reason to leave out the feature, unless we are fairly sure that the feature cannot be implemented with the requirement for phishing protection in an acceptable way, ever, at all. Actually, lack of imagination on everyone's part _is_ a good reason to leave out a feature. We shouldn't be using HTML standardisation as a research lab, we should be standardising things we know work. On Thu, 25 Oct 2007, Jonas Sicking wrote: I'd say it's the other way around. We shouldn't include features that we can't think of a way to implement them. Right. On Thu, 25 Oct 2007, Greg Houston wrote: Roughly, one solution might be: The user is playing a video within a web page. They click on full screen mode. The toolbar, status bar, menu bar, and so forth are removed, leaving just the title bar and close, minimize, and restore controls. If there is no movement of the mouse for 2-5 seconds the title bar disappears. With movement of the mouse again, the title bar reappears. If the user clicks on the close control, the window returns to its original state while continuing to play the video within the page. Also, If the video comes to an end the window returns to its original state. If you don't want the title bar to control closing full screen mode, the browser could display a special video bar during full screen mode directly underneath the title bar. This bar could have play controls on it. Again, the video bar (as well as the title bar) would disappear after so many seconds of no mouse movement. In addition to redisplaying the title bar (and potentially the video bar) on mouse movement, it might be helpful to have a way to overlay play controls (pause, stop, and so forth) on top of the video at this time giving the designer a way to add those controls or supplement those that would be in the video bar if the video bar was implemented. Standard hotkeys in full screen mode might be nice, e.g., space bar (play, pause). That's what the spec has now. The user has to tell the UA to go full-screen. With javascript it is already possible to make full screen web pages. If advertisers were going to exploit this they would have by now. Actually, they can't, as far as I can tell. Standardizing full screen video mode seems like a good idea since users will learn what to expect and how to navigate it. Otherwise, you potentially have a 1000 different implementations of fullscreen mode devised by designers requiring the end user to figure out each time how to navigate that particular implementation. You only need one implementation -- the user agent's. It just means you can't have little JavaScript UI to trigger it, but I think that's ok. On Fri, 26 Oct 2007, Dave Singer wrote: But the question remains: should we provide standard markup to do fullscreen, since most browsers will provide an extension to do it anyway, or not? And if so, how much do we say about the security issues (and what)? And if not, how do we still need to say about the security issues for browsers that do it anyway through UI, extension, or both? Through UI there's not really a security problem. Through an extension, that's up to the UA. We can't mention all the ways that UAs can shoot themselves through the foot. If an extension turns out to be good, then we can spec it. On Fri, 26 Oct 2007, Jonas Sicking wrote: I imagine what will happen is that pages will create
Re: [whatwg] Full screen for the video element
On Sat, 13 Oct 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). Given how often popups are abused today even with those requirements, I hesitate to do this. (Can you imagine if every time you clicked a link to go to a new site, a full-window or full-screen advert played?) If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
At 0:48 + 26/10/07, Ian Hickson wrote: On Sat, 13 Oct 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). Given how often popups are abused today even with those requirements, I hesitate to do this. (Can you imagine if every time you clicked a link to go to a new site, a full-window or full-screen advert played?) If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. -- David Singer Apple/QuickTime
Re: [whatwg] Full screen for the video element
Dave Singer wrote: At 0:48 + 26/10/07, Ian Hickson wrote: On Sat, 13 Oct 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). Given how often popups are abused today even with those requirements, I hesitate to do this. (Can you imagine if every time you clicked a link to go to a new site, a full-window or full-screen advert played?) If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. I just can't think of a solution that doesn't fall into at least one of these categories: 1) Some sort of user-confirmation that most users will not understand (such as the dialog) 2) Uses annoying ugly UI that will make no sites want to use it (such as a blinking red border) 3) Is unsafe 4) Will be annoying since advertisers are going to abuse it. / Jonas
Re: [whatwg] Full screen for the video element
At 19:50 -0700 25/10/07, Jonas Sicking wrote: Dave Singer wrote: At 0:48 + 26/10/07, Ian Hickson wrote: On Sat, 13 Oct 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). Given how often popups are abused today even with those requirements, I hesitate to do this. (Can you imagine if every time you clicked a link to go to a new site, a full-window or full-screen advert played?) If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. I just can't think of a solution that doesn't fall into at least one of these categories: 1) Some sort of user-confirmation that most users will not understand (such as the dialog) 2) Uses annoying ugly UI that will make no sites want to use it (such as a blinking red border) 3) Is unsafe 4) Will be annoying since advertisers are going to abuse it. You may be right. But a lack of imagination on my part may not be a good reason to leave out the feature, unless we are fairly sure that the feature cannot be implemented with the requirement for phishing protection in an acceptable way, ever, at all. -- David Singer Apple/QuickTime
Re: [whatwg] Full screen for the video element
Dave Singer wrote: At 19:50 -0700 25/10/07, Jonas Sicking wrote: Dave Singer wrote: At 0:48 + 26/10/07, Ian Hickson wrote: On Sat, 13 Oct 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). Given how often popups are abused today even with those requirements, I hesitate to do this. (Can you imagine if every time you clicked a link to go to a new site, a full-window or full-screen advert played?) If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. I just can't think of a solution that doesn't fall into at least one of these categories: 1) Some sort of user-confirmation that most users will not understand (such as the dialog) 2) Uses annoying ugly UI that will make no sites want to use it (such as a blinking red border) 3) Is unsafe 4) Will be annoying since advertisers are going to abuse it. You may be right. But a lack of imagination on my part may not be a good reason to leave out the feature, unless we are fairly sure that the feature cannot be implemented with the requirement for phishing protection in an acceptable way, ever, at all. I'd say it's the other way around. We shouldn't include features that we can't think of a way to implement them. / Jonas
Re: [whatwg] Full screen for the video element
Roughly, one solution might be: The user is playing a video within a web page. They click on full screen mode. The toolbar, status bar, menu bar, and so forth are removed, leaving just the title bar and close, minimize, and restore controls. If there is no movement of the mouse for 2-5 seconds the title bar disappears. With movement of the mouse again, the title bar reappears. If the user clicks on the close control, the window returns to its original state while continuing to play the video within the page. Also, If the video comes to an end the window returns to its original state. If you don't want the title bar to control closing full screen mode, the browser could display a special video bar during full screen mode directly underneath the title bar. This bar could have play controls on it. Again, the video bar (as well as the title bar) would disappear after so many seconds of no mouse movement. In addition to redisplaying the title bar (and potentially the video bar) on mouse movement, it might be helpful to have a way to overlay play controls (pause, stop, and so forth) on top of the video at this time giving the designer a way to add those controls or supplement those that would be in the video bar if the video bar was implemented. Standard hotkeys in full screen mode might be nice, e.g., space bar (play, pause). With javascript it is already possible to make full screen web pages. If advertisers were going to exploit this they would have by now. Standardizing full screen video mode seems like a good idea since users will learn what to expect and how to navigate it. Otherwise, you potentially have a 1000 different implementations of fullscreen mode devised by designers requiring the end user to figure out each time how to navigate that particular implementation. On 10/25/07, Jonas Sicking [EMAIL PROTECTED] wrote: Dave Singer wrote: At 19:50 -0700 25/10/07, Jonas Sicking wrote: Dave Singer wrote: At 0:48 + 26/10/07, Ian Hickson wrote: On Sat, 13 Oct 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). Given how often popups are abused today even with those requirements, I hesitate to do this. (Can you imagine if every time you clicked a link to go to a new site, a full-window or full-screen advert played?) If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. Indeed (and explicit confirmation is pretty bad UI). But you don't need to tell the browser that explicit confirmation is required; you merely need to say that, if the browser supports fullscreen requests (and it may ignore them), it must be clear to the user that the screen is 'filled' with the video and not his normal desktop. Yes, a dialog before is one way, but so is, for example, a blinking red 10-pixel border around the screen that says security warning! do not treat as desktop! continuously. There are (I hope) better designs. :-) i.e. state the requirement, not the solution. I just can't think of a solution that doesn't fall into at least one of these categories: 1) Some sort of user-confirmation that most users will not understand (such as the dialog) 2) Uses annoying ugly UI that will make no sites want to use it (such as a blinking red border) 3) Is unsafe 4) Will be annoying since advertisers are going to abuse it. You may be right. But a lack of imagination on my part may not be a good reason to leave out the feature, unless we are fairly sure that the feature cannot be implemented with the requirement for phishing protection in an acceptable way, ever, at all. I'd say it's the other way around. We shouldn't include features that we can't think of a way to implement them. / Jonas
Re: [whatwg] Full screen for the video element
Le Sat, 13 Oct 2007 00:34:26 +0300, Ian Hickson [EMAIL PROTECTED] a écrit: On Wed, 21 Mar 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) Yep, that's a problem. I was also thinking along the lines of allowing fullscreen() within non-synthetic event handlers, in a similar fashon to popups (just like Kornel suggested). If that's not a desirable solution, then other solutions, which don't require confirmation, are not easy to find. -- Mihai Sucan http://www.robodesign.ro
Re: [whatwg] Full screen for the video element
On Wed, 21 Mar 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
On Wed, 21 Mar 2007, Martin Hassman wrote: I feel conflict here: a) UA provide some Fullscreen item in popup menu (from the discussion seems for me that there shouldn't be any UA-GUI in page than popup menu) b) web author give some Fullscreen button inside his video controls (to look it like youtube etc.) If for b) author doesn't have API and make it owns way, there will be two independent fullscreens for every video. 1st way the browser allows fullscreen and 2nd way the page author make fullscreen. I would posit that if user agents provided for a native full-screen mode, sites would stop providing their own workaround. Fullscreen here does not necessary mean switching browser to fullscreen mode, look e.g. like youtube has it. I'm sure YouTube would _rather_ just have a way to go fullscreen, though. The current feature is but a poor workaround. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
On Wed, 21 Mar 2007, Kornel Lesinski wrote:
Couldn't this be protected in a similar way pop-up blocking works? If
not, browsers could simply display confirmation dialog box before
entering fullscreen (some sort of protection is neccessary to protect
against phishing and annoyance).
The popup blocking is highly inadequate, sadly. It isn't a model we really
want to follow.
Displaying a confirmation dialog is considered poor UI.
I think Mihai has a valid point here -- if there's no API for
fullscreen, custom players won't be able to provide UI for it or will
try to fake it.
Why would the UA's own fullscreen UI not be eough?
I suggest adding fullscreen() (toggleFullscreen? enterFullscreen?)
method that returns false if UA refused to enter fullscreen:
if (!video.fullscreen())
{
openVideoInLargePopupInstead();
}
In practice such an API would simply always return false.
On Thu, 22 Mar 2007, Gervase Markham wrote:
Indeed. But it would be good to have an event which triggers when the
user chooses to go full screen, so the page can e.g. hide headers and
borders. (Or perhaps the onresize() event on the body already does
that?).
The 'projection' media type is probably the best solution for this.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
Simon Pieters wrote: Browsers are allowed to provide full screen, however there's no API for it. Entering fullscreen should only be under the control of the user, otherwise the author could hijack the user's screen and no way to get out of it (e.g. as soon as the user tries to exit fullscreen, the script goes back to fullscreen). Indeed. But it would be good to have an event which triggers when the user chooses to go full screen, so the page can e.g. hide headers and borders. (Or perhaps the onresize() event on the body already does that?). Gerv
Re: [whatwg] Full screen for the video element
Simon Pieters wrote: On Wed, 21 Mar 2007 20:11:57 +0100, Mihai Sucan [EMAIL PROTECTED] wrote: Shouldn't the video API include a way to toggle full screen on/off? Browsers are allowed to provide full screen, however there's no API for it. Entering fullscreen should only be under the control of the user, Agreed. There is no reason to provide an API for this. Some video plugins already allow the user to go to full screen. See this site that I found: http://www.muvids.com/ It appears to require the Windows Media Player plugin. In Firefox, Opera and IE, I was able to enter full screen by double clicking the video or selecting from the context menu. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Full screen for the video element
Gervase Markham wrote: Simon Pieters wrote: Browsers are allowed to provide full screen, however there's no API for it. Entering fullscreen should only be under the control of the user, otherwise the author could hijack the user's screen and no way to get out of it (e.g. as soon as the user tries to exit fullscreen, the script goes back to fullscreen). Indeed. But it would be good to have an event which triggers when the user chooses to go full screen, so the page can e.g. hide headers and borders. (Or perhaps the onresize() event on the body already does that?). Hmm. Perhaps you and I have different ideas about what is meant by full screen, but why would a page need to hide anything when the video is full screen? The page itself won't be visible, because the video will be taking up the entire screen! For the purposes of having video take up the entire space on my monitor, the page doesn't need to be any the wiser... it can go on thinking I'm viewing it in the little box on their site. An interesting point to note, though, is that this sort of full-screen switch effectively allows the user to bypass any overlaid ads/captions/UI that the site may provide.
Re: [whatwg] Full screen for the video element
Martin Atkins wrote: Perhaps you and I have different ideas about what is meant by full screen, but why would a page need to hide anything when the video is full screen? The page itself won't be visible, because the video will be taking up the entire screen! My thought was that it would be the same function as the current full screen that the browser has. I.e. the page says For full-screen, press F11. The user presses F11 and the browser makes the window full-screen, and additionally tells the page that this has happened via an event, so it can arrange to make the appropriate content fill the entire viewport. (Or not, if they want to continue to display captions, or ads, or a set of links). This is a simple solution which is integrated with existing browser functionality and controls and is not specific to video. Gerv
Re: [whatwg] Full screen for the video element
You are confusing Internet Explorer with a web browser. By that I mean that you obviously use IE and aren't considering other UA's, including mobile devices. Certainly Firefox and Safari on the Mac I am currently using don't support this 'feature'. Gaz On 22 Mar 2007, at 14:16, Gervase Markham wrote: Martin Atkins wrote: Perhaps you and I have different ideas about what is meant by full screen, but why would a page need to hide anything when the video is full screen? The page itself won't be visible, because the video will be taking up the entire screen! My thought was that it would be the same function as the current full screen that the browser has. I.e. the page says For full- screen, press F11. The user presses F11 and the browser makes the window full-screen, and additionally tells the page that this has happened via an event, so it can arrange to make the appropriate content fill the entire viewport. (Or not, if they want to continue to display captions, or ads, or a set of links). This is a simple solution which is integrated with existing browser functionality and controls and is not specific to video. Gerv
Re: [whatwg] Full screen for the video element
On 22/03/07, Gareth Hay [EMAIL PROTECTED] wrote: You are confusing Internet Explorer with a web browser. By that I mean that you obviously use IE and aren't considering other UA's, including mobile devices. Funny that you would say that about somebody with a @mozilla.org address... I'm sure Gervase just doesn't use a Mac, so he hasn't felt how lacking the support for full screen mode is in Mac browsers. -- David liorean Andersson
Re: [whatwg] Full screen for the video element
Gareth Hay wrote: On 22 Mar 2007, at 14:16, Gervase Markham wrote: My thought was that it would be the same function as the current full screen that the browser has. I.e. the page says For full-screen, press F11. The user presses F11 and the browser makes the window full-screen... You are confusing Internet Explorer with a web browser. You are confusing a Mozilla developer with an IE user. By that I mean that you obviously use IE and aren't considering other UA's, including mobile devices. What are you talking about? Several browsers provide full screen capabilities, including at least Firefox (Win) and Opera (Win and Mac). And last time I used a mobile device, it took the entire screen real estate by default. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Full screen for the video element
liorean wrote: I'm sure Gervase just doesn't use a Mac, so he hasn't felt how lacking the support for full screen mode is in Mac browsers. It's true that I don't use a Mac. However, I think it's a reasonable position that the idea of going to full screen is a user agent thing (no matter what type of UA it is, even mobile) but that content should be able to respond appropriately when users make that change. If this sucks on Firefox on the Mac, we need to fix Firefox on the Mac. [The only problem might occur if there was an OS whereby every app was always full screen, and so such a function would make no sense.] Whether switching to CSS projection is the right thing to do I'll leave to the CSS experts, but I do think there should be an event. Gerv
Re: [whatwg] Full screen for the video element
By that I mean that you obviously use IE and aren't considering other UA's, including mobile devices. What are you talking about? Several browsers provide full screen capabilities, including at least Firefox (Win) and Opera (Win and Mac). And last time I used a mobile device, it took the entire screen real estate by default. P990i, by default is portrait display, switching to landscape does provide a 'fullscreen' mode, but hey, don't let a valid point get in the way of the argument! I really don't understand this attitude, it was a very clear point, pressing F11 in a *large* number of browsers does not provide a 'fullscreen' mode. I mean, how many mobile devices even have an F11? Besides, this is what I would consider as the 'correct' implementation, from [EMAIL PROTECTED] : Perhaps you and I have different ideas about what is meant by full screen, but why would a page need to hide anything when the video is full screen? The page itself won't be visible, because the video will be taking up the entire screen! Gaz
Re: [whatwg] Full screen for the video element
On Thu, 22 Mar 2007 15:51:31 +0100, Gareth Hay [EMAIL PROTECTED] wrote: P990i, by default is portrait display, switching to landscape does provide a 'fullscreen' mode, but hey, don't let a valid point get in the way of the argument! I really don't understand this attitude, it was a very clear point, pressing F11 in a *large* number of browsers does not provide a 'fullscreen' mode. I mean, how many mobile devices even have an F11? Note that 'fullscreen' and 'fullscreen' are two different things: 1. A fullscreen mode on desktop should typically be a paged media, applying any 'projection' style sheets to the page 2. The fullscreen mode on Sony Ericsson P990i, M600i and a number of other UIQ phones still apply 'handheld' if existent, or 'screen' if so set in the user's preferences. The 'fullscreen' mode on these devices just happens to use all of your viewport, but it is not 'fullscreen' in the sense you'd think. -- Arve Bersvendsen, Web Applications Developer Opera Software ASA, http://www.opera.com/
Re: [whatwg] Full screen for the video element
Arve Bersvendsen wrote: Note that 'fullscreen' and 'fullscreen' are two different things: 1. A fullscreen mode on desktop should typically be a paged media, applying any 'projection' style sheets to the page 2. The fullscreen mode on Sony Ericsson P990i, M600i and a number of other UIQ phones still apply 'handheld' if existent, or 'screen' if so set in the user's preferences. The 'fullscreen' mode on these devices just happens to use all of your viewport, but it is not 'fullscreen' in the sense you'd think. As an Opera user I realise that this is already implemented and deployed, but I do think that taking projection to mean fullscreen is a bit of an abuse of that media type. If I press F11 in my browser, my 17 monitor doesn't suddenly turn into a projector. When I think of full screen I generally mean make the page take up the whole screen -- hide the browser chrome, not turn this web page into a slide-show. Not that Opera's feature isn't useful: I'd just prefer it were called Projection Mode and not Full Screen to avoid this very confusion that you've called out in your message. Too late now though, I guess!
Re: [whatwg] Full screen for the video element
On 22 Mar 2007, at 14:16, Gervase Markham wrote: Martin Atkins wrote: Perhaps you and I have different ideas about what is meant by full screen, but why would a page need to hide anything when the video is full screen? The page itself won't be visible, because the video will be taking up the entire screen! My thought was that it would be the same function as the current full screen that the browser has. I.e. the page says For full- screen, press F11. The user presses F11 and the browser makes the window full-screen, Does this hide the menubar/taskbar/widgets, darken other screens (I have three) or anything along those lines, and resize the browser window? To me full screen mode for video would not alter the browser window size, instead it would cover the screen in a new window and draw just the video into that. The browser window would be left untouched below (though the video may no longer be rendering into it). I would also like to be able to drag the full-screen video to a secondary monitor, switch back to the browser window and keep browsing (perhaps in another tab or read the rest of the page). The video would keep playing full-screen on the other screen until I closed the originating tab, the video ends, or I stop playback. - Nicholas. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Full screen for the video element
Gareth Hay wrote: I really don't understand this attitude, it was a very clear point, pressing F11 in a *large* number of browsers does not provide a 'fullscreen' mode. I mean, how many mobile devices even have an F11? Er, F11 was an example (that's what it is in Firefox). I could have said press whatever key or take whatever user action is necessary to invoke the browser's mode where it occupies the entire screen, but I thought that people would have understood what I mean. It seems not. My assertion is that the idea of going to full screen (i.e. removing all chrome and allowing the content to take up as much space as possible) is a fairly common browser thing. Of course, those with a wider experience of browser implementations than I may well tell me I'm wrong. Gerv
Re: [whatwg] Full screen for the video element
Nicholas Shanks wrote: What is chrome ? I mean, I know what it really is, but that seems to have nothing to do with computers or web browsers (except for the chromium-coloured iPod phone). Sorry. It means things like toolbars, menu bars, status bars and other non-content-area UI. Gerv
Re: [whatwg] Full screen for the video element
As my last word on this pointless bit of the thread, I'm going to spell it out Your thread: Martin Atkins wrote: Perhaps you and I have different ideas about what is meant by full screen, but why would a page need to hide anything when the video is full screen? The page itself won't be visible, because the video will be taking up the entire screen! My thought was that it would be the same function as the current full screen that the browser has. I.e. the page says For full- screen, press F11. The user presses F11 and the browser makes the window full-screen, and additionally tells the page that this has happened via an event, so it can arrange to make the appropriate content fill the entire viewport. (Or not, if they want to continue to display captions, or ads, or a set of links). I was agreeing with Martin and disagreeing with you. Fullscreen video should be like that of a media player, think VLC, Quicktime, DVD Player(on the Mac), Cyber-whatever, you choose fullscreen, all you get is the video. I think it should be like this, as you are telling the video element to go fullscreen and *not* the page. That's my opinion. On 22 Mar 2007, at 16:02, Gervase Markham wrote: Gareth Hay wrote: I really don't understand this attitude, it was a very clear point, pressing F11 in a *large* number of browsers does not provide a 'fullscreen' mode. I mean, how many mobile devices even have an F11? Er, F11 was an example (that's what it is in Firefox). I could have said press whatever key or take whatever user action is necessary to invoke the browser's mode where it occupies the entire screen, but I thought that people would have understood what I mean. It seems not. I hope with this last comment you are attempting to be as humerous as I was when I made the IE quip. Gaz
Re: [whatwg] Full screen for the video element
Gareth Hay wrote: I think it should be like this, as you are telling the video element to go fullscreen and *not* the page. That's my opinion. I guess that's the heart of it. My view is the opposite. I don't think video should be special in this regard. If you want to see an embedded image full screen, you do View Image, then Full Screen. Why can video not be the same? Of course, the page should have the option (with the event I mentioned) of making doing Full Screen for the browser Do The Right Thing with the video, if they think that's what the Right Thing is. And maybe that would become the norm on video sharing sites. Gerv
Re: [whatwg] Full screen for the video element
On 3/22/07, Gervase Markham [EMAIL PROTECTED] wrote: However, I think it's a reasonable position that the idea of going to full screen is a user agent thing (no matter what type of UA it is, even mobile) but that content should be able to respond appropriately when users make that change. If this sucks on Firefox on the Mac, we need to fix Firefox on the Mac. Sorry. Some of us use devices where full screen is um... 800x480. And the reason I choose to use full screen is not because I want content to randomly shift to some magical playback mode. It's just because I need to see more of the content (not less!). Please don't hurt my users (they're using Opera in case you're curious). It's bad enough that my screen can sometimes be closer to 800x220 (that's basically full screen + find + location + vkb on the 770/n800). [The exact pixel value is probably off by 2.] [The only problem might occur if there was an OS whereby every app was always full screen, and so such a function would make no sense.] I think instead of saying full screen here, you should have said maximized since as it turns out, there are at least 3 meanings for full screen, and overloading them seems to cause a lot of confusion :(. On the 770/n800, apps are always maximized. They're either maximized with no borders (classical full screen), or they're maximized with fairly wide borders (something like . The only resizing cases happen in things which for the most part *shouldn't* be sent to web pages (because the results are really bad :( ). Unfortunately this is mostly a design decision by some UI Engineers in some other group and the Input Method developers (IMEs really shouldn't cause window resize, it should float, but I'm not in control of that group ...). Whether switching to CSS projection is the right thing to do I'll leave to the CSS experts, but I do think there should be an event. Gareth later asks how many devices have fullscreen modes w/ F11 bindings. The Nokia 770/n800 use F6 (yes, they clearly didn't research web browsers before they picked it, but there is a control panel thing to configure it) [there's also of course a button on the device that switches to full screen, but he seemed to be particularly curious about f11...].
Re: [whatwg] Full screen for the video element
Gervase Markham wrote: My assertion is that the idea of going to full screen (i.e. removing all chrome and allowing the content to take up as much space as possible) is a fairly common browser thing. Of course, those with a wider experience of browser implementations than I may well tell me I'm wrong. I very rarely want to view web pages full-screen, but I almost always watch video full-screen. I want a browser to allow me to scale the video over the entire screen without the site having to explicitly support it.
Re: [whatwg] Full screen for the video element
On 22/03/07, Martin Atkins [EMAIL PROTECTED] wrote: Incidentally, although I'm in favour of the full-screen feature under discussion being for full-screen *video*, not full-screen pages, I'm not arguing that this should be mandated by the spec. This is something that browsers could choose to offer, just as they could choose to offer full-screen images as you mention in your example. Given that showing a video or image full-screen requires no co-operation from the page it was embedded on, it doesn't need to be in the spec. It's a browser implementation detail. It doesn't require cooperation if included in the the UA UI, no, but what if the page opts to provide it's own UI? Then it would be nice if that feature could be reached from the API in those cases it does exist (and whether it exists or not should be discoverable), rather than them not being able to include that functionality at all, or hacking it together by stopping the playback in the original window and opening a new fullscreen window with another copy of the video in. Especially if one wants to switch in the middle of the a video, keeping the playback going without interuption. -- David liorean Andersson
Re: [whatwg] Full screen for the video element
On 3/22/07, Nicholas Shanks [EMAIL PROTECTED] wrote: To me full screen mode for video would not alter the browser window size, instead it would cover the screen in a new window and draw just the video into that. The browser window would be left untouched below (though the video may no longer be rendering into it). I kind of figured it'd be like that also. When you switch to full screen, the window would stay the same size. The embedded video would switch off and the video overlay would appear and cover the whole screen. -- burnout426
[whatwg] Full screen for the video element
Hello! Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. I'd suggest adding a new property to the HTMLVideoElement interface: the .fullscreen boolean. This should be used to toggle full screen video rendering. The way this works should be left at the discretion of the UA: it can be real full screen, or only full screen within the viewport. The UA must be required to provide a way to exit the full screen mode. (pardon me if this was already discussed on the mailing list) -- http://www.robodesign.ro ROBO Design - We bring you the future
