[minutes] 20160316 Web Performance Working Group

Available at
  https://www.w3.org/2016/03/03-webperf-minutes.html

Text version:

               Web Performance Working Group Teleconference

03 Mar 2016

    See also: [2]IRC log

       [2] http://www.w3.org/2016/03/03-webperf-irc

Attendees

    Present
           Ilya, yoav, plh, todd

    Regrets

    Chair
           Ilya

    Scribe
           plh

Contents

      * [3]Topics
          1. [4]Resource Timing
          2. [5]Beacon
          3. [6]Preload
          4. [7]s/type/as/ attribute
          5. [8]Reporting
          6. [9]hr-time
          7. [10]Velocity
          8. [11]Next meeting
      * [12]Summary of Action Items
      * [13]Summary of Resolutions
      __________________________________________________________

Resource Timing

    [14]https://github.com/w3c/resource-timing/pull/51

      [14] https://github.com/w3c/resource-timing/pull/51

    <igrigorik> preview:
    [15]https://rawgit.com/w3c/resource-timing/continuous-idl/index
    .html

      [15] https://rawgit.com/w3c/resource-timing/continuous-idl/index.html

    Ilya: looked an interesting approach
    ... left some comments

    Todd: *bodySize and nextHopProtocol doesn't seem to be
    implemented

    Ilya: maybe in Firefox

    <igrigorik>
    [16]https://bugzilla.mozilla.org/show_bug.cgi?id=1154309

      [16] https://bugzilla.mozilla.org/show_bug.cgi?id=1154309

    plh: stable is 44

    Ilya: it's marked for 45

    plh: cn we ship HRT, PT, RT, NT, and UT as a batch?
    ... at least a subset of it

    Todd: we'd like all UAs to implement the most recent RECs, but
    they'll implement whatever they can

    plh: I'll make a proposal

Beacon

    [17]https://github.com/w3c/beacon/pull/27#issuecomment-18740407
    5

      [17] https://github.com/w3c/beacon/pull/27#issuecomment-187404075

    <toddreifsteck> [18]https://github.com/w3c/beacon/pull/27

      [18] https://github.com/w3c/beacon/pull/27

    Todd: I'm ok with fetchBeacon

    Ilya: method = POST, body nil as default
    ... headers?
    ... make sense to have but still needs to think
    ... fetchBeacon doesn't return anything...
    ... return true/false
    ... which indicates if it was queued

    Todd: yes, would be exact same. we validate method/headers/body
    and return true if ok

    Ilya: would developers expect a Promise, ie should we return a
    resolved Promise?

    Todd: added async code on unload seems like a bad idea

    Ilya: should we cc Domenic to look at this?
    ... or Anne
    ... we should consider aligning with Fetch on the return value

    Todd: ok
    ... re headers, should we keep it?

    Ilya: I think it's fine
    ... Fetch will set some of the headers for us
    ... so should be optional

    and we're passing it through

    Todd: I'll sort it out later today

Preload

    [19]https://github.com/w3c/preload/issues/32#issuecomment-19024
    3646

      [19] https://github.com/w3c/preload/issues/32#issuecomment-190243646

    Yoav: while implementing and testing preload, ran into fonts
    ... crossorigin attribute got in the way

    Ilya: you're trying to preload a font
    ... link ref=preload crossorigin href=[20]http://same-origin
    ... crossorigin is meaningless here

      [20] http://same-origin/

    Yoav: not sure about that
    ... let's assume that for now

    Ilya: if the browser issues a 3xxx to another origin
    ... then the crossorigin becomes relevant

    Yoav: agreed
    ... for non-redirect, they should match

    Ilya: if the rec is to always have crossorigin attribute and
    the response from same-origin
    ... will that match my @font-face?

    Yoav: asking to put crossorigin on same-origin is weird.

    Ilya: this may trigger different cookies behaviors

s/type/as/ attribute

    <igrigorik> [21]https://github.com/w3c/preload/pull/59

      [21] https://github.com/w3c/preload/pull/59

    Ilya: I got confused while trying to fix the spec and I'd like
    to restore the old logic and introduces as

    Yoav: if you change from one image format to an other, should
    we trigger a new request?
    ... because we're changing the client logic?

    Ilya: ok. type only afects if it got triggers in the first
    place

    Yoav: if you want to trgigger a different download, you should
    change something else, type won't be enough
    ... if it was fetched type won't matter

    Ilya: checking the html spec...

    Yoav: I filed some bugs around that

    Ilya: html has 2 items for type
    ... and we're mirroring that

    <igrigorik>
    [22]https://html.spec.whatwg.org/#concept-link-obtain

      [22] https://html.spec.whatwg.org/#concept-link-obtain

    <igrigorik>
    [23]https://html.spec.whatwg.org/#link-type-stylesheet

      [23] https://html.spec.whatwg.org/#link-type-stylesheet

    Ilya: ok, will drop the first point from the PR
    ... but we'll keep both type/as

    Tp[oc: Reporting

Reporting

    [24]http://w3c.github.io/reporting/

      [24] http://w3c.github.io/reporting/

    Plh: I'll set up the repo for automatic bikeshed generation

    ILya: new CSP spec is using it
    ... I'd like to push out the first draft to get feedback

    Todd: it's a subset of NEL

    plh: are ok to adop and publish a FPWD?

    Todd: looks fine

    Yoav: fine

    RESOLUTION: publish as FPWD

hr-time

    Todd: when you're up in Seattle and be around a whiteboard

    Ilya: ok

Velocity

    Ilya: we are currently scheduled for second day for keynote
    ... looking to reschedule on first day
    ... full day meetup thing seems unlikely
    ... option: move keynote on first day and do a BOF in the
    evening
    ... option 2: during lunch hour, they have office hours. we
    could do office hours after our keynote
    ... but setup isn't the best
    ... option 3: find a meeting room but we would compete with
    other scheduled meetings

    yoav: 1 & 3 sounds reasonnable. 1 sounds the best
    ... 2 doesn't sound productive

    Todd: +1 to Yoav

    Plh: ditto

    ok, preference is 1, 3, 2

Next meeting

    March 23rd, 10am PT?

    plh to check

Summary of Action Items

Summary of Resolutions

     1. [25]publish as FPWD

    [End of minutes]

Received on Friday, 11 March 2016 21:07:46 UTC