[minutes] Web Performance 20151111

Available at
   http://www.w3.org/2015/11/11-webperf-minutes.html


Text version:


Web Performance Working Group Teleconference

11 Nov 2015

    [2]Agenda

       [2] 
https://lists.w3.org/Archives/Public/public-web-perf/2015Nov/0006.html

    See also: [3]IRC log

       [3] http://www.w3.org/2015/11/11-webperf-irc

Attendees

    Present
           Ilya, Todd, Plh, Yoav, mpb

    Regrets
    Chair
           Todd

    Scribe
           plh

Contents

      * [4]Topics
          1. [5]Page Visibility
          2. [6]requestIdlCallback
          3. [7]Resource Timing
          4. [8]Primer
          5. [9]HR Time
          6. [10]Preload
          7. [11]HR Time
          8. [12]Performance Timeline
          9. [13]next meeting
      * [14]Summary of Action Items

Page Visibility

    <ToddReifsteck>
    [15]https://github.com/w3c/page-visibility/issues/18

      [15] https://github.com/w3c/page-visibility/issues/18

    Todd: current state is that Firefox implements the normative
    state

    Ilya: I missed the point on state change on unload
    ... everyone except FF missed it

    Todd: so should the spec stay the same or not?

    Ilya: we have a mixed of implementations now
    ... I see Boris' point that subscribing to 2 events isn't
    convenient
    ... we could say that everyone should implement the spec
    ... I didn't find any reason in chrome on why it wasn't
    implemented

    Yoav: guessing that safari is using the same old implementation
    from webkit
    ... so same reason

    todd: I'm tracking this down in MS and my guess it's an
    omission
    ... will keep looking

    Ilya: we don't see any issue in implementing but it's low
    priority

    todd: agreed. it's silly to cut it when we all shipped the spec
    together

    Ilya: to clarify: this is about firing the hidden transition on
    unload. we would still remove the unload state
    ... the text is there but I can make it explicit

    Todd: sounds good to me
    ... ditto it will be low priority in edge as well
    ... 6 to 9 months to get to it

    Ilya: I'll add an additional note to the spec

    plh: should we wait to publish a new rec or wait for
    implementations to catch up?

    <ToddReifsteck>
    [16]https://github.com/w3c/requestidlecallback/issues/31

      [16] https://github.com/w3c/requestidlecallback/issues/31

requestIdlCallback

    <igrigorik>
    [17]https://github.com/w3c/requestidlecallback/pull/32

      [17] https://github.com/w3c/requestidlecallback/pull/32

    Ilya: Ross addressed most of the feedback in his PRs

    <igrigorik>
    [18]https://github.com/w3c/requestidlecallback/pull/35

      [18] https://github.com/w3c/requestidlecallback/pull/35

    Ilya: lots of clarification but no material change to the API
    ... the changes look good to me

    Todd: I need to make sure the processing model got fixed, ie
    not tied to Blink model

    Ilya: I believe we did but open a separate issue if not

    Todd: ok, I'll look at the PR and see to merge

Resource Timing

    Todd: almost ready to send some tests to plh
    ... and we'll go from there

Primer

    <ToddReifsteck> a. When will next Primer draft occur? ANSWER:
    Primer repo-- [19]https://github.com/w3c/perf-timing-primer
    Primer can be viewed at--
    [20]http://w3c.github.io/perf-timing-primer/index.html b. What
    are next steps for linking/feedback?

      [19] https://github.com/w3c/perf-timing-primer
      [20] http://w3c.github.io/perf-timing-primer/index.html

    plh: next step is for people to look at it and see if we can
    publish as a working group note

    todd: where will it be linked from?

    plh: wherever we want

    todd: ok, we'll come back to it in 2 weeks

HR Time

    <ToddReifsteck> a. Can we merge?--Current Document
    [21]https://github.com/w3c/hr-time/pull/14

      [21] https://github.com/w3c/hr-time/pull/14

    plh: I think we should merge.

    Todd: ok

    ilya: sound good

    plh: ok, I'll squash the edits and then do a merge

Preload

    [22]https://github.com/w3c/preload/issues/36

      [22] https://github.com/w3c/preload/issues/36

    <ToddReifsteck> a. Allowing empty/invalid ‘as’--
    [23]https://github.com/w3c/preload/issues/36

      [23] https://github.com/w3c/preload/issues/36

    Yoav: 2 issues in it
    ... should we allow invalid or empty as values?
    ... we could special case empty values but seems weird
    ... main concern with invalid values is that devs will set the
    wrong values and will have a hard time figuring why their
    resource is low priority
    ... we can mitigate that on the console

    Ilya: one of the criteria is to allow to do fetch with passing
    as. we're tied to it closely.
    ... the default is to do a low priority fetch
    ... so we could reject invalid types, but would we fail the
    fetch?
    ... the UA could issue a warning but shouldn't reject it
    ... and we should allow empty value, as a declarative XHR

    Yoav: ok. now for CSP directives

    Ilya: in previous iteration, we have many more values for as
    ... CSP is not to block request but to block consuming
    responses
    ... not ideal but we don't break anything like that
    ... if we want to enforce CSP on preload we have some choices

    yoav: besides the impl issue, the problem with the generic
    fetch, devs will have to declare their resources twice, ie
    declare them up-front
    ... but if we want the various types, we could have scriopt,
    worker-script, serivecxe-worker, so we can set the context

    ilya: preload itself is not subject to CSP. there is no csp
    policy that covers it
    ... I believe Mike West is ok with that

    yoav: but if you want to prevent leaking data
    ... if you exempt preload from that, you cannot prevent data
    leaks
    ... it could weaken CSP

    ilya: ok, we should keep iterating
    ... maybe we need a different mechanism to enfore csp on
    preload

    yoav: I think we could extend type
    ... I'll open a new issue on github

HR Time

    <ToddReifsteck> b. Need a changelist without translateTime so
    we can publish REC [24]https://github.com/w3c/hr-time/issues/16

      [24] https://github.com/w3c/hr-time/issues/16

    plh: I'll make a branch
    ... one is a CR with translateTime and then, once moving to PR,
    I'll publish a HR Time 3

Performance Timeline

    <ToddReifsteck> a. Added performance entry buffer--
    [25]https://github.com/w3c/performance-timeline/pull/49

      [25] https://github.com/w3c/performance-timeline/pull/49

    Todd: I'll need to review this

    <ToddReifsteck> b. Any updated thoughts on buffering for
    PerformanceObservers?
    [26]http://www.w3.org/2015/10/webperf-tpac2015-minutes#ptpo-con
    clusion (Should we move this to a GitHub issue?)

      [26] 
http://www.w3.org/2015/10/webperf-tpac2015-minutes#ptpo-conclusion

    Plh: I'll create a github out of our TPAC discussion

next meeting

    Todd, plh, and yoav will be available on 11/25

    Todd will check with Ilya [and indeed, Ilya will be able to
    make it]

Summary of Action Items

    [End of minutes]

Received on Thursday, 12 November 2015 13:23:16 UTC