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

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.

Jason



> On Mar 28, 2019, at 10:54 AM, Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com> wrote:
> 
> See below.
>  
> From: mmaxfield@apple.com <mailto:mmaxfield@apple.com> <mmaxfield@apple.com <mailto:mmaxfield@apple.com>> 
> Sent: Wednesday, March 27, 2019 7:04 PM
> To: Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com <mailto:Vladimir.Levantovsky@monotype.com>>
> Cc: w3c-webfonts-wg (public-webfonts-wg@w3.org <mailto:public-webfonts-wg@w3.org>) <public-webfonts-wg@w3.org <mailto:public-webfonts-wg@w3.org>>
> Subject: Re: Proposed agenda for this week telcon, March 28th
>  
> I don’t know if we’ll have time, but I’d like to have a discussion about flashiness.
>  
> I think we’ve all settled on a design where, during initial page load, some subset of a font is downloaded from a server. Then, as the page content changes, there would be subsequent downloads from the server, and somehow a way of joining the new response with the old response. What should browsers show during the second download?
>  
> One option is the way unicode-range behaves, where a random half of the characters scattered throughout the newly-added text are rendered, and the remaining ones are invisible. I have accidentally caused behavior like this in WebKit before (in English content), and we heard howls from users about it.
> Another option is for the browser to somehow separate the “new text” from the “old text” and render none of the “new text” but keep rendering all of the “old text”. Keeping these two sets distinct is perhaps unimplementable, especially in the presence of things like React that have “virtual DOMs” and automatic diffing
> Guarantee that, for every alphabetic language/script, the entire alphabet always be transferred together. This wouldn’t help the scripts that need progressive enhancement the most, may not work with combining marks even in alphabetic scripts.
> Maybe someone smarter than me can come up with something better?
> I just ran a simple experiment where I posted some nonsense on my FB page (using Chrome running on Windows PC) in English, and then commented on my own post in Russian using iPhone FB app. Post content with the new comment added got updated in Chrome within a fraction of a second, let’s say ½ a second of noticeable delay. However the delay is only noticeable to the OP of the comment, nobody else would ever know when the comment was added and when the content is updated with the new text … which brings me to yet another scenario to consider:
> Delay content updates (as in “show nothing new at all”) until all necessary incremental font updates are completed.
> Reasoning: This particular behavior is known to have caused [sometimes significant] delays in page load, and have contributed to really bad user experience in certain cases (when users would walk away from the page because nothing was happening for few long seconds). However, unlike the first page load where a user clicks on a URL and is waiting for something to happen (therefore, having an exact time reference of the URL click as trigger event, and enduring the burden of latency and delays in page load), the incremental content updates are completely asynchronous to the vast majority of viewers – content of the page may have been updated 5 seconds ago but if one only sees it at this particular moment of time, the update still seems instantaneous to everyone else other than OP.
> An interesting side-effect that we may need to consider (using the same example I described earlier) is what to do when an OP starts typing a comment using downloaded font that doesn’t have a particular character set, like in my case I started typing using Cyrillic characters that wouldn’t be part of the currently loaded subset, and until I finish typing, the exact content of my comment (which would inform an incremental font enrichment request) is unknown – should we simply allow a switch to fallback font to happen for content edits?
>  
> Thanks,
> Vlad
>  
>  
> Thanks,
> Myles