<scribe> scribeNick: Persa_Zula

https://www.w3.org/Fonts/WG/track/actions/214

No data available yet, analysis is still running

myles: right now analysis runs without knowledge of network params, still need changes to framework
... today's data update will be the first time the analysis was run on all different methods, but others will happen will come after changes to framework

Garret: will update style checking today so myle's PR will pass automated checks

myles: has optimized fonts from the corpus

Garret: can that be published somewhere?

myles: cannot publish the fonts themselves, but the optimizer is open sourced

Codepoint prediction

Garret: fresh numbers to present
... prediction helps with slower mobile connection results
... you can morph prediction into the unicode-range results with patching
... will be doing a short writeup and sending that out

https://www.w3.org/Fonts/WG/track/actions/221

Garret: no major updates, still working on that
... estimated (optimistically) 2 weeks for the glyph id dataset

Vlad: how long will it take myles for the analysis from that time?

myles: estimate 3-4 weeks from now we can data together

Vlad: can we use that as a final dataset for evaluation report?

myles: yes, we should aim for that

Vlad: Full draft of evaluation report, in September
... 2 weeks will be 10 year anniversary of woff :)
... plan not to miss our call in 2 weeks so we can celebrate :)
... back to the data, Garret, sometimes whole font seems to look good

Garret: yes, because it's got the fewest number of requests, and the framework might need to measure network requests better

sergeym: if the request is done by the browser, that can be measured; but will the JS be able to measure?

myles: either option should have access to network params

Garret: browser might not know specifics to endpoints, but it should have rough idea of global network conditions on the device; needs to talk to someone on the chrome team

myles: saying to use network params from unrelated websites in order to infer the first request?

sergeym: measure of your own connection, not connection to server?

jpamental: a smaller request will get a faster page render, even if in aggregate it's spread across pageviews, no? loading the full font will be worse, right?

Garret: first page, it takes a long time. the font connection completes and gets into the cache. for incremental xfer, slow font load on each page. which scenario is best for the user? hard to say. cost function tries to assign a number to this but not the best measure of user xperience, just a best guess

myles: one of the font-display descriptor's goals is to distinguish between those two cases

Vlad: would it be useful to get a number just for first request cost?

Garret: yes should be straightforward

jpamental: we have objective benchmarks and numbers, but we shouldn't forget about the perceived experience. it can hurt adoption for slower networks

Summary

2 weeks, glyph id dataset, anniversary of woff

Vlad: we will meet again in 2 weeks for the discussion and celebration

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/font-display descriptor's goal/one of the font-display descriptor's goals/
Default Present: Vlad, Persa_Zula, Garret, jpamental, sergeym, myles, ned
Present: Vlad Persa_Zula Garret jpamental sergeym myles ned
Regrets: Chris_Lilley
Found ScribeNick: Persa_Zula
Inferring Scribes: Persa_Zula

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

Found Date: 13 Jul 2020
People with action items: 

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


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)