Standalone should not relate to fullscreen but no-chrome

[ernesto-jimenez]

We are currently linking standalone mode with fullscreen.

In my opinion, this should be linked with getting rid of the chrome, not full-screen. @benfrancis and myself were discussing it in IRC and come up with the following reasons:

• In Mobile, getting rid of the chrome means "fullscreen", but that wouldn't be the case in desktop
• In Mobile, fullscreen usually means the status bar is not shown, which is not the case for the current apple-mobile-web-app-capable standalone mode

@benfrancis mentioned Firefox OS manifest format includes a "chrome" property, which might be more appropriate than standalone mode.

[benfrancis]

I also wonder whether there might be value in bringing this "chrome" property in line with the features argument that can be passed to window.open() to specify which browser chrome to display [1].

1. https://developer.mozilla.org/en-US/docs/Web/API/Window.open#Toolbar_and_chrome_features

[benfrancis]

Note that the Mozilla Open Web App manifest also has a separate "fullscreen" field [1] for an app to launch in true full screen (e.g. for games).

1. https://developer.mozilla.org/en-US/Apps/Developing/Manifest#fullscreen

[ernesto-jimenez]

I would +1 supporting the chrome and fullscreen properties.

In that case standalone would be a matter of wether the app is intended to be opened inside a browser tab or as an standalone app.

Standalone: false

• Chrome: true, Fullscreen: false - Open web app regularly in a browser tab
• Chrome: false, Fullscreen: false - Open web app in a new browser tab without back buttons, location bar, etc...
• Chrome: false, Fullscreen: true - Open web app in a new browser tab without back buttons, location bar, etc... and automatically get in full-screen
• Chrome: true, Fullscreen: true - Open web app in a new browser tab and automatically get in full-screen

Standalone: true

• Chrome: true, Fullscreen: false - Open web outside of the regular browser but include browser controls (might be a minimal chrome like Firefox OS's)
• Chrome: false, Fullscreen: false - behaviour of apple-mobile-web-app-capable
• Chrome: false, Fullscreen: true - Open web app fullscreen and without chrome. Games would probably use this in mobile and desktop.
• Chrome: true, Fullscreen: true - Open web app fullscreen but with minimal chrome controls.

[marcoscaceres]

I want to avoid boolean based manifest properties (e.g., fullscreen). They always end in tears. So, for that, we would need something like "viewmodes": ["fullscreen"] or some such.

Also, it's important to understand why FxOS had to add a chrome property. It was because it made the incorrect assumption that a mobile app could simply be treated as an installed app if an application simply added a manifest.

I would prefer to learn and document from any mistakes FxOS has made, and try to avoid replicating anything there.

[ernesto-jimenez]

+1 to not using the boolean attributes, it was just simpler to illustrate the logic :)

I also agree that we need to understand this better. I created an issue for the installable-webapps document to expand the standalone part and cover these things.

[benfrancis]

Note that the "fullscreen" property doesn't mean "this app can be used in full screen mode", it means "this app should be launched in full screen mode".

Any hosted app can have a fullscreen mode which it requests via the full screen API.

[johnmellor]

Standalone: false, Chrome: false, Fullscreen: false - Open web app in a new browser tab without back buttons, location bar, etc...

I'm not sure this is a real use case that browsers want to support.

Standalone: true, Chrome: true, Fullscreen: false - Open web outside of the regular browser but include browser controls

I'm also not convinced that many standalone apps would choose to give up screen real estate in order to get a back button (and presumably not much else that's relevant).

Can we not merge standalone:true and chrome:false into a single case? In fact, could we combine them all into a single three-way option?:

display: browser-tab | standalone | fullscreen

[ernesto-jimenez]

@johnmellor sounds good to me, browser-tab would be the default value for display.

The only thing I'm missing is: standalone: true, chrome: true, fullscreen: false.

Firefox OS supports this although as an exceptional measure for existing websites that want an standalone version but rely on the browser back button for navigation

I'm not attached to it and we might want to drop that use case, but it would be good to make sure nobody would miss it.

[johnmellor]

@mounirlamouri made a good point offline that games in particular might want to default to launching in fullscreen mode, but allow the user to put them into windowed mode (presumably the UA would remember what mode they were last open in). So perhaps tying fullscreen to this is a bad idea.

[ernesto-jimenez]

Notes from IRC conversation with @marcosc, @johnmellor and @mounirlamouri

We would probably want the property to work as a list of sorted preferences (like font-family in CSS).

In that case, a game would use (using placeholder names for attributes and values):

"display": ["standalone-fullscreen", "standalone-windowed", "standalone"]

An app for Desktop and Mobile would do:

"display": ["standalone-windowed", "standalone"]

When talking about windowed, we raised @benfrancis' comment about allowing finer-grained control of the window creation aligning with window.open features attribute. That would make sense specially since in desktop you would probably want to allow developers to specify things like the default window size and wether the window was resizable. Maybe by using a window_features property.

However, we suggested not considering window_features for the initial spec. It's something that we could address in an extension spec to address windowed web apps. Specially since there might be other features to consider for windowed apps such as native menu support.

[benfrancis]

When talking about windowed, we raised @benfrancis' comment about allowing finer-grained control of the window creation aligning with window.open features attribute.

I was thinking about the toolbar=yes|no|0|1 feature because it could fulfil the use case where a standalone app wants to opt-in to a navigation toolbar. However, I've just noticed that the current HTML5 spec actually discourages the use of the features argument to window.open altogether so maybe aligning with that isn't so important.

The only thing I'm missing is: standalone: true, chrome: true, fullscreen: false.
Firefox OS supports this although as an exceptional measure for existing websites that want an standalone version but rely on the browser back button for navigation

This was a popular demand for content creators who wanted to turn their existing web content into a web app, including high profile properties like Facebook and YouTube.

[marcoscaceres]

Just thinking this through again...

As we already know, when the user presses "add to home screen", a web application that lacks a standalone switch (i.e., "mobile-web-app-capable" today) opens as follows:

• Chrome on Android and iOS Safari open the web application in a tab.
• FirefoxOS opens the web app in a special windowed mode, that lacks a URL bar but provides navigation buttons.

When the "mobile-web-app-capable" trigger is present or when the application is "installed" in the case of FxOS:

• Chrome, iOS, and FxOS all open the web application "windowed" (i.e., have a status bar but no UI/nav chrome).

Now, if we treat <link rel="manifest" href="foo.json"> serving an equivalent function to "mobile-web-app-capable" for when a user presses "add to home screen", then we can do away with saying "standalone" (as it just becomes the default).

That means that, for hosted applications, we would need:

display: browser-tab |  fullscreen | auto

As:

1. When the display member is "auto", missing, or unknown/in-error, use the UA's default (i.e., default to show status bar).
2. When the display member is fullscreen, UA removes the status bar.
3. When the display member is browser-tab, open it in the browser even though it's a hosted app (i.e., this is an override).

I think that covers everything - including continuing to support non-conforming/legacy UAs.

In all the cases above, the metadata of the manifest can still be used for populating a bookmarking dialog.

[marcoscaceres]

The above looks like this:

[ernesto-jimenez]

@marcoscaceres, I think I might be missing something.

Looking at the diagram, it seems to me we are just saying that no display and "auto" actually mean "windowed". What's the benefit then of having "auto" instead of "windowed"?

In my opinion, since the manifest is declarative, we are better off having the developer say "windowed" when they mean "windowed" rather than saying "auto".

Also, as a developer, "auto" to me would mean "UA Default", not "windowed". So it's a bit counter-intuitive to hide "windowed" behind "auto" or the lack of display.

[kenchris]

I don't like "browser-tab" much... and there might be other embedded uses for apps, like widgets on Smart TV's etc... what about "hosted"?

[ernesto-jimenez]

@kenchris, you don't like the name or don't like the idea of specifying an app needs to be opened in-browser?

I think the names are currently placeholders while we discuss the functionality. I don't like "browser-tab" either :)

[kenchris]

The name... it is too specific. We also really need to look at fullscreen and see how that would work on platforms like Android which has various modes, like immersive and immersive-sticky and iOS with minimal-ui (relating to system UI and not just chrome)

[marcoscaceres]

@kenchris, as @ernesto-jimenez said, the names are just placeholders for now. Maybe I should post-fix all of them with -bikeshed just to make that clear. We are just trying to make sure we get agreement on the functionality before bikeshedding.

[marcoscaceres]

@ernesto-jimenez yeah, I kinda came to the same conclusion when I was making the diagram - but I didn't want to impose "windowed" as that's also a bit of a fuzzy concept. That is, it seems just consequential that UAs display these kinds of apps as windowed, what windowed means is somewhat different from one UA to another.