- From: Roderick Sheeter <rsheeter@google.com>
- Date: Thu, 28 Mar 2019 20:58:25 -0700
- To: Jonathan Kew <jfkthame@gmail.com>
- Cc: public-webfonts-wg@w3.org
- Message-ID: <CABscrrE_z2HM+hCuDoNjK-GhgXCcWftCwx0eWNaLskQYPPA+3w@mail.gmail.com>
These problems exist today. unicode-range can be viewed as approximating incremental transfer, particularly with numerous slices, such as how Google Fonts handles CJK. The existing solutions should all continue to work with incremental transfer (possibly worth a informational note in our nascent spec): 1) font-display permits control over the fout, repaints, whether to redraw in a late-arriving font,etc. I believe this came up in the call I missed. 2) CSS Font Loading (such an odd name for a js api) permits you to demand specific characters via load(font,text). https://drafts.csswg.org/css-font-loading/#font-face-set-load. Today in a unicode-range scenario you can use it to demand early load of parts of the font. This tactic should continue to work with progressive enrichment. Thinking "aloud", it might be nice for the text param for font loading to support some sort of range syntax, today you'd have to pass a rather long string in some scenarios. That might be worth filing a ticket with CSS about; doesn't have to influence our spec I don't think. On Thu, Mar 28, 2019 at 9:07 AM Jonathan Kew <jfkthame@gmail.com> wrote: > On 28/03/2019 15:51, Jason Pamental wrote: > > I was wondering if part of the answer might be to simply render new > > content (i.e. a comment that has posted) in fallback font until new font > > download is complete. But I’m not entirely sure if that would trigger > > multiple repaints, which could be a bad experience. > > > > Yes, it would be liable to multiple repaints. > > And it would also be liable to "ransom-note" effects, particularly in > the case where content is edited rather than an entirely new, separate > block being added. E.g. imagine a user-editable comment field that uses > such a webfont. The user writes an ASCII-only comment, and the browser > downloads an ASCII subset of the font. > > Then the user edits their comment, inserting an accented letter (e.g. > they fix the spelling of someone's title from "Senor" to "Señor"). The > accented character wasn't present in the initial font subset, so a new > request is made; but in the meantime, it gets rendered using a fallback > for the ñ, which might look a bit ugly. Then, once the new subset has > been downloaded and added to the resource, the content gets repainted > using the proper font. > > JK > >
Received on Friday, 29 March 2019 03:59:00 UTC