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

Just to note a historical precedent for this kind of feature, the `features` argument to `window.open()` which is a comma-separate list of requested features of the new window.

MDN [lists](https://developer.mozilla.org/en-US/docs/Web/API/Window/open#Window_features) possible values like:

- `menubar` (whether to render the menu bar)
- `toolbar` (whether to render toolbar buttons like back, forward, reload, stop)
- `location` (whether to render the location bar)
- `status` (whether to render the status bar)
- `resizable` (whether the window is resizable)
- `scrollbars` (whether to show horizontal and/pr vertical scrollbars)

As I understand it, these values were never properly standardised and were supported inconsistently between browsers and are now mostly ignored by modern browsers where they are just used as a hint to determine whether to open a popup, new tab or new window.

So a couple of options might be:

1. Add a top level `features` member to the manifest which allows the developer to request enabling/disabling a similar list of UI features for a given application context
2. Heed the warning of history that this may not work in practice and stick to simple display modes

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