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
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 :)
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.)[End of scribe.perl diagnostic output]