19:59:45 RRSAgent has joined #webperf 19:59:45 logging to http://www.w3.org/2013/12/11-webperf-irc 19:59:47 RRSAgent, make logs world 19:59:47 Zakim has joined #webperf 19:59:49 Zakim, this will be WPWG 19:59:49 I do not see a conference matching that name scheduled within the next hour, trackbot 19:59:50 Meeting: Web Performance Working Group Teleconference 19:59:50 Date: 11 December 2013 20:03:21 mnot has joined #webperf 20:03:31 zakim, who is here? 20:03:31 sorry, mnot, I don't know what conference this is 20:03:32 On IRC I see mnot, Zakim, RRSAgent, JatinderMann, slightlyoff, trackbot 20:03:38 zakim, this is webperf 20:03:38 sorry, mnot, I do not see a conference named 'webperf' in progress or scheduled at this time 20:03:45 zakim, this is wperf 20:03:45 ok, mnot; that matches RWC_web-per()3:00PM 20:04:11 Sometimes even Zakim messes up. 20:04:13 + +1.971.270.aabb 20:04:53 present+ Chase Douglas 20:05:02 present+ MNot 20:05:07 present+ JatinderMann 20:05:49 + +1.650.214.aacc 20:06:10 present+ Ilya 20:06:51 plh has joined #webperf 20:06:57 +Plh 20:07:19 zakim, aaaa is me 20:07:19 +mnot; got it 20:09:18 present+ plh 20:09:46 Topic: Timing APIs 20:09:56 Jatinder: Based on conversation with plh, looks like User Timing and Performance Timeline will be published as recommendations tomorrow. 20:10:02 Plh: We are on track. 20:10:18 Jatinder: I have updated the re-defined the performance interface in Navigation Timing L2 per Action 119. I'll upload the changes later today. 20:10:51 Thread: http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0076.html 20:11:02 Jatinder: Lots of discussion and seems like we are landing on the Timing specs should implement byte size information. 20:14:45 Plh: Would byte size data help in the Timing specs? 20:15:16 Jatinder: Giving connection information to sites so they can make better quality vs. performance tradeoff sounds interesting. However, I worry that there are so many complexities here to consider: variation in network speeds during a single session (if I have gone through LTE, 3G, Wifi in a single session, which data to report?), every site will make a speed vs. quality decision instead of making that decision at an OS level, some users may wan[CUT] 20:16:11 ...and other examples given below and in the threads. It may be interesting to have the UA tally up the data over time and give an appropriate hint but looks like Opera did that and was hit with many false positives, e.g. parallel network activity made it appear that they were on a slow connection, resulting in a generally poorer experience for some users. Getting a stripped down version of the site I was hoping to see when I have the connectio[CUT] 20:16:35 Ilya: I think the byte size data in the Timing APIs would be a step in the right direction. 20:18:57 Jatinder: Should we include byte size for both Navigation and Resource Timing? 20:19:44 Ilya: We can't see any reason why we shouldn't include it for Navigation and Resource Timing for both byte size and procotol information. 20:19:58 Plh: Mark, when do you expect to have the proposal for protocol information for us? 20:20:02 Mark: I should have it soon. 20:20:18 Jatinder: I can add the byte size information. Ilya, any information you want to include? 20:20:29 Ilya: We may want to include the byte size and compressed information as well. 20:20:57 Topic: High Resolution Time L2 20:21:05 Jatinder: Anne had feedback that we should name the worker interface, WorkerPerformance, to just Performance, http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0035.html. Seeing that we already have a partial for Performance, does this make sense? 20:21:25 Spec: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime2/Overview.html#sec-now-method 20:23:36 plh: I'm not sure we need to make a change. But this may impact prototyping. 20:23:44 Jatinder: I'll talk to Travis to see what changes need to make. 20:23:52 Topic: Beacon 20:24:27 Jatinder: Based on latest thread, http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0066.html, seems like most are in agreement to continue working on Beacon spec prior and then talk about whether to bring this into XHR. It also seems like we are in agreement that we should stick with a non-normative limit now during implementation and work on changing that as needed. 20:25:16 Jatinder: Regarding determining whether the beacon was queued. I agree with Jonas that returning a true/false value is a safer syntax for developers than raising an exception, if we want developers to take action on the beacon. I worry that developers will check if the beacon was queued and if not, will hold the unload and try again. Though not as bad as the current methods to see if the entire beacon got sent, this will cause some delay. Do we[CUT] 20:26:53 Ilya: If the browser does the retry, then we probably don't need to allow the developers retry. We talked about error logging being used as a mechanism, but the other thread mentioned that possibly error logging won't retry. I think we should just say best effort. 20:31:51 Chase: If we return a boolean, we are implying that they should wait and check that value. I rather not even give the boolean for queued values. If we do provide a boolean, it might be useful to return a false if the beacon didn't get queued because of the size. 20:32:15 Ilya: Looking at the XHR spec, looks like they also raise the exceptions. I don't think its unreasonable to do the same. 20:32:29 Chase: I wanted to query what size limits were we considering? 20:34:04 ...We are reporting back up to 30K data up to minute for consumer systems. 20:34:53 Ilya: One of the main concern here is that you're uploading 50k or 100k data while you're competing for the next request. What if the UA does some smart moves like it sends the small data immeidately and waits to send the larger data when it can including during the next page. 20:35:10 Chase: That is what the beacon API seems to want to do. 20:38:09 Ilya: I'm starting to think we shouldn't have a limit as I hear more data. Seems like whatever limit we have breaks someones beacon size, it causes us to do synchronous checks. I think we should just stick with something simpler. 20:38:56 Jatinder: Seeing that XHR can send as much data as possible, I'm not sure we need to protect against that case. I wonder if we're adding complexities for a theoritical problem. 20:39:13 Ilya: Yeah, seems like we're adding complexities. 20:39:34 Chase: If someones going to send MBs and MBs, UAs should set a limit internally. 20:40:59 Jatinder: Okay, I think we should push back on limits unless we have an real world example of abuse today with limits. 20:41:07 Topic: Resource Priorities 20:41:15 Jatinder: Ian pointed out a discussion that’s taking place in the WHATWG over how to provide more control to authors around loading and executing scripts, http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0277.html. Essentially looks like they are trying to solve issues that script loading libraries are trying to solve today. There are more use cases in the thread. We need to determine how that proposal works with Resource Pri[CUT] 20:41:47 Also, do we have an opinion on that proposal? Main thread is here: http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0061.html 20:43:02 Jatinder: Ian mentioned that we should either have Resource Priorities changes be made in the HTML spec or have hooks in the HTML spec that Resource Priorities can point to. Since we wanted to start by defining this feature end to end in a separate spec, I'd love to get the hooks put in. If later on we think it makes sense to pull this back into HTML, SVG, CSS, we can integrate those changes back. 20:44:25 Ilya: I had a question about postpone. For the postpone attribute its only defined visibile elements. Have we concerned making it available on a container element? Many times on the mobile web, we will have entire content inside a div. E.g., I may display:none the entire div. It would be great if I could display:none the entire element. 20:46:30 Jatinder: There were issues with CSS properties setting on a div because formatting doesn't come until later. We could consider doing this on a container level. 20:46:57 ACTION Jatinder to add postpone to container elements that visible elements can inherit 20:46:57 Created ACTION-126 - Add postpone to container elements that visible elements can inherit [on Jatinder Mann - due 2013-12-18]. 20:47:14 Topic: Error Logging 20:47:19 Spec: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationErrorLogging/Overview.html 20:48:07 Jatinder: Aaron raised the issue with the reporting retry logic causing a DDOS. There was a suggestion that no retrying will solve the DDOS problem: http://lists.w3.org/Archives/Public/public-web-perf/2013Dec/0063.html. Is this okay by our customers? Should we limit the no retrying to the same origin (origin with the error)? Likelihood of an error on a navigation on one domain and an error on a posting to another at the same time seems low. 20:49:59 Jatinder: Seems like we're okay, since another user will probably hit the site anyway. 20:50:59 -[Microsoft] 20:51:00 -Plh 20:51:01 -mnot 20:51:05 - +1.650.214.aacc 20:51:07 - +1.971.270.aabb 20:51:08 RWC_web-per()3:00PM has ended 20:51:08 Attendees were [Microsoft], +61.2.900.8.aaaa, +1.971.270.aabb, +1.650.214.aacc, Plh, mnot 20:51:10 rrsagent, generate minutes 20:51:10 I have made the request to generate http://www.w3.org/2013/12/11-webperf-minutes.html JatinderMann 22:44:32 Zakim has left #webperf