Raw minutes from WebFonts WG call, March 28

Folks,
I forgot to invite rrsagent to "listen" on our call, therefore, minutes are only available in raw text format. Maybe Chris knows how to convert this back to official minutes after the fact.

#webfonts: (no topic set)
[12:00] == Vlad [~Vlad@public.cloak] has joined #webfonts
[12:00] == jfkthame [~jfkthame@public.cloak] has joined #webfonts
[12:00] == Garret [~Garret@public.cloak] has joined #webfonts
[12:00] <myles> present+ myles
[12:01] <jfkthame> present+
[12:01] <Garret> present+
[12:01] <jfkthame> webex is showing me a large number of Chris Lilleys.... has he cloned himself?
[12:02] <sergeym> present+
[12:03] <Vlad> present+
[12:03] <jpamental> He does seem rather aggressively present
[12:04] == ned [~ned@public.cloak] has joined #webfonts
[12:04] <Vlad> I am, just muted  :)
[12:04] <myles> he's aggressively present in WebEx but not present at all in IRC
[12:05] <myles> ScribeNick: myles
[12:05] <myles> Vlad: 1st item: the results of the F2F planning email
[12:05] <myles> Vlad: 9 responders
[12:05] <myles> https://www.w3.org/2002/09/wbs/44556/WebFontsWG-Sep2019F2F/results
[12:05] <myles> Vlad: 1 said he would not be able to show up anywhere. Everyone else had at least 1 "yes". The majority of answers prefer ATypI
[12:06] <myles> Vlad: This is not unexpected.
[12:06] <myles> Vlad: myles said "no" to ATypI. Is that true?
[12:06] <myles> myles: If there's a way to call in, it's okay
[12:07] <myles> Vlad: chris and I were thinking of just spending 3 weeks in japan
[12:07] == Garret_ [~Garret@public.cloak] has joined #webfonts
[12:07] <myles> Vlad: we'll work with the host to try to accomodate that.
[12:07] <myles> Vlad: There will be an unfortunate time difference.
[12:07] <myles> Vlad: jpamental, in one of the past phone calls, you said you would be happy to be our ambassador to ATypI
[12:08] <myles> jpamental: I am more than happy to do that
[12:08] <myles> Vlad: Excelent. I don't know how far in advance we need to let them know about our plans, but if you know how to proceed, we would need a room for 10 people with a projector and hopefully fast interenet
[12:08] == Garret [~Garret@public.cloak] has quit [Ping timeout: 180 seconds]
[12:08] <myles> jpamental: Have we talked about a particular day for the meeting?
[12:08] <myles> Vlad: What about Tuesday?
[12:09] <myles> jpamental: Okay, I'll follow up and figure out how to coordinate it.
[12:09] <myles> Vlad: If we have a relatively fast connection, the rest won't be a problem. I can set up VC
[12:09] <myles> Vlad: So we don't need anythign from the organizers other than connection
[12:09] <myles> Topic: WOFF2 bugs
[12:10] <myles> Vlad: There were a few bug reports. The first one is explanable, but the second one I don't know how it happened. We missed part of a sentence.
[12:10] <myles> Vlad: I know we already have 1 errata. Are we going to take care of both of these changes at the same time when we publish the second errata?
[12:10] <myles> <general confusion about which chris is the real chris>
[12:11] <myles> <apparently no chris'es are the real chris>
[12:12] <myles> Topic: Enriching Variable Fonts
[12:12] <myles> Vlad: who wants to drive?
[12:13] <myles> Garret_: We we wondering if we should also consider a variable being something that can be enriched in a font. If the initial load only has one point in the design space, we can just send that and not any deltas. And we can continue sending masters one by one
[12:13] <myles> Garret_: It might be complicated to do this. We should consider whether it's worth it
[12:13] <myles> Vlad: I had some thoughts
[12:13] <Vlad> https://v-fonts.com/
[12:14] <myles> Vlad: Here is a special-purpose page that showcases variable font capabilities. In order to speed up that first page, you don't have to download all the variable information, you only need the specific instances. But that defeats the whole purpose, because as soon as you touch a slider, you're screwed.
[12:14] <myles> Vlad: If a variable font is used for dynamic page layout, then you're also screwed.
[12:15] <myles> Vlad: I agree there are so many different types of data in the font that might not be needed or usable for a particular page. But we don't know what is expected to be used in the future
[12:15] <myles> jpamental: If people are using variable fonts to design better, then they're ilkely to use those axes more than they are presently calling for separate instances
[12:16] <myles> jpamental: Whatever method we use should support those axes.
[12:16] <myles> jpamental: if people are subsetting characters rather than axes, it's more likely to work in a broader circumstances
[12:17] <myles> ned: I also am curious as to whether or not it would be beneficial given the amount of work it would take. There are no masters encoded in a variable font; it's a set of deltas. Saying you "add more masters", that's terminology from designers. Depending on how the glyph data has been compiled, it might not be a huge amount of data, but it could be a fair amount of work in subsetting. We shouldn't design anything out of spec if possible, but this might
[12:17] <myles>  not be low hanging fruit
[12:18] <myles> Garret_: I agree. It might be worth doing some experimentation to see if there is any benefit. We can simulate what it would look like on a typical page to see if it would save bytes.
[12:19] <myles> jpamental: Given that we have all the CSS of the page to look at, we have all the scenarios covered, even if there are media queries to change the width if the viewport changes. We would know how much of the font is used ont he page
[12:20] <myles> jfkthame: CSS often never is applied to any element on the page. Using the style might overestimate what is needed
[12:20] <myles> Garret_: We are working, in fonttools, partial instancing for variable fonts. For us it wouldn't be extra work to do that.
[12:21] <myles> myles: We don't want to break variable fonts, though, with our solution
[12:21] <myles> Garret_: Agree. We could have a font with many axes and it would be reasonable to use
[12:21] <myles> jpamental: this is a key to adoption
[12:22] <myles> Vlad: My argument for not breaking things - if the author tells us to use a variable font, we can analyze other data to determine which region of the font is used, but the variability needs to be preserved.
[12:22] <myles> Vlad: Breaking variable fonts would be detrimental to many users
[12:23] <myles> Vlad: Both Garret_ and I when we mention masters, we meant instances, while culling deltas that wouldn't have any effect
[12:24] <myles> Vlad: If you have a font from plain-condensed and ultrathin-heavy, you have two different delta sets, one from ultrathin-regular and one for regular-heavy. Those are easy to split, and we can eliminate some deltas.
[12:24] <myles> Garret_: right.
[12:25] <myles> jfkthame: If we allowed variability to be omitted and dynamically added, that raises the question of how would we make sure the potential variablility is still exposed to the user agent, in terms of font selection and requesting additional styles. If you have a resource that was just plain, non-variable font, with the potential to send deltas separately, we still need the font to be recognized by the UA as having the axes, otherwise the UA will never
[12:25] <myles>  maek the request for them
[12:25] <myles> Garret_: What we want to do is keep the fvar table, and just the deltas from gvar, and bring those down as needed. The font would appear as variable, just wouldn't have variable information.
[12:26] <myles> jfkthame: We'd need to check how that would work in reality
[12:26] <myles> jfkthame: rasterizers might mess it up
[12:26] <myles> Garret_: Might be difficult to implement in browsers.
[12:27] <myles> Garret_: we have tried to subset variable data. We can do full instancing of fonts, and we are working on partial instancing where we remove some of the deltas. Once we do that, we should run some tests to see how many bytes could be saved. will inform later work.
[12:27] <myles> Vlad: We can approach this from two ends. 1) The point of view of the page developer, using what the developer expects - jpamental's expectations
[12:28] <myles> Garret_: The font would present full variable axes, teh developer wouldn't do anything special, and the data would be downloaded transparently
[12:28] <myles> Vlad: 2) Once we have an initial implementation of variable data subsetting, that would inform what kind of <missed> we would need to do it correctly without adding too much latency
[12:29] <myles> Vlad: Users don't like flashing text due to progressive enhancemenet
[12:29] <myles> Garret_: yes
[12:29] <myles> jfkthame: The author might want to declare which variations they want to have available, even if they're not in use
[12:29] <myles> Garret_: that makes sense
[12:29] <myles> jfkthame: If you don't do that, you risk more latency. It would still work but it might be slower
[12:30] <myles> myles: abuse!
[12:30] <myles> jfkthame: if they abuse it, they get slower pages and that's their problem
[12:31] <myles> Vlad: Simple attempts to subset variation data woudl tell us what kind of input woudl be most useful
[12:32] <myles> Garret_: Once we have support in fonttools, i'll update the demo that I previously sent out to get some idea of what to expect
[12:32] <myles> jpamental: Good idea to try in a browser. We can see what the experience is like. font playground, axis praxis, w/e
[12:32] <myles> just to see what happens in practice
[12:33] <myles> Garret_: might be more difficult to get it to work with an outside page, but we might be able to get somethign to work
[12:33] <myles> Garret_: We can't evaluate the latency impact because we're doing it inefficiently. But we could at least look at data sizes.
[12:33] <myles> Garret_: Some of the variable fonts we've seen have lots fo variation data in them
[12:34] <myles> jpamental: It might manifest in what you want in an initial load. If that mechanism were created, you overcome a little bit of the "developer laziness" of "just give me everything" because they have to put a little bit of effort into saying "my css uses this range of width, this range of weight". People can figure out the tools to make the creation of these better. Someone who is concerned with performance has a story they can tell
[12:35] <myles> jpamental: e.g. manifests for service workers. There's a precedent for declaring your intentions
[12:35] <myles> Garret_: That makes sense in general, beyond variable fonts. "These are the characters I'm going to need, make sure they are all there"
[12:35] <myles> jpamental: Have we found people using that a lot with the google fonts API? That's possible, you can say "give me these characters"
[12:35] <myles> Garret_: We don'
[12:36] <myles> Garret_: We don't see that often, because the system is rigid. Most pages don't know a priori what all the characters on the page are. We see some use for ads.
[12:37] <myles> Vlad: Garret_ can you take an action item to do more investigations?
[12:37] <myles> Garret_: yes
[12:37] <myles> action Garret_ investigate performance savings by slicing variable-ness
[12:37] * trackbot is creating a new ACTION.
[12:37] <@trackbot> Error finding 'Garret_'. You can review and register nicknames at <https://www.w3.org/Fonts/WG/track/users>.
[12:37] <myles> jfkthame: I just looked at <missed> file from Windows. The gvar table is half of that file
[12:38] <myles> jfkthame: which indicates how much could be saved by omitting variations
[12:38] <jfkthame> s/<missed>/bahnschrift.ttf/
[12:38] <myles> myles: maybe we can add it in later
[12:38] <myles> Garret_: <agrees>
[12:39] <myles> s/add it in/add slicing variable-ness in/
[12:39] <Vlad> action Garret investigate performance savings by slicing variable-ness
[12:39] * trackbot is creating a new ACTION.
[12:39] <@trackbot> Created ACTION-207 - Investigate performance savings by slicing variable-ness [on Garret Rieger - due 2019-04-04].
[12:39] <myles> Garret_: even if we just did character subsetting, it would already have a ton of value
________________________________
[12:40] <myles> jpamental: Bahnschrift would help English speakers, but in CJK, the characters are going to be a massive amount of the data. There still would be variable font perf gain just by doing character subsetting. That's the difference between being "usable on the web" and not
[12:40] <myles> jpamental: That gets us to a place where we're still making it better going forward, but we can keep it in the back of our mind and leave room for it.
[12:41] <myles> RESOLVED: Tackle slicing variable-ness later.
[12:41] <myles> Topic: Progressive Font Enrichment strategy and legacy support
[12:42] <myles> Vlad: Discussion about requiring Javascript or not in a solution. Adobe wants legacy browsers to be accomodated, which is impossible without JS
[12:42] <myles> Vlad: there would be a JS implementation that's not needed in a new browser. If we were to do that, we would have to provide a blessed JS implementation?
[12:43] <myles> Vlad: how much effort to spend?
[12:44] <myles> myles: spiel about performance
[12:44] <myles> Garret_: I agree. The fallback can be "just send the whole font". We could also use unicode-range as a fallback
[12:45] <myles> Vlad: I like that approach.
[12:45] <jpamental> I agree w/ Myles - fallback being 'just send the whole thing'
[12:45] <myles> Vlad: We don't have to accomodate users are who on old browsers
[12:45] <myles> Garret_: The current state of the art is to send the whole font, so we're not harming users w/ old browsers
[12:46] <myles> Vlad: In fact, these users wouldn't even know that they're getting the existing codepath
[12:46] <myles> Vlad: We need to write this in the evaluation report.
[12:46] <myles> Vlad: This section in the evaluation report needs to be substantive
[12:47] <myles> Vlad: Let's take it offline, if you have concerns
[12:47] <myles> Topic: Flashiness
[12:50] <myles> Garret_: we have this problem today with unicode range is?
[12:51] <myles> myles: the first option
[12:51] <myles> Garret_: there should not be many instances where you have to load from the network. We have lots of caches. This shouldn't be a common problem
[12:53] <myles> Vlad: Given the frequency and occurrences, we need to look at two separate sides. One action that makes an update happen, then they'res everyone else who is an observer and has their content updated at that moment in time. I think that the behavior we found to be objectionable for regular font downloads, that behavior that was objectionable in the page load because you ahve specific time references (time you click) that time reference is non existent
[12:53] <myles>  when the content gets updated after load. You don't know the content was updated 5 seconds ago
[12:53] <myles> Vlad: Whatever delays is needed is fine
[12:54] <myles> Vlad: User typing is a special case - switch to a fallback font
[12:56] <myles> myles: is harrrrrrddddd
[12:56] <myles> jpamental: Hiding content isn't desirable. Instead, authors should use better styles to avoid reflows. That's why people are adopting font-display: swap or fallback. Because people don't want that delay. People can use some other mechanism if they want to hide it
[12:56] <myles> Garret_: We could just respect font-display
[12:57] == chris [chris@public.cloak] has joined #webfonts
[12:58] <myles> myles: would we remove existing content b/c font-display?
[12:58] <myles> Garret_: how does it work today?
[12:58] <myles> myles: independent timers for independent @font-face blocks
[12:59] <myles> Vlad: Maybe could draw different boundaries between not showing updated content vs delaying showing updated content. Delaying wouldn't be objectionable to users. jpamental, do you agree?
[13:00] <myles> jpamental: I suppose there's reasonably a difference between initial page load and changing content. Initial page load, there are many circumstances where network latency renders pages invisible for a really long time. That was a huge mistake to adopt that as the standard. People use a font loading manager to style the fallback font.
[13:01] <myles> jpamental: When that is in place, displaying fallback content and swapping it for the live webfont when it's loaded is less jarring, people often don't even notice. For posting a comment, i guess it's okay, but delaying stuff under optimal circumstances is suboptimal when subways or tunnels or elevators get involved.
[13:01] <myles> jpamental: it might render webpages unusable
[13:01] <myles> bye, everyone!
[13:02] == Garret_ [~Garret@public.cloak] has quit ["Page closed"]