Re: [whatwg] api for fullscreen()

[David Singer]

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()

[Kit Grose]

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()

[David Singer]

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()

[Brian Campbell]

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 th

Re: [whatwg] api for fullscreen()

[Smylers]

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()

[Kit Grose]

> 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]

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()

[Smylers]

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()

[Aryeh Gregor]

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

I'd hope that browsers don't go with 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()

[Brian Campbell]

On Feb 1, 2010, at 5:38 PM, Robert O'Callahan wrote:

> On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell  
> wrote:
> I'm a bit concerned about when the fullscreen events and styles apply, 
> though. If the page can tell whether or not the user has actually allowed it 
> to enter fullscreen mode, 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()

[Robert O'Callahan]

On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell wrote:

> I'm a bit concerned about when the fullscreen events and styles apply,
> though. If the page can tell whether or not the user has actually allowed it
> to enter fullscreen mode, it can refuse to display content until the user
> gives it 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() - security issues

[Robert O'Callahan]

On Tue, Feb 2, 2010 at 5:00 AM, Simon Fraser  wrote:

> On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote:
>
> > On Jan 31, 2010, at 05:08, Simon Fraser wrote:
> >
> >> * disallow enterFullscreen() from a frame or iframe
> >
> > This might be a problem if video sites transition their embedding
> 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 , 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()

[Brian Campbell]

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()

[Kenneth Russell]

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

[Robert O'Callahan]

On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell  wrote:

> When you say that the DOM viewport of the element is aligned with the
> screen when it goes fullscreen, does that mean that the .width and
> .height properties are changed? Or does it mean that the element's
> size is changed by a CSS style?
>

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()

[Kenneth Russell]

On Thu, Jan 28, 2010 at 8:55 PM, Robert O'Callahan  wrote:
> On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns 
> wrote:
>>>
>>> enterFullscreen always returns immediately. If fullscreen mode is
>>> currently supported and permitted, enterFullscreen dispatches a task that a)
>>> imposes the fullscreen 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  element already letterboxes. So you'd do something like this:
> 
>    src=...>
>   ... controls ...
> 
>
> Making the  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()

[Henry Bridge]

>
>
> 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() - security issues

[Simon Fraser]

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() - security issues

[Henri Sivonen]

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

[Olli Pettay]

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()

[Anne van Kesteren]

On Sun, 31 Jan 2010 03:43:49 +0100, Simon Fraser  wrote:

On Jan 30, 2010, at 1:24 PM, Anne van Kesteren wrote:
To stop polluting the Window object, might it make sense to put the new  
members (other than event handler attributes) on window.screen?


This would require that the current window 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

[Boris Zbarsky]

On 1/30/10 11:38 PM, Tab Atkins Jr. wrote:

On Sat, Jan 30, 2010 at 9:08 PM, Simon Fraser  wrote:

* require that enterFullscreen() is being called inside a user-event handler
(e.g. click or keypress) to avoid drive-by fullscreen annoyances.


This one seems kind of weird.  Does the spec currently 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() - security issues

[Tab Atkins Jr.]

On Sat, Jan 30, 2010 at 9:08 PM, Simon Fraser  wrote:
> * require that enterFullscreen() is being called inside a user-event handler
> (e.g. click or keypress) to avoid drive-by fullscreen annoyances.

This one seems kind of weird.  Does the spec currently distinguish
significantly between a user-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

[Simon Fraser]

On Jan 28, 2010, at 6:42 pm, Robert O'Callahan wrote:

> On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser  wrote:
> We have been discussing a more general fullscreen API that lets you take the 
> page fullscreen (perhaps with the ability to focus on a single element), as 
> Maciej mentions. We have 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()

[Simon Fraser]

On Jan 30, 2010, at 1:24 PM, Anne van Kesteren wrote:

> On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser  wrote:
>> On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote:
>>> So how about a Window API with an optional element component:
>>> void enterFullscreen(optional DOMElement element, optional 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()

[Tab Atkins Jr.]

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

[Darin Fisher]

On Thu, Jan 28, 2010 at 6:42 PM, Robert O'Callahan wrote:

> On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser  wrote:
>
>> We have been discussing a more general fullscreen API that lets you take
>> the page fullscreen (perhaps with the ability to focus on a single element),
>> as Maciej mentions. We 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()

[Anne van Kesteren]

On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser  wrote:

On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote:

So how about a Window API with an optional element component:
void enterFullscreen(optional DOMElement element, optional boolean  
enableKeys);

void exitFullscreen();
boolean attribute 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()

[Simon Fraser]

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()

[Robert O'Callahan]

On Sat, Jan 30, 2010 at 5:49 AM, Simon Fraser  wrote:

> On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote:
>
> 1) Should be convenient for authors to make any element in a page display
> fullscreen
> 2) Should support in-page activation UI for discoverability
>
>
> I agree with Boris that we 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  self-letterboxes,
you can make this always look good for  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()

[Frank Hellenkamp]

>> 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()

[Simon Fraser]

On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote:

> On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser  wrote:
> We have been discussing a more general fullscreen API that lets you take the 
> page fullscreen (perhaps with the ability to focus on a single element), as 
> Maciej mentions. We have 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()

[Boris Zbarsky]

On 1/28/10 10:41 PM, Kit Grose wrote:

True, but surely saying "any element" opens the door to full-screening inline text 
elements (e.g  elements).


I don't see why this is a problem, offhand.


I suppose the native style being "position: fixed" would put those elements in 
a block formatting 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()

[Robert O'Callahan]

On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns wrote:

> enterFullscreen always returns immediately. If fullscreen mode is currently
>> supported and permitted, enterFullscreen dispatches a task that a) imposes
>> the fullscreen style, b) fires the beginfullscreen event on the element and
>> c) 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  element already letterboxes. So you'd do something like this:

  
  ... controls ...


Making the  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()

[Ian Hickson]

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()

[Robert O'Callahan]

On Fri, Jan 29, 2010 at 4:06 PM, Kit Grose  wrote:

> Regarding point 1, surely any fullscreen API should only support
> block-level elements?
>

I don't see why. Setting position:fixed does what you want in the cases I
can think of.

If I'm reading point 2 correctly, I disagree with it (except in cases like
>  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()

[Geoff Stearns]

>
> 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()

[Kit Grose]

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

True, but surely saying "any element" opens the door to full-screening inline 
text elements (e.g  elements).

Looking at a few lists of all inline elements in HTML, there aren't any except 
 (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()

[Boris Zbarsky]

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?   is not block-level in any sense; One 
could argue that  and  are "block-level" in HTML terms, 
but it's context-dependent (they can contain blocks if their parent 
can).  None of these are block-level in the CSS sense, by default.


-Boris

Re: [whatwg] api for fullscreen()

[Kit Grose]

> 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 
 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()

[Robert O'Callahan]

On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser  wrote:

> We have been discussing a more general fullscreen API that lets you take
> the page fullscreen (perhaps with the ability to focus on a single element),
> as Maciej mentions. We have not decided on a final form for this API, nor
> have we 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()

[Simon Fraser]

On Jan 28, 2010, at 3:38 PM, Robert O'Callahan wrote:

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

[Robert O'Callahan]

On Thu, Jan 28, 2010 at 8:34 PM, Henri Sivonen  wrote:

> I haven't seen a proposal, but it looks like code has landed:
> http://trac.webkit.org/changeset/50893
>
> Demo: http://jilion.com/sublime/video
> (option-click  the full
> screen button in 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.

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()

[Henri Sivonen]

On Jan 28, 2010, at 04:38, Robert O'Callahan wrote:

> 2009/12/17 Maciej Stachowiak 
>> 1) It handles some very common use cases (including likely one of the *most* 
>> common, video) in a way that's much simpler for the content author.
>> 2) The browser will have the option to animate the 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?

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)

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] api for fullscreen()

[Robert O'Callahan]

2009/12/17 Maciej Stachowiak 

> 1) It handles some very common use cases (including likely one of the
> *most* common, video) in a way that's much simpler for the content author.
> 2) The browser will have the option to animate the transition to fullscreen
> starting from the target element, in a 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()

[Maciej Stachowiak]

On Dec 17, 2009, at 1:52 AM, Simon Pieters wrote:

On Thu, 17 Dec 2009 10:30:26 +0100, Maciej Stachowiak  
 wrote:




Some of us at Apple have discussed fullscreen APIs, and we think a  
user gesture requirement plus clear indication of what has happened  
is likely sufficient.


As to the API 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()

[Eric Uhrhane]

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

[Dion Almaer]

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

> wrote:

> 2009/12/17 Jonas Sicking :
> > I guess that if you enforced that fullscreen could only happen in
> > response to a click then you are in better shape.
>
> Browsers already have heuristics just like this for opening popup
> windows, don't they?  They seem to work pretty well to prevent pages
> from being too 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 (イアンフェッティ) :
> > 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()

[Aryeh Gregor]

2009/12/17 Jonas Sicking :
> I guess that if you enforced that fullscreen could only happen in
> response to a click then you are in better shape.

Browsers already have heuristics just like this for opening popup
windows, don't they?  They seem to work pretty well to prevent pages
from being too 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 (イアンフェッティ) :
> 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()

[Simon Pieters]

On Thu, 17 Dec 2009 10:30:26 +0100, Maciej Stachowiak   
wrote:




Some of us at Apple have discussed fullscreen APIs, and we think a user  
gesture requirement plus clear indication of what has happened is likely  
sufficient.


As to the API itself: we tentatively think a good API would be to 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()

[Maciej Stachowiak]

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
 wrote:

2009/12/17 Ian Fette (イアンフェッティ) 


I'm not convinced we actually need opt-in, though if we did have  
opt-in it
should allow the user to persist that choice (don't ask me for  
permission

each time i try to fullscreen a youtube 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()

[Robert O'Callahan]

2009/12/17 Jonas Sicking 

> Technically speaking this isn't something that needs to be
> standardized. All we need is a standardized fullscreen() function
> somewhere, and possibly standardized "fullscreenon"/"fullscreenoff"
> events. Browsers are free to implement whatever UI they want after
> 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()

[Jonas Sicking]

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

[Robert O'Callahan]

2009/12/17 Ian Fette (イアンフェッティ) 

> I'm not convinced we actually need opt-in, though if we did have opt-in it
> should allow the user to persist that choice (don't ask me for permission
> each time i try to fullscreen a youtube video.)
>

Sure.


> I would much rather go for user gesture + opt-out. 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()

[イアンフェッティ]

2009/12/16 Robert O'Callahan 

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

Re: [whatwg] api for fullscreen()

[Robert O'Callahan]

2009/12/17 Ian Fette (イアンフェッティ) 

> I think what I've heard from application developers over and over again is
> that, while the UA may provide some way to go into full screen from in the
> browser chrome, it is much more discoverable when that capability exists
> 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 Jonas Sicking 

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

[Jonas Sicking]

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

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

[Jonas Sicking]

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

[イアンフェッティ]

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 

> 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()

[narendra sisodiya]

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

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] api for fullscreen()

[Michael Dale]

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.


This is especially useful for video tag interfaces. For example we could 
expose a themed full-screen button in the player that is the equivalent 
of hitting f11 in Firefox. The video element container could be set to 
width:100% height:100% in the target window retaining support for 
javascript driven DOM overlays like timed text, temporal click spaces, 
site themed specific video controls sliding in at the bottom when the 
user moves the mouse, exiting full screen on


This is distinct from the browser providing a full-screen on the video 
element because we retain DOM overlays and javascript bindings, allowing 
sites to theme and customize the full-player experience.


To reiterate this is a separates spec request from the full-screen 
support for video element rather it just applies to exposing a 
permission system for JavaScript to control a browser "window" being 
full screen.


--michael