It'd be interesting to discuss markup discoverability

[yoavweiss]

In order to properly download incremental fonts, the browser needs to know a few things:

• Is this font large enough to justify the performance tradeoffs, especially if we're to fall back to range requests?
• What would be the characters used in the document that should be requested? Ideally that would be something the browser knows before the entire HTML is parsed.
• How large is the font table for this particular font file? (if we're using range requests)

There may be more questions. It'd be good to think of ways we can provide the browser with answers, either in markup, based on heuristics or otherwise.

[garretrieger]

Deciding whether or not to use incxfer is going to depend on many factors, some beyond just the characteristics of the font. Such as what content is expected to be encountered on the current and/or future page views. So I think the decision to use/not use incxfer would be best made by the content author who can analyze the full circumstances decide whether to opt-in or not for incremental loading on each font file.

Once incremental transfer has been opted into the browser could use some heurestics (and probably should) to try and maximize performance. For example by requesting additional characters that are likely to be needed in order to reduce the need for additional requests.

• What would be the characters used in the document that should be requested? Ideally that would be something the browser knows before the entire HTML is parsed.

Not sure if this is what you meant, but in patch subset the first response from a server includes a complete list of codepoints supported by the font. The client can use that to avoid making requests for characters the font does not support. Likewise for range request the client will load the font's cmap table on the first request which allows it to know what codepoints are supported. This actually turned out to be a pretty important optimization in the simulations we ran. Additionally the content author can provide additional guidance to the browser by adding "unicode-range: ..." to the font face which will help avoid the first requests where the font contains no relevant characters.

[yoavweiss]

Deciding whether or not to use incxfer is going to depend on many factors, some beyond just the characteristics of the font. Such as what content is expected to be encountered on the current and/or future page views. So I think the decision to use/not use incxfer would be best made by the content author who can analyze the full circumstances decide whether to opt-in or not for incremental loading on each font file.

Agreed.

But once an author has opted in, we ideally want the browser to make a single, early and as-complete-as-possible request for the glyphs and shapes that it needs for the initial render. The information to enable sending such a request won't be available to the browser until rather late in the game (after HTML parsing & layout). So some heuristics are in order to automatically make that process faster, but maybe we want/need to enable authors and tools to provide hints that would help the browser make the right call.

Not sure if this is what you meant, but in patch subset the first response from a server includes a complete list of codepoints supported by the font.

That's useful for followup requests (e.g. for parts of the font that are needed for out-of-viewport content), but doesn't help the initial request. I was thinking more along the lines of markup annotations (e.g. preload attribute, etc).