- From: Alex Komoroske <komoroske@chromium.org>
- Date: Mon, 20 Dec 2010 22:23:41 +0000
Hi Bjartur, Thanks for your comments. My responses are inline. On Mon, Dec 20, 2010 at 8:56 PM, Bjartur Thorlacius <svartman95 at gmail.com>wrote: > On 12/20/10, Alex Komoroske <komoroske at chromium.org> wrote: > > Thanks for your comments. I've replied inline. > > > > On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius > > <svartman95 at gmail.com>wrote: > > > >> On Wed, 15 Dec 2010 19:27:51 -0000, Alex Komoroske > >> <komoroske at chromium.org> wrote: > >> > >>> Regarding the fact that background tabs aren't necessarily invisible: > >>> ----- > >>> > >>> On December 8, Boris Zbarsky wrote: > >>>> > >>> > >>> There is no such guarantee for background tabs. For example, browsers > >>> may > >>> > >>>> show tab previews in various contexts (Panorama in Firefox 4, e.g.). > >>>> > >>> > >>> ----- > >>> > >>> The point of the API, as proposed, is that page scripts will know when > >>> their > >>> content is guaranteed to be invisible to the user--that is, the API > will > >>> not > >>> provide a false positive about invisibility. However, the API may > >>> provide > >>> false negatives about invisibility, for reasons many others on this > >>> thread > >>> have been pointed out (including different windowing systems, multiple > >>> monitors, partial transparency, etc.). > >>> > >>> The easiest way to achieve this guarantee is to only consider a tab > >>> hidden > >>> when it is a background tab within* *a window. The window itself, of > >>> course, may be on a little-noticed second monitor, partially obscured, > >>> etc. > The obvious way to achieve this is to only consider a tab/window hidden > when > it's not on-screen, and consider it visible when it's on-screen. What good > is > being the current tab when the window is off-screen? > > > >> I don?t see how that information is useful. Now, you have to define > >> 'window' > >> and 'tab' differently and define a background state of the latter. Do > >> multiple > >> non-backgrounded (attached) tabs in a window need special treatment? If > >> you use the term 'tab' anywhere it _will_ be confused with the UI > >> metaphor, > >> causing confusion with the approach to hierarchical window management. > >> I don't understand what the term 'tab' means to you. To me a tab is a > >> window. > > > > > > I'm not sure that I understand the point of confusion. When I say 'tab', > I > > mean the current UI construct implemented in Firefox, Safari, Chrome, > Opera, > > Internet Explorer, and others. Each window can have one or more tabs, > and > > in curent implementations (with very few exceptions), each window can > only > > have a single visible tab. > > > In context of many of the less-widely used browsers the word 'tab' is > never used. > Each top-level browsing context has an associated window, which may be > grouped with other windows and that group may be represented as a tab > strip, > wherefrom windows may be selected. They may also be tiled, and a tab strip > which allows multiple windows to be selected (tabbed desktops), causing > them > to tile. How does your proposal work wrt tagged windows (as used in wmii, > dwm)? > > I don't understand an UI construct used by WMs is of any interest to > applications. > AFAIK, X11 only notifies clients about changing visibility, and by > extension, > partial overlaps. Why would apps rather know whether they're selected in a > tab > strip (creating an unnecessary requirement for tab strips) than whether > they're > visible? With the aforementioned WMs (wmii, dwm) windows may be in multiple > groups (tags). In wmii, windows are managed hierarchically. This isn't of > any > concern to anyone but the user. Applications shouldn't care at all. > They're given a > resizing window of variable visibility to draw on; tabs don't matter. > Thanks for the clarification. I attempted to address this in the e-mail I just sent in response to Boris. (In a nutshell: I agree with you about tabs not being a central UI concept, but I think that the concept of "tab" is not core to the proposal.) Let me know if that e-mail doesn't address these concerns. > > > I'm not sure that I have seen your counterproposal. Based on your > comments > > in this thread, I presume that it includes an ability for pages to > declare > > what capabilities they require (e.g. an animation requires that it be > > visible) and then the browser automatically pauses scripts when those > > required conditions are not met. Is that a proper understanding of your > > counterproposal? Is there a more comprehensive/detailed version of the > > proposal that I could read and comment on? > > > Yes, your understanding is correct, and no, there is none. > > > >>> On December 8th, Maciej Stachowiak wrote: > >>>> This use case can be handled without help from the page. In Safari, > >>>> video > >>>> (whether through media elements or plugins) won't start playing when a > >>>> user > >>>> opens a tab in the background, until the user switches to that tab. > >>>> > >>> > >>> ----- > >>> > >>> Although what you describe satisfies the specific use case, it doesn't > >>> address the more general use case of animations (either explicit via > >>> javascript or via CSS Animations) or content that is not a plugin/video > >>> file. > >>> > Modularity is good. > > >>> I argue that there are two potentially viable solutions: > Implementations > >> exploiting more methods ? la Safari, stopping animations or apps > declaring > >> dependencies on various things like visibility and audibility. There are > >> previous proposals regarding throwing CSS media events upon change, > which > >> could potentially be integrated with this. > >> > >> The whole things smells of over-engineering. A resource of MIME media > type > >> "audio" obviously can't be rendered without audibility, "image" > resources > >> sans (2D) visibility nor "model" resources sans 3D visibility. "Text" > >> resources can be rendered both visually and aurally, and "model"s can > also > >> be rendered to 2D displays, as long they're interactive (they're > >> redrawable > >> and user input is accessible). > > > > > > Although I agree that in some limited cases the correct behavior is > clear, > > in practice there is a lot of gray area for many common cases. A > multi-user > > collaborative puzzle should continue executing even when in the > background > > (perhaps another player made a move that should play a sound to alert > this > > user of the new move); a single-player puzzle might not need to execute > at > > all when backgrounded. The more complex the web app, the more likely > that > > the precise needs for pausing can't be met precisely with simple > "semantic" > > directives to the browser. > > > A multiplayer puzzle needs either focus and visibility (and'll use a > network > connection when available) or a network connection and a notification > mechanism. The developer will be aware of what interfaces the app utilizes, > and > declaring dependencies on interfaces he might otherwise take for granted > might, > as a surplus, prompt him to think about accessibility issues that may rise > when > the interfaces can't be used. > I agree that the notion of visibility is perhaps an imperfect proxy for what the developer really wants to know. However, I believe that in practice it's a reasonably powerful proxy, and that the alternative--designing a system to let the developer precisely define the interfaces he requires, in many different contexts--is quite a larger undertaking. > > > > >> > >> > >> Regarding solving the use cases that cannot be addressed currently: > >>> ------ > >>> On December 8th, Maciej Stachowiak wrote: > >>> > >>> That leaves the following use cases: > >>> * A puzzle game has a timer that keeps track of how long the user has > >>> taken > >>> to solve the puzzle. It wants to pause the timer when the user has > >>> hidden > >>> the tab. > >>> > >> The counter is paused while the script's suspended, wall-clock keeps > >> going. > >> > >> * A web app that uses polling to fetch dynamic content can pause > polling > >>> when it knows the page is hidden from the user. > >>> > >> A suspended script can't phone home. > >> > >> * A page wants to detect when it is being prerendered so it can behave > >>> appropriately. > >>> > >> The only use case for this I can see is confusing users. That's probably > >> just me. > > > > > > I'm not sure that I understand this point. Given the existence of a > > pre-rendering feature, how would providing information to the page about > > whether it is being pre-rendered lead to confusion of users? > > > My misunderstanding. It cannot cause user-confusion. Ignore. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101220/d023f373/attachment.htm>
Received on Monday, 20 December 2010 14:23:41 UTC