That also sounds interesting! My goal is to have the characters visible on the first render, whereas that sounds like the glyphs would be invisible – albeit accurately sized, and therefore preventing layout shifts. Correct me if I'm wrong :)
Separate metrics files have already been done too (both with TeX in TFM files and Adobe/PostScript fonts in AFM/PFM files), so you wouldn't even have to invent a new file format.
Or you could simply use a regular font with no glyph curve data.
I am a bit disappointed this is not covered in the original post, and that no effort is being put in W3C to make that easy and viable.
> I am a bit disappointed this is not covered in the original post, and that no effort is being put in W3C to make that easy and viable.
Yes. What would be interesting is if you could use an a-priori available font (system font), and combine it with a website-provided font metrics file. That way, you can render visible text immediately, and then later render the correct font without layout change.
Yeah, but strictly as a solution to shifting layout, having metrics asap and actual text display later — when the glyph data is downloaded — is the most obvious solution.
Rendering a similar system font (by metrics comparison, ideally) in its place is indeed a great improvement on this, but mostly for the render-as-soon-as-possible problem.
I'd treat it as a separate problem simply because it can be on the user agent to decide to do it and how, and even without it, a bunch of web apps would start benefitting right away (those which have most of their actual text off screen but which might block rendering other parts of the page).
