Re: [w3ctag/design-reviews] Incremental Font Transfer: Patch Subset (Issue #849)

Howdy, y'all!

> Incremental Font Transfer: Patch Subset
> ...
> Myles C. Maxfield @litherum (Apple, editor)

I'm not an editor of the patch subset part...

> Is there a link to the WebKit position?

I don't believe we have a published one. Perhaps that is the cause for the confusion in this issue.

> it has been [a while](https://www.w3.org/2022/03/08-webfonts-minutes.html) since they attended a Fonts WG call.

(Nit: my pronouns are "he" and "his")

The reason I stopped attending is my job function changed. My updated job function was not about text or fonts. (My job function has changed yet again since that time.)

> [Myles] understood that especially for the CJK market which currently has near-zero webfont deployment, patch subset was the only viable solution.

I think this sentence has a few things wrong with it:
1. I do not believe that patch subset is the only viable solution. I believe it often has better performance than range-request, but I do not believe the threshold for viability lies between the two proposals. In the situations that each of the two approaches were designed for, both approaches respectively behave significantly better than the current state of the art.
2. It's logical fallacious to say something is better than the alternatives, so therefore it's good.
3. Even if this sentence _were_ true, it's incorrect to extrapolate a stated standards position from it. Many factors are involved in the production of a standards position, not just performance.

An actual position would be closer to something like:
- Because patch/subset requires a smart server, we don't see _it_ as viable for the web _at large_. We see it as viable for a select set of highly-popular font serving teams/companies. We don't want to see more consolidation in the fonts industry.
- We recognize that patch/subset performs better than all of the (one) alternatives right now, at least in laboratory settings. That doesn't mean we're positive on patch/subset.
- More realistically, what that probably means, gazing into my crystal ball, is that it will be implemented (regardless of anything the TAG or W3C says) by at least some subset of the highly-popular font serving teams/companies, and some subset of browsers, and in order to remain competitive with them, we'll probably be forced to implement it as well, despite our best judgment. (But, again, this is just a prediction of the future; who knows what will actually happen in reality.)
- But, again, even if we do end up implementing it, that doesn't mean we're happy about it, or support the idea. Just because it performs better than the current alternatives doesn't mean it's philosophically a good idea for the web.
- We are excited to see how the new IFTB proposal works in practice (and in the laboratory).
- Perhaps there is a as-of-yet unproposed solution which performs as well or better than patch/subset, but also doesn't have its drawbacks. There is no time like the present to build this technology, but it's also not _urgent_; the world has been living with the current state of the art of font serving for a while. In my experience, it's usually better to ship the _right_ thing, rather than ship the _first_ thing.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/849#issuecomment-1666559805
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/849/1666559805@github.com>