<jfkthame> webex is showing me a large number of Chris Lilleys.... has he cloned himself?
<jpamental> He does seem rather aggressively present
<Vlad> I am, just muted :)
he's aggressively present in WebEx but not present at all in IRC
<scribe> ScribeNick: myles
Vlad: 1st item: the results of the F2F planning email
... 9 responders
https://www.w3.org/2002/09/wbs/44556/WebFontsWG-Sep2019F2F/results
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
... This is not unexpected.
... myles said "no" to ATypI. Is that true?
myles: If there's a way to call in, it's okay
Vlad: chris and I were thinking of just spending 3 weeks in japan
... we'll work with the host to try to accomodate that.
... There will be an unfortunate time difference.
... jpamental, in one of the past phone calls, you said you would be happy to be our ambassador to ATypI
jpamental: I am more than happy to do that
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
jpamental: Have we talked about a particular day for the meeting?
Vlad: What about Tuesday?
jpamental: Okay, I'll follow up and figure out how to coordinate it.
Vlad: If we have a relatively fast connection, the rest won't be a problem. I can set up VC
... So we don't need anythign from the organizers other than connection
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.
... 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?
<general confusion about which chris is the real chris>
<apparently no chris'es are the real chris>
Vlad: who wants to drive?
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
... It might be complicated to do this. We should consider whether it's worth it
Vlad: I had some thoughts
<Vlad> https://v-fonts.com/
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.
... If a variable font is used for dynamic page layout, then you're also screwed.
... 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
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
... Whatever method we use should support those axes.
... if people are subsetting characters rather than axes, it's more likely to work in a broader circumstances
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
not be low hanging fruit
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.
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
jfkthame: CSS often never is applied to any element on the page. Using the style might overestimate what is needed
Garret_: We are working, in fonttools, partial instancing for variable fonts. For us it wouldn't be extra work to do that.
myles: We don't want to break variable fonts, though, with our solution
Garret_: Agree. We could have a font with many axes and it would be reasonable to use
jpamental: this is a key to adoption
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.
... Breaking variable fonts would be detrimental to many users
... Both Garret_ and I when we mention masters, we meant instances, while culling deltas that wouldn't have any effect
... 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.
Garret_: right.
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
maek the request for them
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.
jfkthame: We'd need to check how that would work in reality
... rasterizers might mess it up
Garret_: Might be difficult to implement in browsers.
... 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.
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
Garret_: The font would present full variable axes, teh developer wouldn't do anything special, and the data would be downloaded transparently
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
... Users don't like flashing text due to progressive enhancemenet
Garret_: yes
jfkthame: The author might want to declare which variations they want to have available, even if they're not in use
Garret_: that makes sense
jfkthame: If you don't do that, you risk more latency. It would still work but it might be slower
myles: abuse!
jfkthame: if they abuse it, they get slower pages and that's their problem
Vlad: Simple attempts to subset variation data woudl tell us what kind of input woudl be most useful
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
jpamental: Good idea to try in a browser. We can see what the experience is like. font playground, axis praxis, w/e
just to see what happens in practice
Garret_: might be more difficult to get it to work with an outside page, but we might be able to get somethign to work
... We can't evaluate the latency impact because we're doing it inefficiently. But we could at least look at data sizes.
... Some of the variable fonts we've seen have lots fo variation data in them
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
... e.g. manifests for service workers. There's a precedent for declaring your intentions
Garret_: That makes sense in general, beyond variable fonts. "These are the characters I'm going to need, make sure they are all there"
jpamental: Have we found people using that a lot with the google fonts API? That's possible, you can say "give me these characters"
Garret_: We don'
... 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.
Vlad: Garret_ can you take an action item to do more investigations?
Garret_: yes
action Garret_ investigate performance savings by slicing variable-ness
jfkthame: I just looked at bahnschrift.ttf file from Windows. The gvar table is half of that file
... which indicates how much could be saved by omitting variations
myles: maybe we can add slicing variable-ness in later
Garret_: <agrees>
<Vlad> action Garret investigate performance savings by slicing variable-ness
Garret_: even if we just did character subsetting, it would already have a ton of value
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
... 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.
RESOLUTION: Tackle slicing variable-ness later.
Vlad: Discussion about requiring Javascript or not in a solution. Adobe wants legacy browsers to be accomodated, which is impossible without JS
... 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?
... how much effort to spend?
myles: spiel about performance
Garret_: I agree. The fallback can be "just send the whole font". We could also use unicode-range as a fallback
Vlad: I like that approach.
<jpamental> I agree w/ Myles - fallback being 'just send the whole thing'
Vlad: We don't have to accomodate users are who on old browsers
Garret_: The current state of the art is to send the whole font, so we're not harming users w/ old browsers
Vlad: In fact, these users wouldn't even know that they're getting the existing codepath
... We need to write this in the evaluation report.
... This section in the evaluation report needs to be substantive
... Let's take it offline, if you have concerns
Garret_: we have this problem today with unicode range is?
myles: the first option
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
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
when the content gets updated after load. You don't know the content was updated 5 seconds ago
Vlad: Whatever delays is needed is fine
... User typing is a special case - switch to a fallback font
myles: is harrrrrrddddd
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
Garret_: We could just respect font-display
myles: would we remove existing content b/c font-display?
Garret_: how does it work today?
myles: independent timers for independent @font-face blocks
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?
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.
... 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.
... it might render webpages unusable
bye, everyone!