Re: [w3c/manifest] Clarify the definition of "navigation scope", "applied", and off-scope theming (#880)

I thought it might be useful to provide some examples of implementations I've worked on outside of Android and iOS, in order to not constrain the thinking to contemporary mobile operating systems and be more open minded about how this specification might be used in the future.

**Firefox OS 2.6**

In Firefox OS 2.6 the web browser was merged with the core system UI such that users could seamlessly transition between "pinned" web apps, and the rest of the web. This is in contrast with other mobile operating systems in which there are much firmer boundaries between installed applications.

When browsing the web, web applications could be "pinned" (installed) using their web app manifest. Whenever the user navigated to a URL within the scope of a pinned app, the manifest metadata was applied to the browsing context and whenever they navigated away from the scope of the app, the manifest would be un-applied.

When navigating to a URL within the scope of a pinned app with a standalone display mode, the URL bar would shrink down into the status bar and turn into a title bar to look more like an app. When navigating out of the scope of the pinned app, the URL bar would expand out into a full URL bar to look more like a browser. (The user could always access the full URL bar by tapping to expand it).

![pin_app](https://user-images.githubusercontent.com/552417/83405097-b95da280-a403-11ea-84e9-8244d40192ec.png)


There's a video [here](https://www.youtube.com/watch?v=CWUIvo0BzBU) which shows part of that behaviour.

**Krellian Kiosk**

I'm currently working on an [implementation](https://github.com/krellian/kiosk) of a web application runtime where a single web application may be installed to an interactive kiosk for use by the public. In this use case, the administrator wants to ensure that *only* the installed web application can be navigated to, and any attempted navigations outside of the scope of the web application are blocked. I believe Chrome OS has a kiosk mode which does something similar.

Another related use case is in deploying a single web application to a digital signage display, which has completely passive content and no user interaction on the display itself. Web app installation and navigation are controlled over the network from a separate controller application.

![kiosk](https://user-images.githubusercontent.com/552417/83405118-c24e7400-a403-11ea-9e53-8a3c0a659169.png)


The reason I'm providing these examples is to try not to constrain future innovation in user agents by simply describing the behaviour of existing smartphone web browsers in the specification. I suggest it would better to allow some flexibility in the specification for user agents to decide when to apply a manifest and how navigations outside of the manifest's scope should be handled.

How about defining scope as "the set of URLs to which the manifest applies." This could be qualified by saying that it doesn't mean that user agents can't also apply some aspects of the manifest's metadata to other URLs if they are navigated to from an application context, but that the metadata is primarily intended to apply to that set of URLs, not the whole web.

-- 
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/pull/880#issuecomment-636829085

Received on Monday, 1 June 2020 12:23:03 UTC