Hi Bjartur,<div><br></div><div>Thanks for your comments.  My responses are inline.<br><br><div class="gmail_quote">On Mon, Dec 20, 2010 at 8:56 PM, Bjartur Thorlacius <span dir="ltr"><<a href="mailto:svartman95@gmail.com">svartman95@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On 12/20/10, Alex Komoroske <<a href="mailto:komoroske@chromium.org">komoroske@chromium.org</a>> wrote:<br>


> Thanks for your comments.  I've replied inline.<br>
><br>
> On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius<br>
> <<a href="mailto:svartman95@gmail.com">svartman95@gmail.com</a>>wrote:<br>
><br>
>> On Wed, 15 Dec 2010 19:27:51 -0000, Alex Komoroske<br>
>> <<a href="mailto:komoroske@chromium.org">komoroske@chromium.org</a>> wrote:<br>
>><br>
>>> Regarding the fact that background tabs aren't necessarily invisible:<br>
>>> -----<br>
>>><br>
>>>  On December 8, Boris Zbarsky wrote:<br>
>>>><br>
>>><br>
>>> There is no such guarantee for background tabs.  For example, browsers<br>
>>> may<br>
>>><br>
>>>> show tab previews in various contexts (Panorama in Firefox 4, e.g.).<br>
>>>><br>
>>><br>
>>> -----<br>
>>><br>
>>> The point of the API, as proposed, is that page scripts will know when<br>
>>> their<br>
>>> content is guaranteed to be invisible to the user--that is, the API will<br>
>>> not<br>
>>> provide a false positive about invisibility.  However, the API may<br>
>>> provide<br>
>>> false negatives about invisibility, for reasons many others on this<br>
>>> thread<br>
>>> have been pointed out (including different windowing systems, multiple<br>
>>> monitors, partial transparency, etc.).<br>
>>><br>
>>> The easiest way to achieve this guarantee is to only consider a tab<br>
>>> hidden<br>
>>> when it is a background tab within* *a window.  The window itself, of<br>
>>> course, may be on a little-noticed second monitor, partially obscured,<br>
>>> etc.<br>
</div></div>The obvious way to achieve this is to only consider a tab/window hidden when<br>
it's not on-screen, and consider it visible when it's on-screen. What good is<br>
being the current tab when the window is off-screen?<br>
<div class="im"><br>
<br>
>> I don´t see how that information is useful.  Now, you have to define<br>
>> 'window'<br>
>> and 'tab' differently and define a background state of the latter. Do<br>
>> multiple<br>
>> non-backgrounded (attached) tabs in a window need special treatment? If<br>
>> you use the term 'tab' anywhere it _will_ be confused with the UI<br>
>> metaphor,<br>
>> causing confusion with the approach to hierarchical window management.<br>
>> I don't understand what the term 'tab' means to you. To me a tab is a<br>
>> window.<br>
><br>
><br>
> I'm not sure that I understand the point of confusion.  When I say 'tab', I<br>
> mean the current UI construct implemented in Firefox, Safari, Chrome, Opera,<br>
> Internet Explorer, and others.  Each window can have one or more tabs, and<br>
> in curent implementations (with very few exceptions), each window can only<br>
> have a single visible tab.<br>
><br>
</div>In context of many of the less-widely used browsers the word 'tab' is<br>
never used.<br>
Each top-level browsing context has an associated window, which may be<br>
grouped with other windows and that group may be represented as a tab strip,<br>
wherefrom windows may be selected. They may also be tiled, and a tab strip<br>
which allows multiple windows to be selected (tabbed desktops), causing them<br>
to tile. How does your proposal work wrt tagged windows (as used in wmii, dwm)?<br>
<br>
I don't understand an UI construct used by WMs is of any interest to<br>
applications.<br>
AFAIK, X11 only notifies clients about changing visibility, and by extension,<br>
partial overlaps. Why would apps rather know whether they're selected in a tab<br>
strip (creating an unnecessary requirement for tab strips) than whether they're<br>
visible? With the aforementioned WMs (wmii, dwm) windows may be in multiple<br>
groups (tags). In wmii, windows are managed hierarchically. This isn't of any<br>
concern to anyone but the user. Applications shouldn't care at all.<br>
They're given a<br>
resizing window of variable visibility to draw on; tabs don't matter.<br></blockquote><div><br></div><div>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.</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I'm not sure that I have seen your counterproposal.  Based on your comments<br>
> in this thread, I presume that it includes an ability for pages to declare<br>
> what capabilities they require (e.g. an animation requires that it be<br>
> visible) and then the browser automatically pauses scripts when those<br>
> required conditions are not met.  Is that a proper understanding of your<br>
> counterproposal?  Is there a more comprehensive/detailed version of the<br>
> proposal that I could read and comment on?<br>
><br>
</div>Yes, your understanding is correct, and no, there is none.<br>
<div class="im"><br>
<br>
>>>  On December 8th, Maciej Stachowiak wrote:<br>
>>>> This use case can be handled without help from the page. In Safari,<br>
>>>> video<br>
>>>> (whether through media elements or plugins) won't start playing when a<br>
>>>> user<br>
>>>> opens a tab in the background, until the user switches to that tab.<br>
>>>><br>
>>><br>
>>> -----<br>
>>><br>
>>> Although what you describe satisfies the specific use case, it doesn't<br>
>>> address the more general use case of animations (either explicit via<br>
>>> javascript or via CSS Animations) or content that is not a plugin/video<br>
>>> file.<br>
>>><br>
</div>Modularity is good.<br>
<div class="im"><br>
>>>  I argue that there are two potentially viable solutions: Implementations<br>
>> exploiting more methods á la Safari, stopping animations or apps declaring<br>
>> dependencies on various things like visibility and audibility. There are<br>
>> previous proposals regarding throwing CSS media events upon change, which<br>
>> could potentially be integrated with this.<br>
>><br>
>> The whole things smells of over-engineering. A resource of MIME media type<br>
>> "audio" obviously can't be rendered without audibility, "image" resources<br>
>> sans (2D) visibility nor "model" resources sans 3D visibility. "Text"<br>
>> resources can be rendered both visually and aurally, and "model"s can also<br>
>> be rendered to 2D displays, as long they're interactive (they're<br>
>> redrawable<br>
>> and user input is accessible).<br>
><br>
><br>
> Although I agree that in some limited cases the correct behavior is clear,<br>
> in practice there is a lot of gray area for many common cases.  A multi-user<br>
> collaborative puzzle should continue executing even when in the background<br>
> (perhaps another player made a move that should play a sound to alert this<br>
> user of the new move); a single-player puzzle might not need to execute at<br>
> all when backgrounded.  The more complex the web app, the more likely that<br>
> the precise needs for pausing can't be met precisely with simple "semantic"<br>
> directives to the browser.<br>
><br>
</div>A multiplayer puzzle needs either focus and visibility (and'll use a network<br>
connection when available) or a network connection and a notification<br>
mechanism. The developer will be aware of what interfaces the app utilizes, and<br>
declaring dependencies on interfaces he might otherwise take for granted might,<br>
as a surplus, prompt him to think about accessibility issues that may rise when<br>
the interfaces can't be used.<br></blockquote><div><br></div><div>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.  </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
><br>
>><br>
>><br>
>>  Regarding solving the use cases that cannot be addressed currently:<br>
>>> ------<br>
>>> On December 8th, Maciej Stachowiak wrote:<br>
>>><br>
>>> That leaves the following use cases:<br>
>>> * A puzzle game has a timer that keeps track of how long the user has<br>
>>> taken<br>
>>> to solve the puzzle.  It wants to pause the timer when the user has<br>
>>> hidden<br>
>>> the tab.<br>
>>><br>
>> The counter is paused while the script's suspended, wall-clock keeps<br>
>> going.<br>
>><br>
>>  * A web app that uses polling to fetch dynamic content can pause polling<br>
>>> when it knows the page is hidden from the user.<br>
>>><br>
>> A suspended script can't phone home.<br>
>><br>
>>  * A page wants to detect when it is being prerendered so it can behave<br>
>>> appropriately.<br>
>>><br>
>> The only use case for this I can see is confusing users. That's probably<br>
>> just me.<br>
><br>
><br>
> I'm not sure that I understand this point.  Given the existence of a<br>
> pre-rendering feature, how would providing information to the page about<br>
> whether it is being pre-rendered lead to confusion of users?<br>
><br>
</div>My misunderstanding. It cannot cause user-confusion. Ignore.<br>
</blockquote></div><br></div>