<Vlad> scribenick: Persa_Zula

recent charter overview

<chris> https://www.w3.org/Fonts/WG/webfonts-2018.html

PFE Evaluation Report - Expected completion date Q2 2020

Vlad: We have one full month ahead of us for completing this task. When we received the approval for the charter is that we had a very long timeline to plan accordingly. So if we follow the plan we can stay on track.

chris: The report needs to be clear instead of saying "we did a bunch of work".

Vlad: the existing data is pointing to a winning approach, unless a new approach is modeled and becomes a part of the framework that tells a different story, the one we have as a candidate will remain as much. This is what was done, what was delivered, and the analysis framework results - this is the one that will be subject for recommendation track deliverable

myles: feels he has outstanding work holding some of this up. will be devoting most of this week on this task. we haven't decided yet what the value of a solution being available to every website is. we understand that one solution is better for performance, but maybe there is a solution that can exist anywhere.
... if all the solutions aren't presented by a certain point we need to move on. but whatever solution we make presumably will live for a long time and it's important to get this right.

Vlad: agreed, and why we brought this up a few months ago; end result needs to have a decision to standardize on something. different factors we need to take into consideration. but we can't stay in this stage for a long time. good solution is probably better than best optimal solution that doesn't materialize

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

Garret: should have a completely public data set at the end of this week; completed run of analysis with it and working on report to share by the end of the week
... (got permission to make the dataset public)

Vlad: should we hold next call in a week from now? sounds like we will have some things in the next week

Garret: yes

Open action items (https://www.w3.org/Fonts/WG/track/actions/open)

myles: investigating how compression will work - woff2 is the dominate compressed format on the web. woff2 spec dictates that woff2 dictates that it must be compressed using brotli
... brotli compression format breaks content into collection of blocks; to decode the block you need the block header. the contents of a block are not guaranteed to be independent of other blocks but encoder can be set to do so.
... suggests a design like what Mike Rumford (sp?) suggested
... two approaches to evaluate. size is not always the same for every set of inputs. one can be a fixed compression ratio that is written into the spec; or a different approach where we write the block boundries in a different table in the font. tradeoffs between both

Vlad: everything thrown into the encoder is a binary dataset; it doesn't care what the data represents. the size of the input block makes a big difference in the compression ratio; we can treat every single update as a particular byte range to be uploaded - that can be considered your block. nothing would stop us from using brotli for whatever block size we want to compress. is there a limit in the brotli that is documented? are small b[CUT]
... 1. do you see any reason not to consider a byte range determined by the browser?

chris: most servers can use brotli as a general compression metho

Vlad: can't we use just part of the font file as a generic data set for brotli

myles: yes
... was looking at compression ratios of zlib vs brotli; compression ratios for brotli is 5-10% better than zlib
... zlib is interesting because apache comes out of the box, so most webservers support zlib out of the box
... given that brotli has better compression ratios, even if the server used the default compression, it wouldn't be that much worse to use the server default

Vlad: small data sets might not be worth compressing
... what is the minimal practical size of data size to compress using brotli to get real benefit from it?

myles: if the block size is too small, compression ratio is bad; if the block size is too big, browser has to download too much than what is needed to render page

Garret: public data set in the analysis will allow us to fire different block sizes through it

myles: two modes - compressed or non-compressed. brolti's compression could be a pass-through identify function. can create a valid woff2 file without any compression, but also allows the server to use the range request

sergeym: for most servers, they use pre-compiled woff2 files

myles: the model i'm looking at is where the font foundry or the website hoster pre-processes the optimized font file, then they drop it on any web server

sergeym: will packages be created dynamically?
... we care about brotli running on the server, right?

myles: in the model I'm looking at, brotli is run in a pre-processing step

Vlad: if the id function built into brotli, brotli was used for being part of woff2 spec, but as brotli became generic http and asset usage points. is it smart enough to recognize if something has already been compressed?

myles: not an issue of fonts specifically; it's possible servers can double compress, don't know
... i have a path forward on it. this week will be working on finishing this optimization tool and adding it to the test harness.

Vlad: once that's done, we can pass it through brotli and see what happens

Garret: that is left up to the individual implementation of each transfer method

myles: a few questions for the group
... so far everyone has been approaching this from a server-oriented POV. what changes would need to be performed in the browser? What is the CSS mechanism to trigger it? what do we encourage browsers to minimize flashy text?
... what are people thinking about with those q's, we cant ship without answering those questions

Garret: do we want to get to a point for prototype in a browser to evaluate how it behaves to an end user
... it might help us develpp some anti-flashyness ways of doing things

jpamental: that will help us evaluate how much we have to do
... a variable fallback font might be interesting
... to minimize what people would notice
... it would be akin to making decisions about font-display

Garret: can use a blocking-type strategy

myles: font-display might not be sufficent

jpamental: it's not sufficient, but as an example of a switch of how you want it to behave
... one of the situations with user-generated content, giving some way in CSS to make sure which stuff you want to be downloaded? u
... putting some control, like preloading to it, so you're less likely to end up in this situation with web content like user comments

myles: internal discussions is using prediction to load some characters before they're actually requested

Garret: browsers already do a ton of predictions, not unreasonable to go that route

myles: interested in the mechanism; sites would need an opt-in for the the streamable approach likely - do we know what that looks like?

Garret: for patch-subset appraoch, a declaration in the CSS would have to be made. But with myles' approach, regular woff2 on the backend, having an opt-in might make sense too

myles: opt-in necessary on one level if a browser needs to take a different code path
... even if a browser doesn't need it mechanically, there is a user-visable behavior difference with streamable font

Garret: imagine it would be a different format in the font-face rule

jpamental: maybe `font-streaming: true` or putting it in the syntax with color fonts and variable fonts - that syntax is moving towards supporting other formats also

Garret: whatever we do for that, we need to make sure it works for browsers that don't support it
... if it's in the fallback list, browsers can fallback to the type it supports

myles: this is where the two approaches differ; the approach that Garret was working on it, if it browser doesn't understand what codepath to take for the binary diff, then the URL is dead to the browser
... in the approach myles is looking at, if the browser doesn't understand range requests, it can still use the URL

Garret: for blocked compression, a browser might need an alternate version of the woff2 that is just fully compressed

myles: how the compression results shakes out might help determine this
... in the approach that Garret is championing, is there a way without an opt-in for a browser to know... maybe an extra header?

Garret: fallback case can be supported with the same URL - can be built into the protocol

myles: both approaches might be able to live in harmony
... if a browser wants the smart server approach, it can send headers; if it's the range-request, it can send the range-request to the same URL

Vlad: is it the browser's choice?

Garret: you can make it up to the page author or the browser - something we need to think about

Vlad: experience in different standards discussions; if at all possible we should look at a single solution that is relatively straightforward to use; doesn't matter about the complexity to implement. the least number of options is better
... we should strongly consider not giving different options unless there's a clear need for it

myles: we'll have to see; making a solution that only works for web font services would be unfortunate
... having one solution that works really well but only works for a company with server SREs but doesn't work for "Joe's website", we probably need a solution for "Joe's website" too

Vlad: agreed. whatever solution we standardize will have Open Source solution for both server and client components. if it's downloadable and installable, doesn't matter if it's owned by an entity or small individuals.
... both solutions will probably get to comparable ease of use because of the examples provided from group
... we started the analysis because we all believed that we wanted user experience to be better. if we have a clear winner for the best user experience we will probably select that
... user exerience first, then implementation complexity, then followed by additional tools to enable use of the new technology
... doesn't want our recommendation to do anything related to the design-side of things. that's completly the freedom of the developers using it
... all design decisions should be in the hands of the people using them

jpamental: what we do need to do is define the path by which these can be accomplished

Vlad: that's what I mean by tools

jpamental: agreed

myles: focusing on the user experience is agreeable. not realistic for the world to upgrade their servers. most people that run websites - the people don't even run the webservers -- people don't have control over what modules are running, just control of the files in the host
... the question about what the design of the system is, is a part of this effort. we can't make a server-side solution without saying what browsers should enforce

Vlad: 1. user expereince; 2. complexity of implementation is 2nd (everythign on browser and server-side; 3. tools, which include the components that enable the developer and browser to create a system where the font streaming is possible (what requests are sent and how to be formatted)
... not including design decisions - not including preconvieved design decisions like variable font fallbacks, etc
... those things are for web authors, not part of the w3c recommendation

myles: web authors need some controls; there should be one or a few different designs for how this technology can fit into a website and authors can select between those ways
... authors shouldnt have to write JS to use this tech

Vlad: agreed
... we'll pick up this discussion next week

jpamental: we are now figuring out what success is for the deliverable
... not having to configure web server differently should be an important thing we consider

myles: we're creating a new technology; it's up to us to determine how to use it. make it easy for poeple to use it well, and hard to use it poorly

Vlad: two major topics for next week - continued discussion on the success criteria, as well as our open action items

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/We have one full month ahead of us for completing this task. When we received the approval for the charter is that we had a very long timeline to plan accordingly. So if we follow the plan we can stay on track./Vlad: We have one full month ahead of us for completing this task. When we received the approval for the charter is that we had a very long timeline to plan accordingly. So if we follow the plan we can stay on track./
Succeeded: s/ste/step/
Succeeded: s/rul/rule/
Default Present: Vlad, Persa_Zula, Garret, sergeym, chris, jpaemntal, jpamental, myles
Present: Vlad Persa_Zula Garret sergeym chris jpaemntal jpamental myles
Found ScribeNick: Persa_Zula
Inferring Scribes: Persa_Zula
Found Date: 01 Jun 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.)