Meeting minutes
Doodle poll for WebFonts WG weekly meetings: https://doodle.com/poll/2d7p4shwd8pnberp
<Vlad> sergey, do you want to jump on Zoom for introductions?
<Vlad> PFE Eval report is available here: https://
Garret: We're making a technology where each page load downloads only the characters that particular page load actually needs. Last year we made a simulation software to try to determine which approach to this problem works the best and performance characteristics. We made an evaluation report, which explains the results. The summary: We have 2 promising approaches to incremental transfer. One is "patch subset" is complicated: Computing two
subsets on the server side, the subset the client already has and the subset they want, so the server sends a diff for the client to apply.
The second one is called range request, uses HTTP range requests to grab specific ranges of glyph bytes from the glyf table to get what the client needs. Patch/subset performs better, but range-request is much easier to deploy for small websites
Garret: This year we're switching gears to writing the specification. There are still a few open technology questions before we start putting words on the spec. But that will start soon.
myles: the browser and the server will negotiate about which technology to use, not the website. This makes the website much easier to create.
<Garret> https://
Garret: The first request will be special, and the browser will proceed with whatever got negotiated
jpamental: The web author just adds one word and that's enough for opt-in
Vlad: For "should" or "must", in order for authors to rely on the tech, and for servers to optimize, the more that's normative, the better. It worked well for WOFF
myles: WOFF support in a browser isn't required
Vlad: Within WOFF, there was nothing optional.
myles: Inside Brotli, there are tons of optional things
Vlad: Brotli isn't part of WOFF
Vlad: The approach that's more complicated for the server is more simple for the client.
myles: I disagree. The client has to apply the binary diff
Vlad: That's brotli's responsibility
myles: I don't make a distinction between "brotli's responsibility" and "the browser's responsibility"
Serialization format for patch/subset
Garret: Requirement 1: We need to support key/value pairs. This allows for abstraction on top of that.
Garret: Requirement 2: Keys don't need to be strings.
Garret: for compactness.
Garret: Serialization should be compact.
Garret: Part of the message will be a byte array, which should be able to be encoded as just bytes, with minimal overhead.
Garret: Whatever we depend on should be standardized, so we can link to it
Garret: If we've got a message with a newer version of the protocol, an older version should be able to decode it without error, and at least read the older fields.
Garret: The serialization should be fast. This is all render blocking.
Garret: I ruled out protocol buffers because it's not standardizaed
Garret: It's also complicated.
Garret: JSON (actually a stand-in for a large number of text-based encodings): The format is not compact, even if you gzip it. It's still larger than a binary encoding. Most formats in byte arrays have to encode that into text. Also, there are usually perf overheads than binary encodings. E.g. parsing text numbers -> binary
Garret: BSON / UBJSON: These are like binary JSON. But neither of these are standardized. But these are simpler so it might be possible. The field keys must be strings though.
Garret: CBOR and Message Pack. CBOR is better than Message Pack. CBOR uses a single control byte in front of each key / value. Only the first 3 bits are used for the field type, and the remainder of the bits can either hold the data or the length of the data. It has variable length integers, and key/values maps, and don't need a schema to encode, and is standard via IETF
Garret: We should be able to link to that.
Garret: This meets all the requirements. It has many implementations available.
Garret: Message Pack isn't standardized.
Garret: There's also the custom encoding option. We don't need this, specifically because we don't want to reinvent a serialization format when a candidate already exists.
Garret: I encoded a couple test messages via protobuf, CBOR, and custom encoding, and CBOR is largest, but not by much. Especially once messages are big.
Garret: I recommend moving forward with CBOR. Objections?
myles: seems reasonable
Garret: I'm working on an updated version of the protocol design that uses CBOR.
Vlad: That difference is so minor, it's not worth paying attention to.
Garret: The overhead only matters when your messages are in the 10s of bytes. And at that point it doesn't matter. 4k messages cause the difference to disappear in the noise
Naming
Garret: I sent out a list of names last week. <reads list>
myles: Sounds like "incremental" wins
<general agreement>
Vlad: Right now we have "progressive font enrichment" which was cooked up quickly. Now that we're moving into part of developemtn, we can rethink this. If we're doing "incremental" I have a slight distaste to "enrichment"
Garret: "Incremental font transfer"
myles: "Loading" is a term-of-art on the web
jpamental: Agree
Vlad: What about "Lazy font loading"? People could be confused.
Vlad: In that sense, "loading" means you've got a full font file transferred.
jpamental: The whole phrase together means that. "Loading" is a well-understood term for stuff being pulled into the browser. Pre-loading, etc. "Incremental loading" describes really well what's going on to any user.
Vlad: ok.
Vlad: If we have to pick between Incremental Font Loading and Incremental Font Transfer, what do we pick?
Garret: I'm fine with either
myles: +1 for loading
jpamental: +1 for loading
Garret: "loading" wins
Vlad: Can we ask our new members?
venkat: +1 to loading
Bianca: +1 to loading
Moving the call time
ned: I responded during the meeting
ned: Tuesday mornings do not work for me
ned: The Unicode Emoji Subcommittee meets on Tuesdays and Thursday mornings every week
myles: twice a week?!?! that's a lot of emoji
ned: We argue about roadmaps and encoding issues, so that you don't have to.
Garret: Tentatively, we can say that Tuesday morning looks good, but we'll make sure Chris replies before making it official.
Garret: Next meeting will be 2 weeks for now.
Garret: By the next meeting, I plan to make a spec skeleton in Bikeshed.
Vlad: Earlier on this call, if we move to a different room or a different place... ?
Garret:
Garret: