Fonts are loaded when used so font loading won't start until the contents using a particular font are laid out. With an async cycle, this means the first layout pass will use fallback fonts and the second layout pass will use the loaded font resources.
Using generic loop: Reflow ==> layout text ==> Need font? start load ==> render with fallback ==> font resource loads ==> Reflow ==> layout text ==> decode/activate font ==> render with font With the optimization for data URLs: Reflow ==> layout text ==> Need font? decode/activate font ==> render with font This optimization simply eliminates the extra reflow required by spinning the event loop. There's no atomic unit of work that's broken in two in one case and not the other, in each case [decode/activate font] happens as part of text rendering. I completely agree that having different code paths is an annoyance but the flip side is that there's a user-side impact to this optimization, one case will flash fallback content, the other one won't. Pick your poison. > 1) The behavior of Web apps may change when the address of a > resource is changed from http: to data: or vice versa. Changing the > data source shouldn’t fundamentally alter the code flow. What this means in practical terms is that we should *always* show some form of fallback content, then render again with the actual content, simply for consistency. Last time I looked, Webkit caches activated fonts, so the second time the UA loads the same font (e.g. in a different document) it will be shown immediately without fallback content first. So there's already other reasons why behavior is not consistent across document loads. > 2) Stop promoting data: URL synchronicity as green / “success” This I agree with completely, this is merely an optimization, not a "feature". Cheers, John Daggett _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
