16:57:18 RRSAgent has joined #webperf 16:57:18 logging to http://www.w3.org/2013/09/11-webperf-irc 16:57:20 RRSAgent, make logs world 16:57:20 Zakim has joined #webperf 16:57:22 Zakim, this will be WPWG 16:57:22 I do not see a conference matching that name scheduled within the next hour, trackbot 16:57:23 Meeting: Web Performance Working Group Teleconference 16:57:23 Date: 11 September 2013 17:03:11 present+ Daniel 17:03:14 present+ Rob 17:03:19 present+ Jatinder 17:03:42 RobDickinsonFromDell has joined #webperf 17:03:58 Hellow 17:04:51 simonjam has joined #webperf 17:07:14 present+ simonjam 17:07:56 Topic: User Timing Open Issue 17:07:59 http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0001.html 17:08:22 Jatinder: Based on the example, a simple workaround for async function may just be to take a performance.measure('name'), and not pass in a start mark. That way you will get the time from navigationStart until the async call has been made. If one really desires to see the deltas, you can always subtract the measure's duration from the mark's duration. 17:08:50 Jatinder: Also, I wasn't able to reproduce the issue Kiran saw with the code he had submitted on either Chrome or IE. I think it's worthwhile to ask him to share a repro test case. 17:10:06 James: My interpretation was that this was just something people can fall for. 17:10:14 Jatinder: I don't think we should take this change. 17:10:18 Topic: originTime in performance.now() spec 17:11:21 Jatinder: Goal was if developers ever wanted to compare the absolute times of two different performance.now() measurements, they could just add performance.originTime to the performance.now() value. This makes comparing an absolute time value from a shared worker context with a dedicated worker or top level document possible. 17:13:50 Jatinder: To make this work, performance.originTime must be in milliseconds from unix epoch in at least microsecond resolution, monotonically increasing. I think this should be possible with doubles. 17:19:08 James: Seems like you want to compare when a worker sent data and when it was recieved, so you can figure out the latency. 17:19:47 James: We should consider coming up with a new point in reference, just has to be before the first navigation start. E.g., start of browser launch. 17:19:55 Topic: Resource Priorities 17:20:00 http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0042.html 17:21:57 Jatinder: Should we mark the lazyload behavior with a MUST clause? I was hoping by letting the user agent decide what is network contention we can still have some wiggle room. E.g., for testing, you just need to create a page that uses up all six available connections (for some user agents), and then try to download another resource. The next resource should be a non-lazyloaded resource. I'm not against moving this back to a MAY clause. 17:23:57 James: I am leaning towards MAY, but I recognize that it may make testing harder. 17:24:04 http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0039.html 17:24:12 Jatinder: I think there is value in the Web Perf WG specing and defining the meanings of the lazyload and postpone attributes in a Resource Priorities spec. As the two attributes only apply to some elements, we will need to define which attributes support lazyload or postpone. Should we define those in this spec or in HTML5? 17:32:33 James: As long as its defined correctly, I don't care where it goes. I think we should let Philippe and others figure that out. 17:32:41 Daniel: Should we bring this up with HTML WG? 17:33:52 Jatinder: I think we should finish defining the interface and make sure it meets our performance goals. At that point we can decide if we want to keep it in this spec or not, which I would like to unless there is a technical reason we can't, then we should follow up with HTML. 17:34:01 http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0016.html 17:34:04 Jatinder: Should postpone and lazyload not block the DOMContentLoaded event? Should it also not block the document readiness states? Seems like that should be the case. 17:34:21 James: Yes, seems like we should keep not block those events either. 17:34:55 Jatinder: We will want to make sure we don't mess up the ordering of events, so I think its logical to not block either DOMContentLoaded or document readiness states. 17:35:01 Topic: Use of prefixes in tests 17:35:04 http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0043.html 17:35:08 Jatinder: I think our goal should be to either not use prefixes in test cases at all or include all vendor prefixes in our test cases. For now, User Timing can remove the prefixes entirely from the test cases, as we now have two implementations without prefixes. What are your thoughts on future prefixing? 17:35:23 James: We should probably removing the prefixing code from the User Timing test cases. 17:35:38 Jatinder: Yes, let's do that for now. If we do add prefixing in the future, it should cover all vendors. 17:35:42 Topic: Conference call time slots 17:35:51 Jatinder: Mark from Akamai is interested in joining the conversation on wire protocol and JS injection. He's in Melbourne. Since we have active members from Seattle, San Fran, Boston, Vienna, the only time slot that seems to work for all is 1PM PST (1PM San Francisco, 4PM Boston, 10PM Vienna, 6AM Melbourne). See http://www.timeanddate.com/worldclock/meetingtime.html?iso=20131113&p1=224&p2=43&p3=259&p4=152&p5=33 17:36:40 Jatinder: We may want to create a seperate time slot for the JS Inspection and wire protocol discussions, if that accomodates people interested in those topics. Since Alois isn't on the call today, let's defer to the mailing list. 17:36:56 rrsagent, generate minutes 17:36:56 I have made the request to generate http://www.w3.org/2013/09/11-webperf-minutes.html JatinderMann 19:04:48 Zakim has left #webperf