[minutes] Web Performance WG Teleconference #105 2013-04-10

Meeting Summary:



1.     Diagnostics and Error Logging

We discussed in detail the list of error codes to consider in the error logging specification: http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/att-0007/WebRequestStatusCodes4.html. For next week's call, we would like everyone to have reviewed this list of topics and consider what we should and shouldn't include in the error logging spec.



We will also review the real time notification of errors proposal in next week's call.



2.     Resource Timing Updates

We decided to make the connectEnd definition in Resource Timing consistent with the connectEnd definition of Navigation Timing. If we decide that we want to expand the attribute defintions to provide additional details, we can do so in the Level 2 version of both specifications. This will maintain consistency across the Timing specs.



3.     Iframe Visibility

Seeing that requestAnimationFrame is using the Page Visibility definition of visibility, at this time we don't believe we should expand requestAnimationFrame to include iframe visibility. As CSS properties can be queried through script, we don't feel that this is a missing piece. We are interested in further investigating an element visibility that can query the visibility state of elements on the page (e.g., subdocuments, images, canvases, etc.). In rAF L2 spec, we can possibly reference the element visibility instead of page visibility. We can schedule a future conference call to discuss element visibility in more detail.



4.     Agenda for next week's call

We will continue our discussion of the Diagnostics and Error Logging specification next week. In particular, we will review the error type data and also discuss real time notification of errors.




W3C Web Performance WG Teleconference #105 2013-04-10



IRC log: http://www.w3.org/2013/04/10-webperf-irc



Meeting Minutes: http://www.w3.org/2013/04/10-webperf-minutes.html



Attendees

James Simonsen, Jatinder Mann, Daniel Austin, Ganesh Rao, Arvind Jain, Aaron Heady, Philippe Le Hegaret, Jason Weber


Scribe

Jatinder Mann



Agenda

1.     Discuss Diagnostics and Error Logging

2.     Resource Timing spec updates

3.     RequestAnimationFrame Feedback

4.     Charter Updates

--------------------------------------------------------------------------------



Minutes:
Continue Discussion on Error Logging and Diagnostics

Jatinder: Let's discuss Error codes that Dan had put together, security scenario Aaron had raised, and real time notification of errors.
... Spec updates that I've been working on: making two separate interfaces called HistoricalErrorLogging and ErrorLogging, spec clarifies that only HistoricalErrorLogging is persisted across sessions. I'll send an email when I have pushed up these changes.
... Should we specify the ability to disable the feature?

Dan: I don't want to link this feature with cookies. If we can add a separate section that gives guidance to the user agent to add a global setting to turn off the historical data logging feature, I think that's fine.

Jatinder: I'll put that in the privacy section.
... Error list: http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/att-0007/WebRequestStatusCodes4.html

Dan: This is a more complete list of things we should consider, not necessarily a list of things we should require in the spec.

Jatinder: Is abandonment / abort on the list?
... We either have an option of keep generic errors or standardize on a specific list. Personally, I like the standardized list, because users won't have to learn different errors per user agent and we will have consistent errors with third party services like Gomez and keynote.
... Has anyone taken a closer look at this list?

<plh> 599 Network connect timeout error (Unknown)

<plh> This status code is not specified in any RFCs, but is used by Microsoft HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

Aaron: I had reiewed these error codes in detail and tried to compare them with Gomez.

Dan: I combed through many sources, including Gomez and others, to get this full list. I tried to make sure that I didn't miss anything. Some proprietary errors I think we shouldn't include, like the Blocked by Windows Parental Controls.

Arvind: We may want to add a high level category (DNS, TCP, etc.) and then a more detailed error within that category. We can then just reference all the various specs, and not necessarily have to specify each one in this spec.

Dan: Personally, I don't think it's not useful to see if something is a DNS or TCP error, but I think it's much more useful to look at the actual errors.

Jatinder: I think we shouldn't make decision right now. Let's review the status codes and make a decision next week on what we should or shouldn't include.
Resource Timing spec updates

Jatinder: There was a discussion to make the Resource Timing connectEnd definition to be consistent with Navigation Timing connectEnd.

<plh> "connectEnd must include the time interval to establish the transport connection as well as other time interval such as SSL handshake and SOCKS authentication."

Dan: I believe it would be more useful to create a separate phase for the SSL handshake and SOCK authentication.
... Something like TCPConnectStart, TCPConnectEnd, etc.

James: I believe we went this way because not everyone has access to the SSL connection times.

Jatinder: For consistency with Navigation Timing Level 1, we should keep the Resource Timing Level 1 definition consistent with it. If we want to consider expanding the phases/attributes, we should do it for both the Level 2 specifications for Navigation and Resource Timing.
... I have also uploaded a Resource Timing Level 2 specification, which has the exact same text as the Level 1, but with a different name. We should start talking about how we want to define the audio and video behavior in this spec.

James: We should invite the Media folks to that discussion.

Alois, we just ended the conference call. We're still on US daylight savings time (minus one hour).

(I'm just writing up the meeting notes that I missed)

Jatinder: I recommend we send out a proposal on the mailing list for what that would look like and schedule a discussion on that in the future, I'll add those details to the Level 2 spec after we agree on the proposal.
RequestAnimationFrame Feedback

Jatinder: Boris had raised feedback on the requestAnimationFrame spec: http://lists.w3.org/Archives/Public/public-web-perf/2013Feb/0036.html

Jatinder: Considering one can determine through script if an iframe is hidden or not, I don't think that's necessarily a missing piece. The rAF spec depends on the Page Visibility definition of hidden, which is tied to the top level document. We can consider an element visibility spec separately and have rAF L2 point to that.

Arvind: Was the concern that if an iframe is below the fold, it's still considered visible through Page Visibility?

Jatinder: Yes, it is. I think there are a number of parties that would be interested in the visibility of certain elements, like iframes or canvases that are below the fold. E.g., advertisers uses numerous non-standardized methods to determine if their ad is visible, hidden, or partially visible. If we want to consider solving that problem, I recommend a separate specification.

Dan: I would be interested in hearing more about this particular problem space.
... I'd be interested in hearing the performance angle on that problem.

Jatinder: I think we should share out a proposal and discuss further. Such a spec would be in the limits of our current charter.
Charter Updates

Plh: I have received approval from the various AC reps for the new charter, which is a good thing.
... I have also just sent out the approval for Page Visibility to the AC reps. I expect it to go to Rec soon.