Manifest format should support some way of including a splash screen #9

Closed
marcoscaceres opened this Issue Apr 22, 2013 · 103 comments

Projects

None yet
@marcoscaceres
Member

This feature is at risk. Unless we hear otherwise, this feature will be removed from the specification in the next few months.

Why is this at risk?

In the past, various vendors had expressed an interest in having a splash screen for when an app boots up. However, at least one implementer claims that it's possible to achieve this effect by using background_color + icon members. Additionally, browsers engines are able to boot up in sub 200ms, making it possible for authors to create their own splash screen experiences without needing to rely on this.

Use case

Because of the limited processing capabilities of some devices and the amount of time it takes to initialize a Web runtime, there can be a small - yet noticeably perceivable - delay between when the end-user starts an application and the application actually becoming available and interactive to the end-user.

Depending on the complexity of the application and the processing power of the device, this delay can range from a few milliseconds to a couple of seconds. When applications take more than a few seconds to load, it can be disorienting to end-users as nothing is displayed on the screen; leading to a poor user experience. Native applications overcome this issue by allowing developers to use a media file that is displayed the instant the application is launched. Such a file is commonly referred to as a "splash screen" or "launch image".

@mounirlamouri
Member

CC people involved in the previous issue: @nhoizey @julienw

@mounirlamouri
Member

I've been trying to think about that last week and I feel that there are a lot of use cases here. Most people will ask to be able to tweak there splash screen as much as possible but there is a sure thing: we don't want to put HTML and CSS in the manifest. Using a HTML page (linked) wouldn't be efficient.

Also, we have to define what the splash screen is for: it is for the moment between the user tried to start the application and the application is actually started. It can be a second or less when the application is cached. It can be a few seconds if the application has to be loaded from the network.
In both cases, as soon as the application is loaded we should show the index of the application and the splash screen should be hidden. The feature isn't there to replace the splash screens show by games when they load data for example.
The problem with having different magnitude of time between some types of application startups and some others is that some elaborated splash screens might be shown only for a few milliseconds giving a terrible user experience. When we expect the application to get loaded very quickly no splash screen or a plain colour is probably the best thing to do.

As soon as we agree that we can't customize the splash screen in detail, I think we can narrow down the splash screens in two categories:

  • an icon shown in the middle of the screen with a background;
  • a huge background image.

For the former, we could easily take the best sized icon from the manifest and show it on top of a predefined background colour. It could be based on the icon colours or on the system theme. We could also ask the application developer to define it.
For the later, we should just ask for a background image knowing that it is very hard to get it right because of the different size of screens. The UA will then have to play with resizes and maybe cropping.

I think this is a feature we should keep as UA specific behaviour for the moment. UA could simply do the first proposition: show an app icon on some kind of background if they believe this is a good idea. I believe that this is a good enough solution for the moment and that we might learn more later. The main concern I have is that with performance improving and offline hopefuly getting fixed on the web, we might end up no needing splash screen soon enough and if we need them, we might have a better understanding of what are the use cases.

@nhoizey
nhoizey commented Apr 23, 2013

I've had time to think about it since our discussion on sysapps/sysapps#41 and I agree with @mounirlamouri that we need something simple enough to fit most needs.

I'm not comfortable with "the UA [having] to play with resizes and maybe cropping". So, isn't "an icon show in the middle of the screen with a background" just "a huge background image" that is not huge enough to fill the screen? ;-)

As I said in our previous discussion, I'm not comfortable either with the UA chosing a solid background color alone, "based on the icon colours or on the system theme".

As a webapp developer, I would then like to have this:

  • If I set nothing, the "best sized icon from the manifest" on a background set by the system theme (may be a gradient instead of a solid color)
  • I can set my own list of splash icons, from which the "best sized" is chosen by the UA
  • I can set a solid color for the background

My understanding is that "best sized" means something like "the biggest that fits into 90% or the width and height of the viewport", to give it some padding…

@marcoscaceres
Member

@nhoizey, what concerns do you have about the UA proportionally resizing the splash screen?

I agree that the user should get to specify the BG color for the start up.

(adding this here as we can probably reuse some of the text: https://dvcs.w3.org/hg/nativeapps/raw-file/tip/splashscreen/Overview.src.html)

@nhoizey
nhoizey commented Apr 29, 2013

@marcoscaceres I have more concerns with "cropping" than with "resize", actually… ;-)

@marcoscaceres
Member

I agree. Cropping would be bad.

The RICG looked quite a bit into resizing by browsers and found the
algorithms to be good from a design/aesthetic POV. Unfortunately, I don't
have a reference; but the were many blog posts about it.

@marcoscaceres
Member

We've (@mounirlamouri and I) done a whole bunch of investigation into this over the last month or so, and from Mozilla's point of view, we don't need splash screens. There is too much variance in what developers need and using HTML is perfectly well suited to this task: you can adapt it to layout, you can animate it, it's accessible, etc.

The challenge for both developers and browser vendors is to have the runtime pop up quickly enough to be able to render a HTML page (in around 100ms - FireFox OS is able to do this, FWIW).

@marcoscaceres
Member

Closing this bug. If anyone disagrees, please reopen for further discussion.

@laurentperez

Hi

I'd like to reopen the discussion on this. We are an UA vendor : our HTTP proxy translates custom data-* attributes into web UI components.

Currently there are at least 3 different implementations of a splash screen :

It is unclear for us if we go the widget splash way (see https://dvcs.w3.org/hg/nativeapps/raw-file/tip/splashscreen/Overview.html) or manifest way.

I understand the spash is doable in pure web without UA assistance. Apple is using their own standard, but we like true standards. Not every developer has the JS skills to wait for the readiness of their content and hide a custom splash element, quickly shown before everything else.

What do you think ?

@marcoscaceres marcoscaceres reopened this Aug 11, 2013
@marcoscaceres
Member

(I'm reopening so this doesn't get lost - but I'm away on vacation till next month)

@mounirlamouri
Member

A library/framework could work very well. Not speaking about the fact that a splash screen is actually pretty easy to implement.

@laurentperez

On Firefox Beta 24, on Android, if you have in your manifest : "icons": {"128": "icon.png"}

Then when you first run the app, you'll get a zooming animation of the icon on an orange/yellow background, with a spinning loader at the bottom. So there's some sort of splash mechanism, but you won't get this on the latest Firefox OS simulator.

If I want to override the zoom, change the background or use a progress bar instead of a spinner, I can't. Phonegap exposes navigator.splashscreen.show() and hide() (see http://simonmacdonald.blogspot.fr/2012/04/phonegap-android-splashscreen-just-got.html).

If I could use {splashscreen: "splash.html" } in the manifest and dismiss it like Phonegap does, it would be nice. I agree HTML is well suited for this, I could use media queries in the splash.html page to display a retina friendly image, use another one in landscape, etc.

On a side note, Tizen uses the widget spec (https://developer.tizen.org/downloads/sample-web-applications/load-web-app-tizen-sdk/sample-config.xml-file), but unlike Blackberry with a rim:splash extension, does not support splashscreens yet : https://developer.tizen.org/forums/web-application-development/splash-screen

@marcoscaceres marcoscaceres referenced this issue in w3c-webmob/installable-webapps Dec 18, 2013
Open

Investigate splash screens #36

@marcoscaceres
Member

Will try to investigate what we would need as part of w3c-webmob/installable-webapps#36 in 2014. However, I'm inclined to defer splash screens to future versions of the spec.

Would anyone object to that?

@anssiko
Collaborator
anssiko commented Jan 2, 2014

@marcoscaceres We are experimenting with a proposal with @kenchris, should be able to share it with the group soon. Perhaps we can keep the proposal in its own branch as an experimental feature, and after we have implementation experience consider merging it to future versions of the spec?

@kenchris
Collaborator
kenchris commented Jan 2, 2014

@anssiko I think that is a good idea. Let's finish up our proposal.

@marcoscaceres
Member

ok, closing this and we can reopen for v2

@marcoscaceres marcoscaceres reopened this Feb 25, 2014
@mounirlamouri mounirlamouri added the V2 label Apr 7, 2014
@anssiko
Collaborator
anssiko commented Jun 27, 2014

We've shipped an experimental implementation of the "launch screen" feature in Crosswalk:

https://crosswalk-project.org/#documentation/manifest/launch_screen

We'll now gather feedback from web developers, and evaluate how the feature is used in real-life to help us refine the proposal. And if there's developer pull and interest among other implementers, we can then think about the standards track.

@marcoscaceres
Member

Thanks @anssiko! Looking forward to getting your feedback.

@marcoscaceres marcoscaceres modified the milestone: Future version, Level 2 Nov 5, 2014
@marcoscaceres marcoscaceres added v3 and removed V2 labels Nov 5, 2014
@marcoscaceres
Member

Moved to V3

@marcoscaceres
Member

@anssiko do you have any feedback on the splashscreen usage since you guys shipped?

@anssiko
Collaborator
anssiko commented Nov 7, 2014

@marcoscaceres I'm not aware of any significant feedback that would motivate us raising the priority. I suggest we keep this in the V3 / future work bucket.

Optimally, SW improves the startup experience enough (beyond the first start when the cache is primed), so that this would not be needed at all.

@marcoscaceres
Member

I'm inclined to close this. We can revive again in the future once we see how the manifest gets used in the wild.

@anssiko
Collaborator
anssiko commented Nov 11, 2014

WFM. Thanks for triaging the issues.

@marcoscaceres marcoscaceres reopened this Mar 6, 2015
@marcoscaceres
Member

There is some renewed interest in this coming from potential implementers.

@anssiko
Collaborator
anssiko commented Mar 6, 2015

I'll check whether there has been more recent feedback on the launch screen feature in Crosswalk.

@anssiko
Collaborator
anssiko commented Mar 6, 2015

Quick poll result: most of our users seem to be using the Cordova splash screen plugin:
https://github.com/apache/cordova-plugin-splashscreen/blob/master/doc/index.md

@kenchris
Collaborator
kenchris commented Mar 6, 2015

Which is due to most of our users using Crosswalk with Cordova integration and in that scenario that is the only thing they can use :-)

@marcoscaceres
Member

On March 6, 2015 at 8:28:59 PM, Kenneth Rohde Christiansen (notifications@github.com) wrote:

Which is due to most of our users using Crosswalk with Cordova integration and in that
scenario that is the only thing they can use :-)

We can probably learn a lot from Cordova, like adding the minimum duration before removing the splash screen.  

@mounirlamouri
Member

How are Crosswalk applications handling the different screen sizes?

@anssiko
Collaborator
anssiko commented Mar 9, 2015

@mounirlamouri For the background image, we're using the 9-patch image method. Android uses something similar for stretchable bitmaps, see http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch

@marcoscaceres
Member

Ok, there are two solutions here I can think of... 

  1. we support patch images, as per Android: from playing around, it appears that patch images are just PNGs with a 1px transparent border around the image. In that border, black pixel lines indicate what the stretchable areas are (you can have patterns like: __  _ __ ____ __). Android uses a .9.png file extension as the way to tell the OS that this is a 9-patch. 

So, in the manifest, we would also provide a member to say that it's a nine-patch image: 

{
   splash: [{"src": "foo.png", "BikeShedMyName": "patch"}]
}

When patch markers are missing, we just use, say, 30 by 30px (or some sensible default).

BikeShedMyName could be "align" or "display" or something. 

  1. we support CSS border-image syntax. This seems overly complicated tho, because values relate to the rest of a stylesheet, so it's probably not even possible to support 2.  

So, my vote is just do 1: it's simple and straight forward :)

On March 9, 2015 at 7:05:11 AM, Anssi Kostiainen (notifications@github.com) wrote:

@mounirlamouri For the background image, we're using the 9-patch image method. Android
uses something similar for stretchable bitmaps, see http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch


Reply to this email directly or view it on GitHub:
#9 (comment)

@kenchris
Collaborator
kenchris commented Mar 9, 2015

You don't really need to hardcode the patching in the image files, it could very well be specified in markup

@kenchris
Collaborator
kenchris commented Mar 9, 2015

How does 1 allow you to define how to scale the patch areas? like stretch, repeat etc? It probably also won't work with any lossy format like jpeg

@marcoscaceres
Member

Markup? you mean like option 2? But then we would be recreating what CSS does :(  

On March 9, 2015 at 8:40:50 AM, Kenneth Rohde Christiansen (notifications@github.com) wrote:

You don't really need to hardcode the patching in the image files, it could very well be
specified in markup


Reply to this email directly or view it on GitHub:
#9 (comment)

@marcoscaceres
Member

On March 9, 2015 at 8:43:27 AM, Kenneth Rohde Christiansen (notifications@github.com) wrote:

How does 1 allow you to define how to scale the patch areas? like stretch, repeat etc? It
probably also won't work with any lossy format like jpeg

Yes, this is true. It's a pretty cheap solution restricted to .png (and maybe .webp), probably doesn't work with vectors either. 

@kenchris
Collaborator
kenchris commented Mar 9, 2015

Would it be too bad? like

"image.png 30px stretch 30px stretch 20px repeat 20px repeat"

I guess the image would work, but it would then only work with non-lossy formats like PNG (WEBP?)

@anssiko
Collaborator
anssiko commented Mar 9, 2015

I would prefer not to reinvent CSS for launch screen, nor put CSS in JSON. Vote for option 1 to address the most common use case first, make it dead simple, while ensure it is extensible to allow experimentation and future extensions.

We could just recommend people to use a lossless format. That should be obvious for most web developers anyway.

I could see how we might get bonus points if developers would be able to use their existing 9-patch image assets. If there's a de facto format for it, then we should embrace it assuming no obvious issues or concerns with it.

@marcoscaceres
Member

On March 9, 2015 at 8:48:12 AM, Kenneth Rohde Christiansen (notifications@github.com) wrote:

Would it be too bad? like

"image.png 30px stretch 30px stretch 20px repeat 20px repeat"

Personally, I think it's better just to encode this information directly in the image file. 

However, the above would be simple to parse so long as we don't combine URL and stretching information together.

I guess the image would work, but it would then only work with non-lossy formats like PNG
(WEBP?)

Yeah, that's the tradeoff. However, we would get all those 9-patch images already being used on Android for free. 

Maybe there is a third option of adding "auto" to the patch parser above.
 

@kenchris
Collaborator
kenchris commented Mar 9, 2015

@anssiko you need to be able to rely on the drawn lines :-) lossy formats will not make that possible

@anssiko
Collaborator
anssiko commented Mar 9, 2015

I guess we'd be fine mandating the use of PNG since it AFAIK addresses all the known requirements, has a spec blessed by ISO/IEC and W3C, and is the format used by the native platforms for the same purpose.

@nuxodin
nuxodin commented Mar 9, 2015

What about putting a html-document as the splash-screen url?

splash: "splash.html"

And maybe, the implementor will cache this document as a static image?
But, hm, this will make animated gifs impossible...

2015-03-09 14:09 GMT+01:00 Anssi Kostiainen notifications@github.com:

I guess we'd be fine mandating the use of PNG since it AFAIK addresses all
the known requirements, has a spec blessed by ISO/IEC and W3C, and is the
format used by the native platforms for the same purpose.


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

Freundliche Grüsse
Tobias Buschor

shwups GmbH
Talstrasse 1
9000 St. Gallen

+41 76 321 23 21
shwups.ch

@anssiko
Collaborator
anssiko commented Mar 9, 2015

@nuxodin You mean, create the 9-patch image from a snapshot of the HTML page? Or just create a fixed sized splash screen in landscape and portrait? That would not work e.g. on desktop where the window can be resized while the launch screen is being displayed. Also, you may have multiple monitors of different resolutions or aspect ratios.

There are some implementability concerns with using an HTML document. For example, what if some of the resources needed to render splash.html do not load or load too slowly, or you get 404? Should we check the splash.html for updates, if so, how often?

Someone might also abuse this, for example, display an ad once in a while instead of your usual splash screen.

What is the use case, what extra flexibility do you need that is not provided by the static 9-piece image?

@marcoscaceres
Member

There are some implementability concerns with using an HTML document. For example, what if some of the resources needed to render splash.html do not load or load too slowly, or you get 404? Should we check the splash.html for updates, if so, how often?

@nuxodin : Yes, this is basically the whole point: on some OSs, booting up the webview is just too slow. Otherwise, you would not need the splashscreen at all. The index.html would serve just fine (e.g., on FxOS, we don't need splash screens because we can get a webview up in 200ms). This is why we originally rejected adding splash screens to this spec. Maybe Moore's law will allows us to overcome this limitation in the future.

@marcoscaceres marcoscaceres removed this from the Future version milestone Mar 9, 2015
@marcoscaceres marcoscaceres added P2 and removed P3 labels Mar 9, 2015
@nuxodin
nuxodin commented Mar 9, 2015

Or just create a fixed sized splash screen in landscape and portrait?

Yes, snapshot of it.

That would not work e.g. on desktop where the window can be resized while
the launch screen is being displayed. Also, you may have multiple monitors
of different resolutions or aspect ratios.

On desktop, it should be ok loading the cached splash-screen-html without
making a snapshot. But i see the problem...

Should we check the splash.html for updates, if so, how often?

On installing the web-app and on changing the last-modified of the manifest
(or the version?)

What is the use case, what extra flexibility do you need that is not
provided by the static 9-piece image?

HTML / CSS is well known by all webdevelopers, the 9-piece image is new
mechanism developers have to learn.

2015-03-09 16:31 GMT+01:00 Marcos Caceres notifications@github.com:

There are some implementability concerns with using an HTML document. For
example, what if some of the resources needed to render splash.html do not
load or load too slowly, or you get 404? Should we check the splash.html
for updates, if so, how often?

@nuxodin https://github.com/nuxodin : Yes, this is basically the whole
point: on some OSs, booting up the webview is just too slow. Otherwise, you
would not need the splashscreen at all. The index.html would serve just
fine (e.g., on FxOS, we don't need splash screens because we can get a
webview up in 200ms). This is why we originally rejected adding splash
screens to this spec. Maybe Moore's law will allows us to overcome this
limitation in the future.


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

Freundliche Grüsse
Tobias Buschor

shwups GmbH
Talstrasse 1
9000 St. Gallen

+41 76 321 23 21
shwups.ch

@slightlyoff

Starting up a renderer process in all chromium-derived runtimes can require multiple process starts. We need to paint faster than that. We must allow an image. If a URL, it should be a URL that could be run once on the device, snapshotted, and re-rastered at next start without renderer startup.

@marcoscaceres
Member

HTML / CSS is well known by all webdevelopers, the 9-piece image is new
mechanism developers have to learn.

That's not true. CSS border-image has been around for many years, tho it never found much use. Also, it's not like it's a huge burden to learn, plus there are a lot of tools that easily allow you to make 9-patch images (both on the web and offline - including any off the shelf graphics program). The benefit is also that we don't need to introduce any new image format.

@mounirlamouri
Member

A feel that we are going in circles with this discussion.

  • We can't use a plain image because it would require cropping or image magics that we can't really rely on browsers to do;
  • Opening an HTML page would fire up new processes which will make the splash screen slowing down the application startup;
  • Making a snapshot of an HTML page will require static page but developers want to do progress bars and stuff - also, it come with the problem of the snapshot happening at the "wrong time";
  • Other solutions a freaking complex (9 images?!).

Can we instead expect UA to build a splash screen from the information already in the Manifest? The icons, theme_color, name or even short_name sound like good information to build a splash screen.

We could add in the Manifest a hint to ask the browser to show a splashscreen (though, I'm not entirely convinced) but then, I wonder, when do the splashscreen hides? The load event is late and unreliable. Other events like DOMContentLoaded might be too early. What does Cordova or Firefox OS do?

@skddc
Contributor
skddc commented Mar 18, 2015

What does Cordova or Firefox OS do?

Firefox OWAs on Android use the supplied icon and extract the main color from it to use as background color I believe.

With Cordova you have to provide a defined set of image sizes: http://cordova.apache.org/docs/en/4.0.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens

@benfrancis

Firefox OWAs on Android use the supplied icon and extract the main color from it to use as background color I believe.

Firefox OS does the same, centre aligns the app icon. We could use theme-color for the background colour instead now that exists.

@kenchris
Collaborator

I actually think it is quite simple.

Provide an image. By default center it and use theme_color or similar for background color. If the image is a 9 piece image (like used by PhoneGap and natively supported by Android) we scale it according to the splits and fill the screen. There is not talk about 9 separate images here :-) just one single one with 4 cuts... two horizontally and two vertically.

@kenchris
Collaborator

You have an event to call when you want the splash screen to be hidden. It is your responsibility to call it. A timeout could be used, but it kind of defeats the purpose

@skddc
Contributor
skddc commented Mar 18, 2015

That would work I think.

From our daily experience I should also add that the automatically generated ones can be a bit ugly, but we'd also not like to use the theme color for this in our apps usually, because it's too bright as background for the splash screen.

@kenchris
Collaborator

I guess that the user agent could decide what to use for background color, like you could use the theme_color and make it 20% darker, like Android does something like that for the status bar background color. We can make suggestions but leave it open for UAs to decide

@marcoscaceres
Member

...resuming work on this...

@mounirlamouri
Member

/cc @PaulKinlan @jakearchibald

I wrote a proof of concept for this using what would be a theme_color with an icon from the Manifest. I'm fairly happy about using the icon. However, I am a bit concerned about the theme_color. It might be very close but not quite exactly the icon's background colour. Also, the theme_color might not be the best solution for a smooth transition. For exmaple, GMail would have a red theme colour with a mostly white content after. They might prefer to have a white-ish loading screen.

Which makes me realise that we could generalise that to help prevent the usual white screen, outside of a splash screen context. For example, if loading an offline-first application would take a couple of hundred milliseconds, a user might still be annoyed by a flash of white. However, if the colour is closed to the page's background, it might be less annoying.

What would you think of introducing something like a background_color property?

@kenchris
Collaborator
kenchris commented Apr 8, 2015

If you did use a 9 piece image (which is just one image btw) then you could define any background color in that. Also it is natively supported on Android.

@jakearchibald

I thought 9-slice images were the answer, but they don't solve a whole lot of cases. Eg

  • Icon against a diagonally stripped background
  • Anything with text is going to look platform-alien
  • Anything that tries to match something like first real render is going to have sizing issues
@kenchris
Collaborator
kenchris commented Apr 8, 2015
  • 9 piece images can be transparent as well
  • If a non-9 piece image is used, we can just center the image
  • iOS as an example, strongly discourages the use of text on any splash screen
@jakearchibald

I agree with @mounirlamouri, it's a quick win.

Is still like a way to generate splashscreen bitmaps on the client, but I realise that's way more complicated. Take https://jakearchibald.github.io/svgomg/, I'd like to be able to create a splash screen that was identical to first render, or maybe without the text.

@mounirlamouri mounirlamouri reopened this May 24, 2015
@mounirlamouri
Member

I'm not a big fan on how that was solved. I don't think I would implement the specification as-is unfortunately.

The background-color fields in image is interesting but I'm not sure that's what we want here. Maybe we should have background-color on splashscreen? The idea was really about knowing the background colour of the content that would be printed after the generated splash screen.

@slightlyoff

I'd like to keep this from being too specific to one timing or another. A
generalized background color is good. A more specific one for each use-case
might also be good, but I'd like to not get hung up on it.

On Sun, May 24, 2015 at 7:19 AM, Mounir Lamouri notifications@github.com
wrote:

I'm not a big fan on how that was solved. I don't think I would implement
the specification as-is unfortunately.

The background-color fields in image is interesting but I'm not sure
that's what we want here. Maybe we should have background-color on
splashscreen? The idea was really about knowing the background colour of
the content that would be printed after the generated splash screen.


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

@marcoscaceres
Member

Maybe we should have background-color on splashscreen?

That's what is currently specified?

The idea was really about knowing the background colour of the content that would be printed after the generated splash screen.

Maybe you can list some apps I can look at to see what you mean. This is not what I'm seeing in the sample of apps I've been testing on iOS.

@marcoscaceres
Member

Here is a wall of splash screens. The images on the left are the splash screen, the ones on the right are the application screens shown after the splash screen goes away.

screenshot 2015-05-25 13 59 10

@marcoscaceres
Member

From the above, we can discuss different use cases and requirements.

@marcoscaceres
Member

The background-color fields in image is interesting but I'm not sure that's what we want here. Maybe we should have background-color on splashscreen? The idea was really about knowing the background colour of the content that would be printed after the generated splash screen.

I need the background color for both the splash screen and for the icons. However, I think I made a mistake having background_color be on the image object. It makes processing non-trivial for me in the gecko implementation. For tiles, this is what I'm doing to determine what image to use:

  1. Create an HTML image element in Gecko's parent process.
  2. convert the list images from icons to string of "srcset"s .
  3. set image.srcset = converted list of icons.

In the above, I lose the background color :( That is, I know which img.currentSrc is used, but I can't then go back reliably to find which background color was associated with an image object (there could be two sources that use the same background-color).

Would anyone object to removing background color from image object and moving it to it's own members:

"icons_background_color": "papayawhip",
"splashcreen_background_color": "blue" 

PS: I hate JSON. It's an inflexible pile of crap.

@mounirlamouri
Member

I would prefer to have background_color on the icon object instead of outside. It gives information that can be interesting to the UA. For example, which icon is fit for a dark background and which for a lighter one.

This said, none of the presented solutions (splashcreen_background_color or icons.background_color) currently match what I had in mind. I don't think it's fair to take iOS examples and say that a splashscreen implement should follow what is being done their. iOS has its own UI rules which doesn't match other platform. For example, Android does not recommend having splashscreens so you will obviously find very little apps with splashscreen.

I will ping some folks about that and come back to you.

@marcoscaceres
Member

I would prefer to have background_color on the icon object instead of outside. It gives information that can be interesting to the UA. For example, which icon is fit for a dark background and which for a lighter one.

That's kinda interesting, but I'd like to see where something like that is done in practice? Is that something that Android supports?

I don't think it's fair to take iOS examples and say that a splashscreen implement should follow what is being done their.

I think it's the same on Android, but I will check tomorrow.

iOS has its own UI rules which doesn't match other platform. For example, Android does not recommend having splashscreens so you will obviously find very little apps with splashscreen.

Yes, @pornel pointed this out in #361. We need to start thinking about how to address that. We've already started doing platform specific stuff with the related_apps thing, so feels like the time is right to start giving that some more serious thought.

Didn't know that Android didn't recommend them. I'll still be interested to see if devs. are respecting that on mainstream apps.

@marcoscaceres
Member

(fwiw, I think having per icon background color might be a "nice to have" thing - it seems kinda niche, but need to find evidence).

@kenchris
Collaborator
kenchris commented Jun 8, 2015

Well, at least at Google I/O it was announced that the Material Design Guidelines how includes a section on guidelines for splash and launch screens:

https://www.google.com/design/spec/patterns/launch-screens.html

"Because launching your app while displaying a blank canvas increases its perceived loading time, consider using a placeholder UI or a branded launch screen."

That sounds pretty much like a recommendation in some cases :-)

@marcoscaceres
Member

How about having background_color on icon and icon_background_color. That would allow authors to override icons_background_color.

{
"icons": [
   {"src": "icon.png",
    "background_color": "orange" },
   {"src": "icon.png"}
],
"icons_background_color": "red"
}

I also seriously want to introduce platform and theme on image objects too - to address @pornel's use cases from #361.

@marcoscaceres
Member

(fixed JSON above)

@marcoscaceres
Member

The same as above for splashscreen.

@marcoscaceres marcoscaceres added P1 and removed P2 labels Jun 11, 2015
@pornel
pornel commented Jun 11, 2015

In Safari 8 9 Apple has introduced a new kind of icon for pinned tabs which they hacked with a non-standard mask attribute.
The icon must be a vector icon, which is only black+transparent, and the browser changes the icon's color based on <meta theme-color> (which is wrong, because theme is a background color and they use it for foreground color). edit: it's all fixed now <meta rel=icon-mask color>.

So maybe {src:"icon.svg", sizes:"all", "foreground_color":red} is needed for that?

@marcoscaceres
Member

Article re: YouTube update states:

Many people have also been taking notice of Google's recent about-face regarding splash screens. While the practice used to be frowned upon, a recent change to the Material Design spec declared that Launch screens are acceptable for apps that take too long to display content at startup. Drive was the first app to receive this treatment, followed shortly thereafter by Maps. Now that YouTube has joined the ranks, a number of people have already mentioned that it feels much snappier.

@marcoscaceres
Member

Marking "at risk" while waiting on feedback from potential implementers.

@pornel
pornel commented Mar 24, 2016

Why is it at risk when it ships in Chrome? (…with ugly hack that repurposes other fields, because this one was missing…)

@marcoscaceres
Member

Chrome uses icons + background_color to create splashscreens (instead of splashscreens member). Their feedback is that the bg+icons combo is sufficient, but having this in the spec is causing confusion.

On 25 Mar 2016, at 9:32 AM, Kornel notifications@github.com wrote:

Why is it at risk when it ships in Chrome?


You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub

@pornel
pornel commented Mar 25, 2016

That's unfortunate, because I find Chrome's implementation hacky, fragile and insufficient to build a quality experience.

AFAIK Chrome's recommendation is to design a 192px icon for the splash screen, and then hope that maybe other sizes will be used elsewhere. I understand they've done it for an MVP, but that's not good enough to keep.

Design of our app calls for a different style of logo on the splash screen than it uses for the homescreen icon (splash logo should be larger, with name in our brand font, and without a shadow).

Additionally, on the first run, our app needs to download initial data before it can lay out the homepage (homepage layout is dynamic and server-driven), so we do have our own HTML/CSS splash screen. AFAIK there's no way to guarantee when Chrome decides it has the first useful render of the page, so we risk that Chrome's splash screen and our in-app splash screen will be slightly different and cause glitchy/jarring jump of the logo on two distinct splashcreens.

We'd like to create a seamless experience where splash screen looks the same from the first render by Chrome, until our app has downloaded data (optionally with a progressbar rendered on our HTML splash screen if download takes long, so just keeping Chrome's bare splash for longer is an unattractive option).

Implementation of splash screens on iOS is a little bit buggy, but allows us to implement our design, and it's so much better than what Chrome ships.

@PaulKinlan

Just to be clear our guidance is to use a larger icon. 192 is minimum.

On Fri, 25 Mar 2016, 17:43 Kornel, notifications@github.com wrote:

That's unfortunate, because I find Chrome's implementation hacky, fragile
and insufficient to build a quality experience.

AFAIK Chrome's recommendation is to design a 192px icon for splash screen,
and then hope that maybe other sizes will be used elsewhere. That's not
good enough.

Design of our app calls for a different style of logo on the splash screen
than it uses for the homescreen icon (icon should be larger, with name in
our brand font, and without a shadow).

Additionally, on the first run, our app needs to download initial data
before it can lay out the homepage (homepage layout is dynamic and
server-driven), so we do have our own HTML/CSS splash screen. AFAIK there's
no way to guarantee when Chrome decides it has the first useful render of
the page, so we risk that Chrome's splash screen and our in-app splash
screen will be slightly different and cause jarring jump of the logo.

We'd like to create a seamless experience where splash screen looks the
same from the first render by Chrome, until our app has downloaded data
(optionally with a progressbar rendered on our HTML splash screen if
download takes long).

Implementation of splash screens on iOS is a little bit buggy, but it's so
much better
than what Chrome ships.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9 (comment)

@pornel
pornel commented Mar 25, 2016

Could you at least extend definition of icons to have a field like "role": "splash", so that the pixel size is not the deciding factor?

And please don't put app name underneath it on the splash screen. Roboto is not our font.

@marcoscaceres
Member

On 26 Mar 2016, at 4:55 AM, Kornel notifications@github.com wrote:

Could you at least extend definition of icons to have a field like "role": "splash", so that the pixel size is not the deciding factor?

That's just shifting the problem up one level.

The point here is to bootstrap the progressive apps ecosystem by covering the 80% case. Once we get more than Chromium-based browsers supporting this standard, we can come back and add more things (even things we know we need, like this!).

We need another year or so for that to happen so we are trying to reduce the feature set to "good enough" for now. That may help us convince Microsoft and Apple to implement, and Mozilla to use my implementation in a product like Fennec.

To be clear: there is no point in having splashscreens in the spec if Chromium is not going to implement it, so we should take splashscreens out till they are convinced otherwise.

We need more sites like FT saying "we need this" in order to change their minds.


You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub

@laukstein

@pornel, sizes: "all" proposed in #407.

@jakearchibald

@pornel

We'd like to create a seamless experience where splash screen looks the same from the first render by Chrome

I agree with this goal, but I don't think a list of image urls is the way to achieve it, especially given the variety of resolutions.

The best answer I have is an html page that the browser runs, and on onload rasterises it at all the resolutions it needs it (presumably one for each orientation).

@marcoscaceres
Member

The best answer I have is an html page that the browser runs, and on onload rasterises it at all the resolutions it needs it (presumably one for each orientation).

Agree. The presupposition being extremely fast browser boot times (i.e., sub 100 or 200ms). It seems Chrome is getting there, and we were there with FirefoxOS before it got killed.

@marcoscaceres
Member

Ok, splashscreens are 410.

@jakearchibald

The presupposition being extremely fast browser boot times

Wait, are we talking about the same thing? I'm talking about the browser caching and caching bitmaps at add-to-homescreen time, then displaying them at next launch while the browser boots up.

@marcoscaceres
Member

Wait, are we talking about the same thing? I'm talking about the browser caching and caching bitmaps at add-to-homescreen time, then displaying them at next launch while the browser boots up.

Yes, but that still presupposes that the browser engine will boot up quickly. The point of the splash screen was to mitigate the wait time between the browser booting up and first paint - which for some engines was more than 1.5 seconds. On engines that do take ages, is currently handled through the combination of icons + background_color.

If an engine can cold start and first paint fast enough, it doesn't need to show anything the icon + background color - and can hence show its own HTML splashscreen.

@jakearchibald

Pretty sure we're talking about different things.

As far as i can tell, you're talking about an HTML splash screen when the app launches, which doesn't need anything from the manifest, as it's just the app.

I'm talking about a special HTML resource, specified in the manifest, which the browser uses to generate bitmap splashscreens at the point of "install". One of these bitmaps is then displayed as the splashscreen at launch time, while the browser loads.

@jakearchibald

My idea isn't needed if the browser can get to first render, from cold, in 100ms

@marcoscaceres
Member

Pretty sure we're talking about different things.

No, no... ok, yeah :)

As far as i can tell, you're talking about an HTML splash screen when the app launches, which doesn't need anything from the manifest, as it's just the app.
I'm talking about a special HTML resource, specified in the manifest, which the browser uses to generate bitmap splashscreens at the point of "install". One of these bitmaps is then displayed as the splashscreen at launch time, while the browser loads.

Ok, yeah... Not talking about that. I would be against such a thing... it's would be super complicated to get right and know when to take the screenshot... like a selfie, but for web apps :)

My idea isn't needed if the browser can get to first render, from cold, in 100ms.

I'd rather we (browsers) get to the above.

@jakearchibald

The timing would be window.onload - but I agree we shouldn't explore it as an option unless quick browser load time become unattainable.

@laukstein

@marcoscaceres, you forgot to remove https://github.com/w3c/manifest/blob/51ebee66f37d1d7652dc26411ca0b8492d1287d6/index.html#L153-L156

"splash_screens": [{
    "src": "splash/lowres",
    "sizes": "320x240"
  }
@marcoscaceres
Member

D'oh. PR?

Sent from my iPhone

On 5 Apr 2016, at 7:55 PM, Binyamin Laukstein notifications@github.com wrote:

@marcoscaceres, you forgot to remove https://github.com/w3c/manifest/blob/51ebee66f37d1d7652dc26411ca0b8492d1287d6/index.html#L153-L156

"splash_screens": [{
"src": "splash/lowres",
"sizes": "320x240"
}

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@laukstein

D'oh. PR?

@marcoscaceres, you removed all documentation related to splash_screens except the mentioned in example https://w3c.github.io/manifest/#example-manifest

@anssiko
Collaborator
anssiko commented Apr 5, 2016

@marcoscaceres PR #445.

Sorry about the monkey patch, my editor (TextMate FTW!) still does not like it.

@marcoscaceres
Member

I'm going to buy you a copy of Sublime.

On 5 Apr 2016, at 9:43 PM, Anssi Kostiainen notifications@github.com wrote:

@marcoscaceres PR #445.

Sorry about the monkey patch, my editor (TextMate FTW!) still does not like it.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@julienw
julienw commented Apr 5, 2016

The timing would be window.onload - but I agree we shouldn't explore it as an option unless quick browser load time become unattainable.

The experience in Firefox OS showed that this is not really good. For some apps we'd have the final state, some other apps would have some waiting state, some other apps would be in a "loading but not finished loading but no splashscreen" state. The solution is a new "event" (or you can call that an API) that the app could send (or call).

@pornel
pornel commented Apr 5, 2016

I like the idea of browser screenshotting a splashscreen in HTML format — it'd be possible to create responsive splash screens with correct font rendering. I hope the browser could prepare such splash screens immediately (in background) when the app is added to the homescreen, so there's no other splash-placeholder screen before the splash screen.

I think it should be a screenshot from a separate dedicated resource (/splash.html), and not a screenshot from start_url, because optimizing app for both fast, fully asynchronous startup and showing of screenshotable splash at a time of specific event (like the load event) is complicated.

@laukstein

the idea of browser screenshotting a splashscreen in HTML format

How do you imagine it behavior animated splashscreen? The icon itself may be animated image.

@jakearchibald

I hope the browser could prepare such splash screens immediately (in background) when the app is added to the homescreen

That was what I was thinking. It'd create screenshots of both orientations too.

I think it should be a screenshot from a separate dedicated resource (/splash.html)

Agreed, although they may point at the same resource, which would work for some things like https://jakearchibald.github.io/svgomg/

@jakearchibald

How do you imagine it behavior animated splashscreen?

I don't think that should be supported.

@marcoscaceres
Member

I don't think that should be supported.

And this is the problem. If you look at the examples from #9 (comment), most of those do have some animated aspect to them... e.g., twitter's "bounce zoom in", or LinkedIn's "exciting" slide down to reveal, and other fancy fades and transitions... it's all part of the UX the web would be denying users and developers by using a screenshot solution.

@jakearchibald

Right, but the screen shot could be the first frame of the animation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment