<trackbot> Date: 22 June 2011

<scribe> scribe: Jatinder Mann

Jatinder: As per last week’s action items, we had sent out a proposal that combined inheritance with the current spec: http://lists.w3.org/Archives/Public/public-web-perf/2011Jun/0075.html.
... What are your thoughts?

James: I liked it a lot.

Zhiheng: It looks cool!
... Thoughts about Jatinder's suggestion about putting them into different namespace?

Jatinder: That was an initial suggestion to give structure. I feel that the current proposal gives us that structure.

James: I agree that the new proposal takes care of that.

Zhiheng: Ok.

Jatinder: We may want to go ahead and make changes to Navigation Timing to include the unified behavior and then solicit feedback from the mailing list.

James: Are there any other mailing list that have more traffic to give feedback?

phl: We can use Web Apps, but they may not give feedback here.

Jatinder: Is there any impact on Navigation Timing spec if we add the new interfaces?

phl: It will remain in PR, it would not necessarily go to CR, but it would be one month in LC.

Jatinder: If we go to LC, aren't we opening all areas of the spec to question, not just the delta?

phl: We can set the bar higher for existing portions of the spec and focus feedback on the deltas.
... We may also want to add prototype tests to the test suites now that the prototype is not as simple as before.

Karen: Agreed.

The WG agrees to update the Navigation Timing spec to add the current unified proposal sent last week and send that out for additional feedback. Jatinder will send some text to Zhiheng to consider adding to the spec.

Discuss Battery Status specification feedback.

Jatinder: Let’s discuss feedback on the Battery Status spec: http://dev.w3.org/2009/dap/system-info/battery-status.html
... Seems like a very simple API set: “isPlugged” gives you whether the device is on battery, “level” gives you a scaled representation from 0 – 100 of your battery level, and batterystatus gets fired when the battery status changes (level varies by 1% or isPlugged changes).
... Not sure of the value of initBatteryStatusEvent(). Similar idea to the initEVent() in DOM Level 2 and 3 specs, http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event-initEvent.

The WG is relatively happy with the spec based on description on the call.

Discuss requestAnimationFrame open issues.

Jatinder: Let’s go through each open issue on requestAnimationFrame and get an update from the editors - http://www.w3.org/2010/webperf/track/issues

<heycam> http://www.w3.org/2010/webperf/track/products/5

ISSUE-1: Scheduling processing model needs to be more tightly defined 2011-05-18

<trackbot> ISSUE-1 Scheduling processing model needs to be more tightly defined notes added

Cameron: Needs to be tightened up. Otherwise no real issues.

Jatinder: We don’t have any issues here.

Next: Callback time parameter needs definition 2011-05-18

Nic: Are we defining the exact time that the frame was going to be drawn?

Cameron: Yes.

Nic: In the case that the callback takes more than one refresh rate, we may want to rely on the previous frame instead the next frame.

Cameron: Since they are clock times, it shouldn’t matter. Maybe we should use the clock tick time.

Next: Animation frame times should be monotonically increasing 2011-05-18

<plh> http://www.w3.org/TR/navigation-timing/#mono-clock

Nic: If I remember correctly on the list, as long as the timestamp parameter is also monotonically increasing, this would make sense.

Jatinder: This issue should also consider including window.animationStartTime.

Cameron: Yes.

Next: We perhaps should support an element parameter to requestAnimationFrame()

Jatinder: We should consider making this optional.

Nic: It would be hard to do feature detection for an optional argument

Jatinder: This argument defines element visibility. Web developers should a graceful fallback to visible.

Next: Expected callback rates should be documented 2011-05-18

Cameron: We had agreed that the expected callback rate should match the display refresh rate. We would probably not want to make this a must statement, but rather should.

Jatinder: Agree.

Next: Spec needs to clarify expected behavior for duplicate calls of the same callback 2011-05-25

Jatinder: I believe everyone on the list agreed to duplicate callbacks.

Cameron: Yes.

Next: FrameRequestCallback interface should be designated as Callback=FunctionOnly

Cameron: Whatever WebIDL defines, requestAnimationFrame should follow, since this issue isn't local to just requestAnimationFrame.

Jatinder: Agreed.
... Considering there are two implementations for this spec, and we are all relatively in agreement with the design, I expect this spec to move quickly. When do we expect to have all these issues completed by?

Cameron: I been busy of late. Will discuss with James further. Hopefully, I will start making changes next week.

<heycam> http://www.w3.org/mid/4DF60DEF.7060005@labri.fr

<heycam> https://mail.mozilla.org/pipermail/es-discuss/2011-March/013227.html

Cameron: David brought up this issue, which should be raised as an issue.

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
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
Found Scribe: Jatinder Mann

WARNING: Replacing list of attendees.
Old list: +1.650.691.aaaa James [Microsoft] Plh
New list: [Microsoft] heycam Plh +1.650.253.aaaa

Default Present: [Microsoft], heycam, Plh, +1.650.253.aaaa
Present: [Microsoft] heycam Plh +1.650.253.aaaa Jatinder Mann Zhiheng Wan JamesS Nic Jansma Karen Anderson

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 22 Jun 2011
Guessing minutes URL: http://www.w3.org/2011/06/22-webperf-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.