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

@benfrancis it seems like your practical objection to this change comes from a desire to have additional restricted modes (such as kiosk modes) that do restrict PWAs to their scope or a restrictive set of URLs.

I would suggest that such a mode falls outside of the manifest spec, and into the realm of (legitimate) user agent interventions, by way of offering their users (administrators) additional control over what URLs can be browsed to. It's very similar to a parental control feature that a web browser may offer, to let parents restrict the set of browsable URLs to a specific allow-list. You don't need to the permission of the HTML spec to prevent navigation to a URL that's been banned by the parent, it's essentially a deviation from the spec requested by the user.

I would argue it makes sense to keep these two things (the scope of a PWA, and a kiosk-like prevention of navigating outside the PWA) separate. There's no reason kiosk mode needs to necessarily be limited to the scope of the PWA. For example, you might let the administrator configure an allow-list, so that you can navigate to certain other origins within the PWA, but not the whole internet.

> Are you sure you want to forbid user agents from transferring any navigation to another top level browsing context? Is this not a product decision?

It isn't a product decision, because it violates the basic assumption that sites make about how HTML navigation works. (As we discovered two years ago in #646.) This isn't obvious, to me anyway, it took months of analysis, discussion, and experimentation (as you can see by reading over #646, the corresponding Chrome bug https://crbug.com/861618, and the corresponding manifest PR #701), to come to the realisation that this wasn't a mere product decision; allowing UAs to open target=_self links in a new top-level browsing context was breaking websites because it violated the normal navigation flow of HTML. So, we changed the Manifest spec to explicitly _forbid_ UAs from doing that. This PR was not intended to re-open the debate; it's just fixing up a piece of text mistakenly left over from #701 .

As I said above, UAs are free to make a product decision to restrict the set of navigable URLs, at the request of the user, but this should be opted in by the user or administrator (e.g., by using a special kiosk mode). The normal operating mode of a compliant browser should not break websites.

> 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.

That seems to be more or less what the spec (erroneously) says today: scope is "the set of URLs to which the manifest applies", but elsewhere in the spec it says that the manifest can apply to any URL, not just one in the navigation scope. Those are contradictory statements. I'm looking for clear normative text here that can be implemented in a web browser. "primarily intended to apply" is not a clear statement.

I think the change suggested in this PR is entirely compatible with your kiosk feature.

-- 
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-638587554