Re: Flashiness (was RE: Proposed agenda for this week telcon, March 28th)

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