F2F meeting minutes and follow-up questions

Folks,

Thank you very much for your time and efforts to join us for the face-to-face meeting, and for your contributions that made it a productive and engaging discussion. Many thanks to Dave Crossland who took detailed meeting notes that can be seen at https://docs.google.com/document/d/1RwrIS9Yzd8hrp1wlv_SiEaUI3cpRgSrtjdqV1yzV7Kg/edit?ts=5a04d39b#heading=h.gdbzof3mk1in

As for the rest of this email, TL; DR: We need to come up a very good reason to convince browser vendors to implement native support for font streaming, and define the implementation boundaries that they would agree with.

I'd like to continue our discussion on the future work items, and, to set the stage, I'd like to ask you a question that I've been pondering with since the F2F. I think we are all in general agreement that having browsers provide a native implementation for a feature we tentatively call "font streaming" would be a very desirable development that can solve many existing problems for CJK fonts and beyond (meaning W3C can make folks in Japan and China very happy)! What is not clear though [not to me, at least] is to what extent the native browser support would be required, or [in other words] how much work we can reasonably ask browser vendors to do and how much we can reasonably expect to get. It is not going to be easy to get an agreement on things, so we need to consider various alternatives and have a good story to tell.

I'd like to share my views and solicit for your feedback on the following implementation boundaries:

1)      The maximalist in me would like to see native implementations that offer full support for dynamic font subsetting and augmentation, where server side API is clearly defined so that various web font services can be compliant, and where all the complexities of manipulating with font data (getting an initial subset, getting an augmentation data and merging the pieces together in a usable font) are done natively. This would offer the best user experience with minimal overhead. The functionality in question is already supported today to various extent in various JS implementations, so feasibility of doing so isn't a concern IMO - the implementation complexity and willingness of browser vendors to put this much effort into it is.

2)      The minimalist native support (for the sake of defining possible boundaries) could simply be avoiding the duplication of efforts. Most of existing JS implementations need to do things that browsers already do today - analyze DOM structure, inspect content, determine what fonts / character subsets are needed, etc. Hypothetically, we could keep things simple and only ask browsers to expose this info and have the rest implemented as a unified [and somewhat simplified] JS library with clearly defined API (similar to what we discussed at our F2F a year ago).

The reality of what the future native browser support for font streaming can do is likely to be somewhere in between these extremes, although with the current emphasis on the importance of internationalization work in W3C, having the right story, and with proper positioning of font streaming implementation and well-defined, justifiable boundaries - I am optimistic that the maximalist implementation could be a possibility. My question for you is two-fold:

-          Please share your opinions on the above, and

-          What do you think would be a convincing, pragmatic, and defensible "really_good_reason(s)" for browser vendors to agree to offer native support for font streaming?

Thank you,
Vlad