See also: IRC log
<trackbot> Date: 11 September 2013
<RobDickinsonFromDell> Hellow
http://lists.w3.org/Archives/Public/public-web-perf/2013Jun/0001.html
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.
... 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.
James: My interpretation was that this was just something people can fall for.
Jatinder: I don't think we should take this change.
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.
... 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.
James: Seems like you want to
compare when a worker sent data and when it was recieved, so
you can figure out the latency.
... 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.
http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0042.html
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.
James: I am leaning towards MAY, but I recognize that it may make testing harder.
http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0039.html
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?
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.
Daniel: Should we bring this up with HTML WG?
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.
http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0016.html
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.
James: Yes, seems like we should keep not block those events either.
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.
http://lists.w3.org/Archives/Public/public-web-perf/2013Sep/0043.html
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?
James: We should probably removing the prefixing code from the User Timing test cases.
Jatinder: Yes, let's do that for now. If we do add prefixing in the future, it should cover all vendors.
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
... 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.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: JatinderMann Inferring Scribes: JatinderMann Present: Daniel Rob Jatinder simonjam WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 11 Sep 2013 Guessing minutes URL: http://www.w3.org/2013/09/11-webperf-minutes.html People with action items:[End of scribe.perl diagnostic output]