First things first: On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote:
> I believe you have _completely_ misunderstood what I said. I'm describing a > problem in the geolocation API as it stands. You're .... talking about > something else. Unfortunately, I'm not quite sure how you got there from > here. > > I think we really need to get this complete failure of communication sorted > out for the rest of this discussion to be productive. :( and: > Hold on. We're talking about geolocation here and whether it's a good model > to follow, no? I'm not presuming to design UI for the full-screen case, and > I have no indication that this would be the UI used for full-screen. Ah, okay. Sorry, I was under the opposite impression. I had thought the permissions model and UI that Firefox was suggesting was identical to the Geolocation case. If not, then you're right, I'm conflating the two issues. I'll try to limit my responses to the topic at hand. :) As I'm not really looking to rehash or debate the geolocation API and browser's implementation of it, I'm going to leave off responding to some of the points raised below. I'm not trying to be evasive in doing so, but just trying to focus in on the full-screen API. Continuing... On May 12, 2011, at 11:24 AM, Boris Zbarsky wrote: > On 5/12/11 12:48 PM, Jer Noble wrote: >>> I'm saying that if authors expect to get one or the other but then never >>> do, that will confuse authors. >> >> Again, I fail to see how this is a problem for the "denial" event but not >> for the "change" event. > > The problem is not "for" any particular event. The problem is in creating an > author expectation that one of the two events will definitely be called. > This expectation is incorrect. > > If there is only one event, then there can be no such expectation, for > obvious reasons: the behavior when full screen is denied is that there is no > event, so authors have to handle the case of no event in a sane way. I understand what you're saying. By making the error case deliberately ambiguous, you're trying to force the author to behave in a certain way. However, I disagree that this is a) likely to work and b) likely to be less confusing than the alternative. Of course, one solution to both confusion and incorrect expectations is documentation. :-) If it were made both clear and explicit that either of those events may never be dispatched after requestFullScreen() is called, shouldn't that suffice? > At the same time, such situations are clearly considered beneficial by > multiple UAs, and I think you will have a hard time finding a UI designer who > thinks that actually forcing the user to decide in this case (i.e. forcing a > modal dialog on them) is a good idea. (skipping ahead) > Keep in mind that the "user denies" case is very likely to be a _rare_ case. > The common cases would be "user accepts" and "user defers". I agree with the first statement. However, I don't expect that "user defers" will actually be that common. If you look at the "Suggested UA Policy" portion of the spec, most cases are either implicitly accepted or denied without user prompting. I expect that, for the overwhelming majority of cases, full-screen requests will be either be implicitly accepted (for user-action driven, non-keyboard requests), or implicitly denied (non-user-action driven requests). For the remainder (user-driven, keyboard-access requests), the requests will be overwhelmingly non-malicious, resulting in "user accepts", and those that are spam/popups will result in "user denies". So I'd argue that the case where a page author would have to wait any appreciable amount of time before receiving a "fullscreendenied" event is actually quite rare. -Jer
