RE: TPAC 2011 Web Performance WG 2011-11-01

Boris,

I completely agree with you that we should only move forward with a spec if there is consensus that all raised issues have been closed and the spec is stable rather than rushing for the sake of rushing. It appears that in this case we could have done a better job of closing loop on the issues you had raised.

We had discussed the two issues of iframe visibility and visibility on navigate away on the 2011/10/12 conference call, summarized in these meeting minutes: http://lists.w3.org/Archives/Public/public-web-perf/2011Oct/0071.html. I summarize some of the discussion below. It's unfortunate you weren't able to make our TPAC meeting, otherwise we could have discussed these issues in person then. 

Per the working group conference call, we felt that iframe visibility, though somewhat interesting, is something to consider in a future revision. Currently, we attempt to simplify the design by defining everything in a visible page in the foreground tab as being visible, and everything else as hidden. This design balances simplicity and provides the lion share of the power efficiency win by allowing developers the ability to minimize background interference in pages in the background tabs. The spec attempts a best effort at providing the true visibility. There is already another edge case where the API suggests the page is visible even though it is not: e.g., a non-minimized browser window that is fully obscured by other windows appearing as visible though it is hidden. These edge cases do not strictly make things worse than they were prior to the availability of this API. We recommend that the IFrame and fully obscured window cases be considered in a future revision in the spec or as non-normative cases. What are your thoughts on this perspective? We may want to continue this discussion on the original mail thread in an effort to improve communication on this issue - http://lists.w3.org/Archives/Public/public-web-perf/2011Oct/0070.html. 

As for visibility change on navigate away, it wasn't clear what are the benefits would be of changing the state and firing the event when navigating away. Today, the beforeunload and unload events mark the end of a user session to a developer; you can queue saving state off of these events. What additional benefit would this change have? Again, we may want to continue the discussion on the original mail thread - http://lists.w3.org/Archives/Public/public-web-perf/2011Oct/0019.html. 

As for the test suite, we have submitted a test suite at http://dvcs.w3.org/hg/webperf/file/6c820a644db0/tests/submission/Microsoft/PageVisibility. Chrome and IE10 both appear to pass majority of the tests; I have not yet had a chance to run them on Firefox. The two issues that you had raised regarding the test suite mirror the above discussion. Based on how we close on that discussion, we can appropriately update the test suite. We already have work to update the test suite for ACTION-59: Do not define string constants, http://www.w3.org/2010/webperf/track/actions/59. 

Thanks,
Jatinder

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Tuesday, November 08, 2011 6:20 PM
To: public-web-perf@w3.org
Subject: Re: TPAC 2011 Web Performance WG 2011-11-01

On 11/8/11 7:38 PM, Jatinder Mann wrote:
> Considering the working group believes this specification is stable 
> and upon completion of the one action item identified today, all 
> issues raised against this specification will have been formally 
> addressed,

There are at least two issues that I have raised on page visibility which haven't even been acknowledged, much less addressed.  Please do address them, as well as the issues I raised that have been acknowledged but likewise not addressed as far as I can tell.

> Further, as there are two interoperable implementations of this 
> specification

Are there?  We don't even have a decent test suite that covers all the functionality last I checked; how could we possibly know whether we have interoperable implementations?

In particular, the issues I raised are not covered by the existing tests.

> the working group will like to take this specification to Proposed 
> Recommendation by December 2011.**

I strongly object to this, given the open issues and lack of demonstrated interoperability.  Consider this a formal objection if desired, though given the existence of open issues that really shouldn't be needed.

I'd love to get this spec to PR, but I think that as currently written it has some issues, and I thing it would be good to actually address them before we proceed to PR.

-Boris

P.S. The general feeling of feedback being ignored so that specs can be rushed to Rec is not particularly pleasant.  I've been there before with SVG 1.1, and almost swore off participation in the W3C at the time, but at least they had the excuse of feeling like they were really late in getting the spec finalized.  Taking the extra week or two to actually address the feedback on page visibility isn't exactly going to kill us.

Received on Wednesday, 9 November 2011 08:13:27 UTC