Re: [w3c/manifest] More precise control over app window features (#856)

> @mgiuca , I don't think I have seen any native app model that provide default menu like PWA so far, the reason is that developers don't like default menu (They want their users to immersive into their app whether it is a client or non client area). I'm not sure if Android PWA has default menu if security is a real concern for it?

Android PWAs expose an equivalent of that menu through a low-priority notification (you can drag from the top of the screen while using a PWA), which exposes the basic features of copy URL, share and open in Chrome.

I don't think it's because "developers don't like it"; I think the value of such a menu is limited in a native app platform. The menu essentially exposes "browser-like features" that apply to the current page: access to encryption information, the URL underlying the current page, being able to move the page back into a browser, HTML-based zoom, find-in-page, print, etc. Those things are traditionally available for web pages, but they have no real native equivalent.

Whether or not developers like it, I see it as a compromise between the "purity" of the app experience where the developer has total control (which is arguably the developer standpoint) and the utility of providing those web-based controls, to ensure that when a user installs a website as an app, we aren't removing a whole bunch of features (security, and otherwise). It's our job as the user agent to represent the user; yes, we're providing a platform for developers, but the web platform doesn't generally give the developer the ability to remove utility from the user (e.g., no way for a website to request that a browser hides the "view source" button).

I think we could see this as a user-agent specific feature which perhaps Edge could do for apps installed in the store.

> @mgiuca , btw, the other suggestion I have besides this is to support platform based UI. Desktop, phone are totally different form factor so it is quite difficult to have universal UI that fit both platforms, and every platform's UI has its own philosophy so single UI view won't work for all . It would be great if developer handles these by themselves instead of individual browser, for example, ('windows': [backbutton=true, 'no_menu', ], 'android'=['no_contex_menu', ].

I'm generally opposed to speccing user-agent-specific or OS-specific customization options. That tends to lead to websites that are designed to work really well on a handful of popular operating systems, and with a poor experience on OSes that the site developer hasn't thought about. We're trying to build a platform where you specify your requirements _semantically_, then the user agent does its best to interpret that data and tailor it for the host OS; that way, a future OS can pop up and interpret the existing data, rather than having to wait for sites to update with specific metadata for the new OS. (An example of this philosophy is the maskable icons design, in which we resisted the temptation to have a field where you provide a specialized icon for each OS; see [this discussion](https://github.com/w3c/manifest/issues/555) and search for "Option C".) Therefore, we should not have an option for each OS; if we want to give developers control over this, we should have a setting like "browser_menu" (which is up to the user agent by default, but can be set to `true` or `false` as a hint to the user agent).

-- 
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/issues/856#issuecomment-650874381