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]


Reply via email to