Re: [w3c/manifest] Richer splash screen backgrounds (#589)

@piotrswigon, I see the problem. But, is this really an issue for the specification of the manifest?

I think the splash_url is a very elegant solution, and it would be a pity to drop it only because it's hard to implement.

The obstacle you see has a broader scope than the splash screen. It would affect any JS animations. Or any other changes to the page not initiated by the user, for example a refresh meta tag. A user on a low end device would be used to animations not working properly. It would be a good thing to improve this, but it's more a question of JS animations on low end devices.

A half-rendered stored splash screen image would be updated (repaired) on the next app load. Of course, only if the device is able to render it in time. If not, the user will see no difference compared to a non cached splash image.

As I understand it there is a race condition. The splash URL has to be loaded, any JS finished and rendering complete. When to do the snapshot? The logical place would be when the content loaded from site_url starts rendering. However there is no guarantee that the rendering of the splash_url is done. An ugly fix would be to add a heuristically determined wait (X CPU cycles). Since we're talking about a low end device - the user is accustomed to a sluggish response. Once there is support for JS animations, this workaround can be removed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/589#issuecomment-361934800