Good morning! Having issues with the password again

trackbot, start telcon

<trackbot> Meeting: Web Fonts Working Group Teleconference

<trackbot> Date: 27 July 2020

<scribe> scribeNick: Persa_Zula

Vlad: Happy birthday to webfonts, 10 year anniversary

Updates on action items

Vlad: We had updates via the email list from Garret
... After we review these items, we need to consider the results and review the criteria

Garret: (Referencing The PFE Codepoint Prediction Results document sent to email)
... The results show that prediction can transfer less bytes than the current methods (unicode range as a reference point)
... Slower 2G connections show good improvement using prediction; for CJK we likely just want to use CJK just for very slow connections, otherwise the improvement isn't as great for those languages
... There are some cases where sending incrementally vs. sending exactly the font you have with exactly what you need in it (optimized, one font) actually performs better
... Arabic and Indic - for these fonts, again we see most improvement in slowest connections. In some cases again prediction can make things worse. We don't want to use prediction universally, may want to target certain scripts and /or connection speeds
... Update on the datasets
... Dataset with glyph IDs, has just a sampling of it so far; waiting for the complete run to finish before sending it out

myles: do we know when the final one will be done?

Garret: about a week, optimistically.
... can send the sampling for myles to try

myles: how are you predicting what codepoints you are sending?

Garret: Collected frequency data from across the web, and sends a prediction based on what hasn't been sent yet. Writeup has details on the algorithm

Document: https://docs.google.com/document/d/1u-05ztF9MqftHbMKB_KiqeUhZKiXNFE4TRSUWFAPXsk/edit

ned: How does connection speed pay into the end to end model of the web? Google can come up with estimates of connection speed. On the client end of things, web browser is going to know not to request certain resources. Is there any resource for a web designer to say what happens to a webpage based on a connection? As a web author, can I say not to use webfonts if a client is slow?

Garret: Yes, there is. Discussed with Chrome team. Two mechanisms: JS API that chrome has that you can ask the page about network performance.
... The second is client hints - headers that the client can send info back on RTT or a broad class (2g, 4g)

jpamental: isn't there also a media query in the works?

Garret: might be related to the client hints, which is header-based

myles: AFAIK, the media query is prefers-reduced-data, which requires user intervention, may not be ideal

<myles> prefers-reduced-data

jpamental: been advocating for this for a while; if you have a loading class, you can write css that doesn't load the webfont, and add the proper spacing and lineheight (and metrics) so that the fallback font can preserve the flow
... i.e., opera mini for this use case. Couple this with checking for bandwidth connection speed. As a designer it would be nice if you could do this to control what is shown
... probably not hard to add this to font-face-observer

myles: 3 ways we might be able to do this. 1. inside font-face rule, allow or disallow these kinds of fonts - website owner has to do bandwidth detection themselves

2. new descriptor in font-face block of network parameters, RTT (50ms), bandwidth: 500kbs - that would mean use streamable fonts if the client matches these requirements 3. for the website to say in the source list - first item is a fancy font, second item is a regular font. We can pick where we want to go in this clarity

jpamental: would be great to declare a fallback - useful for web author. If we don't follow that up with an ability to do things when that happens. This is why he uses FFO to make fallback CSS better. Same issue we have here. Being able to define a parameter is great, but if we dont give web author ability to know what browser has decided, the web author can't design for it

myles: would that be extended for web fonts that fail to load? style differently for when it fails to load also ?

jpamental: yes, because fonts fail to load all the time. web authors need a way to do this. FFO has been sucessor to web-font-loader. Stick a class in there if webfonts aren't present so you can style that stuff separately. if this doesn't show up, we want to adjust the shape of the text and the design of the text so the design doesn't reflow. fantastic technique for folks not to notice that webfonts are still loading
... in slower connections, they need the content, better layout and design that doesn't require the webfonts. may not care about the webfonts being there when they just need the content

myles: there may be an open issue in the css group about this

ned: just wanted clarity on this; sounds like there are some tools that sound a bit complex based on the different pieces needed to react to that information. also sounds like there is an open issue for css; answers a lot of the question that Ned had, thanks for the overview

Vlad: we should plan on doing this going forward; but we need to continue going forward with current agenda :)

Update from Myles

myles: have gathered a lot of data in the last few weeks
... running the analysis takes a long time. investigated the data set during that time
... english is the most common one. Vietnamese is 2nd most common one
... The dataset is heavily weighted to latin
... most of his work focused on CJK because webfonts are not used much in CJK and is interested in changing that
... not that the corpus is wrong, but wanted for all of us to know how the dataset is broken down

Garret: This data is based on web-index which has auto language detection; you're probably right that high proportion of Vietnamese is probably mis-classified

myles: Analysis of cost function for streamable fonts - with the cost metric, there are some places where RangeRequest is equal to Unicode Range, some where it does better. Mostly, it's in the middle

Garret: does this set of data actually include the gsub compression?

myles: yes, and also uses all the fonts in the corpus
... Time spent - this is latency. What you can see for total run - whole font does better than both methods (PFE and Range Request). Time is the sum of the latencies of all of the network frontiers. Where cost is the sum of the costs of each network fronteier. Cost benefits many small loads. Time benefits from a whole font loading then nothing loading after
... might need to continue looking at cost metric, because of surprising results compared to time

Garret: let's review the original design doc to see if we should make changes to the original cost function and document the justification

myles: overall thesis - Range Request is in the middle of PFE and Unicode Range. There are some surprising items in the results that need more investigation

Garret: note on the dataset - the anonimzation - only allowed to take sequences - can only take something that happens more than 50 times. across different users - biases the data set

Vlad: won't be able to join the call next monday - should we push it to two week?
... ok, next meeting is August 10th. Let's push items from Part 3 of our agenda from today

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/about reduced data/prefers-reduced-data/
Succeeded: s/font-face-oberserver/font-face-observer/
Default Present: Vlad, Persa_Zula, chris, jpamental, myles, Garret, ned, sergeym
Present: Vlad Persa_Zula chris jpamental myles Garret ned sergeym
Found ScribeNick: Persa_Zula
Inferring Scribes: Persa_Zula
Found Date: 27 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.)