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

@aarongustafson :
> One clarification (which I’d like reflected in the original issue): @amandabaker came up with the display modifiers proposal in [that initial issue description](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/206) as an alternate approach, not me. I think it’s a great idea, but I can’t accept credit for it. Personally, I think that approach has the most potential for expansion and future development as well.

Apologies, @amandabaker. I was looking at Aaron's comment that expanded on `display_modifiers` and didn't notice you had proposed it in the original issue report. Updated the text on this bug.

@NotWoods :
> For what it's worth, Firefox for Android/Fenix also implements `minimal-ui`.

Oh OK, thanks for that context. Edited the post.

@marcoscaceres :
> I'm personally not a fan of changing the `display_mode` to an array, as that will break backwards compat.

I proposed it as either a string or an array; it doesn't break backwards compat because the string version would still work.

Re historical `window.open` modes not being well supported: I think that precedent doesn't necessarily apply here, for a number of reasons:

1. That proposal had a different context, which was giving web pages (in a standalone window) control over browser UI. It's understandable that browser manufacturers were hesitant to actually give sites this level of control. We're in a totally different context here, which is that we're creating an apps platform, with explicitly user-installed apps, and it makes a lot more sense to give those apps control over their user experience.
2. Generally, those `window.open` settings were about *removing* browser features. In this context, almost everything is removed by default, and we want to give sites the ability to ask for features *added back*.
3. `window.open` simultaneously gave too much and not enough control. It's very tied to the layout of a standard browser window at the time: "menu bar", "tool bar", "status bar" --- these things typically don't even exist on mobile. You're giving sites control over large chunks of browser UI that may or may not make sense in different browsers. At the same time, you're still not giving developers actual control over what controls are visible. If I ask for "toolbar", how do I know if it's got a back button? A refresh button? I don't want to (necessarily) expose control over scrollbars, status bar, toolbars. I want developers to be able to ask for specific actionable controls, like "back button", "refresh button", (maybe) "URL bar".
4. I think we should consider and measure the value of each proposed modifier on its own merits. For example, maybe "back button" is useful enough to be controllable, but "forward button" isn't considered necessary in an app context. I don't want to just throw a dozen controls into the mix. So we'll be a lot more careful, basically, to only expose useful options for developers.

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