A means to control how long a splash screen should remain on screen.

[marcoscaceres]

An app might want to show its splash screen for a minimum amount of time.

[marcoscaceres]

@kenchris wrote:

I would love a DOM API for hiding it. We use that in Crosswalk.

It would be good to investigate when people are calling this API... there has also been talk of adding a "appready" user fireable event in the past, which could be used with something like this.

}
//keyword 
"splash_screens_bikeshedme": "appready",
// or time-based
"splash_screens_bikeshedme": "1000" 
}

[marcoscaceres]

Of course, there could just be an API too.

[kenchris]

right. Doesnt web components not already have such an event? or is it only Polymer?

I think the timeout is pretty bad. It might mean that people will always wait even if the app is ready and usable - which makes us look worse than native.

On the other hand if we force people to call an event, people will quickly find out to call it :-)

[marcoscaceres]

Well, at the moment, it's specified to hide it after DOMContentLoaded fires. So, question I have for crosswalk is if that's what most developers are using in your ecosystem? Is it possible for you to look at a sample?

[kenchris]

We actually support hiding when DOMContentLoaded but my own experience is that that is often a bit too early (especially when using frameworks like Polymer).

I know that @darktears used it as well, maybe he can comment on his experience. Alexis?

[darktears]

I can second what Kenneth said. I tear down the Splash Screen manually when I know in my application code logic that I have stuff to show in terms of content and that the UI has loaded in some way.

[marcoscaceres]

@darktears, can you provide some more info? Do you call the tear down after onload or DOMContentLoaded?

[darktears]

That's what kenneth said, it was too early for onload or DOMContentLoaded. I felt it would be nice in my case if the UI showed up with partial data already.

[marcoscaceres]

Ok, so it seems like an API might be the way to go here.

[marcoscaceres]

Spoke to @kenchris about this. He proposes just navigator.splashscreen.hide() (similar to Cordova, but exclude the show() method, which doesn't have a strong use case?), which returns a promise. Resolves when splash screen is removed. Later, we can add a dictionary with some options for how to remove the splash screen (i.e., fade it out, etc.).

[allanjuma]

Yeah. dont think the navigator.splashscreen.show() has a strong use-case either. perhaps when unloading a page before the next page load? which could probably be called by the browser as well..

[marcoscaceres]

On Saturday, May 9, 2015, allanjuma notifications@github.com wrote:

Yeah. dont think the navigator.splashscreen.show() has a strong use-case
either. perhaps when unloading a page before the next page load?

More interesting question: should this be exposed in a (SW) worker context?

—
Reply to this email directly or view it on GitHub
#372 (comment).

[allanjuma]

interesting. Would like to see a use case for the (SW) worker and splash screen.. they don't sound like very good friends :)

[mounirlamouri]

I think we don't all have the same vision of what a splashscreen should be used for. IMO, the browser should show a splashscreen up to the point of the first paint so an API to control the splashscreen isn't really needed. After the first paint, the website is able to control what's being rendered.

[marcoscaceres]

I think we don't all have the same vision of what a splashscreen should be used for. IMO, the browser should show a splashscreen up to the point of the first paint so an API to control the splashscreen isn't really needed. After the first paint, the website is able to control what's being rendered.

This seems initially like a good idea (it's actually what's in the spec right now). However, if you look at how splash screens are used, this doesn't really match the requirements developers have (e.g., #372 (comment)). However, there might be room for a compromise position: some may opt for first-paint, while others might want more control. Having the API affords developers control over removing the splashscreen on first paint or when the developer deems the application is ready.

[darktears]

@mounirlamouri : First paint doesn't mean you can control what's being rendered. Take an example : Polymer. You may get the first paint event, then tear down the splashscreen however the UI may be in a broken state because the bindings are not yet evaluated. One could say that I should implement some complicated logic to make sure that I don't show partial state in my UI but then what's the point of the Polymer bindings {{ }} and the declarative syntax when suddendly I need to add a bunch of JS code to create the bindings afterwards. Again this is convenience, I could do the logic myself.

[allanjuma]

@marcoscaceres is right, there should be room for a compromise position.

[FremyCompany]

I've built Windows apps in the past using HTML, and I like how it works there. The splashscreen is shown automatically while your app is loading, which usually takes less than a second.

As soon as your app can paint, it does paint, but there's a built-in fullscreen Splashscreen template/control you can add to your page which has the exact same layout as the splash screen so, if you want, you can use it and hide it while you're actually ready.

In addition, you can display other stuff on top of it like a progress bar and the type of things you're actually waiting for (this is useful for games, for instance).

[marcoscaceres]

Maybe what we really need is a generic way for an app to tell the UA that it's "ready" (i.e., on its own terms).

[allanjuma]

@marcoscaceres 'app telling the UI..' might be a better idea.. There may be certain instances where the start URL is different from the app URL? and in such a scenario, should the app request the UA to start the splash then stop when ready?

[marcoscaceres]

On June 25, 2015 at 12:32:26 AM, allanjuma (notifications@github.com) wrote:

@marcoscaceres 'app telling the UI..' might be a better idea..

Sorry, I don't follow? Can you expand the above a bit with an example. 

There may be certain instances
where the start URL is different from the app URL? and in such a scenario, should the app
request the UA to start the splash then stop when ready?

Depends if the application is "resuming", but I think this is unlikely. It seems more likely that if you are starting up the application, you always go to the start URL (and hence show the splash screen). If you are otherwise resuming, then you just return the the currently open web page. 

[allanjuma]

@marcoscaceres for example, the very first time you visit a website/webservice homepage, you may not go directly to the app, however upon navigating from the homepage to the app, the splashscreen should be activated. (of course this only applies if you are visiting the webapp from webpage on the same domain). eg, the home page at https://bitsoko.co.ke should be able to call the splash screen when navigating to the web app at https://bitsoko.co.ke/app.. (on chrome mobile)

[alxlu]

@marcoscaceres for example, the very first time you visit a website/webservice homepage, you may not go directly to the app, however upon navigating from the homepage to the app, the splashscreen should be activated. (of course this only applies if you are visiting the webapp from webpage on the same domain). eg, the home page at https://bitsoko.co.ke should be able to call the splash screen when navigating to the web app at https://bitsoko.co.ke/app.. (on chrome mobile)

If the start page isn't where the splash screen is activated, wouldn't it be better to just have the developer implement their own splash screen at that point?

[marcoscaceres]

Resolved to leave this to the user agent.