On 5/12/11 8:29 PM, Aryeh Gregor wrote:
If we can figure out in advance what UIs browsers will want to use in
practice, though, that should inform what API we settle on.
Generality is not always good.
Yes.
If it turns out no one wants to ask the user before fullscreening
I'm 99% sure that someone does. This would be a pretty typical thing
for NoScript to do, say.
If you have reasons to believe that there is really no one who would
want to do so, I'd love to hear them.
So if the desired API will depend on the sort of UI browsers will want
to implement, I'd ask the UI people what UI they'd use before deciding
on the API.
Yes, that seems like a good idea too.
So let's try attacking the problem from that angle. I posit that for web
developers the following are bad assumptions and that the API should make it
clear that they are bad assumptions:
1) Your page will automatically go into fullscreen when you ask it to
2) After you ask your page to go into fullscreen, you are guaranteed a
response within time T (for some finite T) indicating whether this
has happened.
3) You can figure out whether the user has decided that your site
should never be able to go into fullscreen (exposing that
information increases the fingerprintability of the browser, so
I suspect at least some browsers would not want to expose it).
Those all seem like reasonable things to avoid. However, (3) is
probably impossible to avoid for some choices of UI.
That's fine. I'm not saying all browsers will care about
fingerprinting. But the ones who _do_ shouldn't have to violate this
spec to deal with it when designing their UIs.
If the UI is
like for popup windows, which seems reasonable, then either the
browser will go fullscreen right away or it won't, and you can tell by
timing. Of course, browsers aren't obliged to maintain a per-site
blacklist on fullscreening if they don't want to.
Indeed. They're also not obligated to tell the site the truth about
when they've made the fullscreen decision... unless the spec calls for
it. ;)
-Boris
