YUC. 😉 If a developer has used the environmental variables and the web app gets installed in browser that does not support it (then it is a parallel universe because Firefox nor Safari nor other desktop browser supports this *kidding*) then they can specify reasonable fallback values because they value progressive enhancement and responsive design. I will add a note about this to the spec, if you think it is necessary.
Lack of WCO support and lack of user opt in do not look the same. In a supported browser both the env variables and the JS object in navigator exist even if the feature is turned off. On Wednesday, 1 December 2021 at 11:11:03 UTC yoav...@chromium.org wrote: > On Tuesday, November 30, 2021 at 6:48:07 PM UTC+1 Diego González wrote: > >> Hola Yoav, >> >> I wanted to add that we implemented the concept of a display-override to >> control the fallback of display modes. For non supported browsers, >> developers can also specify the display-override and even if this is not >> supported it will default to the display value in the manifest file. >> >> >> >> On Monday, 29 November 2021 at 18:29:41 UTC Diego González wrote: >> >>> Hola Yoav, >>> >>> For non supported browsers there are 2 options: >>> >>> - env variables take the specified default value by developers (if >>> devs enable WCO). >>> >>> > So IIUC developers are supposed to use the env variables with reasonable > fallback values for non-supporting browsers? Is that advice > captured/documented somewhere? > >> >>> - The web app will open as it would in the browser, with a titlebar >>> if installed (if devs don't enable WCO). >>> >>> WCO is enabled by the end user. The user must enable the feature by >>> toggling the chevron on the controls overlay. This is remembered on >>> subsequent app launches. >>> >> > OK, so lack of WCO support by the browser and lack of user opt-in would > look the same from the developer's perspective? > > >> >>> --diego >>> >>> On Friday, 19 November 2021 at 06:05:44 UTC yoav...@chromium.org wrote: >>> >>>> This looks great! Thanks for following up on the spec work!! >>>> >>>> I had a couple more questions upthread: >>>> >>>> - What are developers expected to do in non-supporting browsers? >>>> - Would the user need to opt-in to having web app control over >>>> their title bar? >>>> >>>> >>>> On Fri, Nov 19, 2021 at 1:25 AM Diego González <die...@gmail.com> >>>> wrote: >>>> >>>>> the the new *new* spec update >>>>> https://wicg.github.io/window-controls-overlay/ >>>>> >>>>> On Wednesday, 17 November 2021 at 19:06:24 UTC Diego González wrote: >>>>> >>>>>> Hola, >>>>>> >>>>>> See the updated spec here: >>>>>> https://wicg.github.io/window-controls-overlay. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> On Monday, 15 November 2021 at 17:00:34 UTC Ajay Rahatekar wrote: >>>>>> >>>>>>> cc: ajayra...@google.com >>>>>>> >>>>>>> On Monday, November 15, 2021 at 8:53:37 AM UTC-8 Diego González >>>>>>> wrote: >>>>>>> >>>>>>>> Hola Yoav, I am looking at making the amendments listed on the >>>>>>>> github issues. I will update soon with the changes. Thanks >>>>>>>> >>>>>>>> On Monday, 15 November 2021 at 08:44:41 UTC yoav...@chromium.org >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks Diego! The updates are a great improvement, but I suspect >>>>>>>>> are not sufficient for an interoperable implementation. I left a >>>>>>>>> couple of >>>>>>>>> comments on the open issues. >>>>>>>>> >>>>>>>>> On Wed, Nov 10, 2021 at 5:11 PM Diego González <die...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hola Yoav, >>>>>>>>>> >>>>>>>>>> We've gone through several iterations of the WCO spec reviewed by >>>>>>>>>> Joshua Bell from Google, and while we are still making changes to >>>>>>>>>> it, we >>>>>>>>>> believe it is in a much better state and want to resubmit for >>>>>>>>>> consideration >>>>>>>>>> of the approvals needed for I2S. See the updated spec below: >>>>>>>>>> https://wicg.github.io/window-controls-overlay/ >>>>>>>>>> >>>>>>>>>> --Diego >>>>>>>>>> >>>>>>>>>> On Thursday, 21 October 2021 at 21:05:09 UTC+1 >>>>>>>>>> yoav...@chromium.org wrote: >>>>>>>>>> >>>>>>>>>>> On Thursday, October 21, 2021 at 9:31:23 AM UTC+2 Yoav Weiss >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> This is an exciting improvement to PWA parity with native apps! >>>>>>>>>>>> :) >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Oct 20, 2021 at 10:49 PM 'Diego Gonzalez' via blink-dev >>>>>>>>>>>> <blin...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Contact emails >>>>>>>>>>>>> >>>>>>>>>>>>> amb...@microsoft.com, luig...@microsoft.com, >>>>>>>>>>>>> hat...@microsoft.com, c...@chromium.org >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Explainer >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/WICG/window-controls-overlay/blob/master/explainer.md >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Specification >>>>>>>>>>>>> >>>>>>>>>>>>> https://wicg.github.io/window-controls-overlay/ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The spec looks like it could use some work. Beyond the >>>>>>>>>>>> editorial, it doesn't seem like it defines the novel concepts that >>>>>>>>>>>> it >>>>>>>>>>>> introduces, nor the relevant processing models. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Let me expand on that a bit. The spec introduces a new concept >>>>>>>>>>> of a "window overlay" without really creating it as a concept. >>>>>>>>>>> What I expect an interoperable spec to define the concept with >>>>>>>>>>> as much detail as possible without getting OS- or >>>>>>>>>>> implementation-specific. >>>>>>>>>>> (Just to draw an example of what I have in mind, if I had to >>>>>>>>>>> make something up, I'd go with something like: "<dfn>Window >>>>>>>>>>> overlay</dfn> >>>>>>>>>>> is an interface element that the operating system uses consistently >>>>>>>>>>> across >>>>>>>>>>> applications to enable the user to perform certain action to >>>>>>>>>>> control the >>>>>>>>>>> application such as closing it, expanding it to full screen, etc. >>>>>>>>>>> This UI >>>>>>>>>>> element takes fixed dimensions....") >>>>>>>>>>> >>>>>>>>>>> Then, once you have that concept defined, you can start building >>>>>>>>>>> on it and define the processing of the different methods based on >>>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>>> I'll open issues with other suggestions. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Design docs >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/WICG/window-controls-overlay/blob/main/explainer.md >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Summary >>>>>>>>>>>>> >>>>>>>>>>>>> Window Controls Overlay allows a developer to create a custom >>>>>>>>>>>>> title bar UX by extending the installed app’s client area. The >>>>>>>>>>>>> client area >>>>>>>>>>>>> now covers the entire window except for the window controls >>>>>>>>>>>>> (close, >>>>>>>>>>>>> maximize/restore, minimize), which are overlaid in their >>>>>>>>>>>>> respective >>>>>>>>>>>>> position. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The web app developer is responsible for drawing and >>>>>>>>>>>>> input-handling for the entire window except for the window >>>>>>>>>>>>> controls >>>>>>>>>>>>> overlay. This includes defining which area of the window is >>>>>>>>>>>>> draggable as well, with a prefixed and non-prefixed version of a >>>>>>>>>>>>> css >>>>>>>>>>>>> property supported, as implemented in: crrev.com/c/3094474. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Intended uses for the Window Controls Overlay are creating >>>>>>>>>>>>> seamless UX that can use the area that was reserved for the title >>>>>>>>>>>>> bar >>>>>>>>>>>>> before. Many modern applications include menus, search bars and >>>>>>>>>>>>> other >>>>>>>>>>>>> controls in the title bar, and this feature enables this on >>>>>>>>>>>>> installed web >>>>>>>>>>>>> apps. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Blink component >>>>>>>>>>>>> >>>>>>>>>>>>> UI>Browser>WebAppInstalls >>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3EWebAppInstalls> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Search tags >>>>>>>>>>>>> >>>>>>>>>>>>> PWA <https://chromestatus.com/features#tags:PWA>, web app >>>>>>>>>>>>> <https://chromestatus.com/features#tags:web%20app>, title bar >>>>>>>>>>>>> <https://chromestatus.com/features#tags:title%20bar>, titlebar >>>>>>>>>>>>> <https://chromestatus.com/features#tags:titlebar>, >>>>>>>>>>>>> customization >>>>>>>>>>>>> <https://chromestatus.com/features#tags:customization>, window >>>>>>>>>>>>> controls >>>>>>>>>>>>> <https://chromestatus.com/features#tags:window%20controls> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/481 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> TAG review status >>>>>>>>>>>>> >>>>>>>>>>>>> Resolution: satisfied >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Risks >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>> >>>>>>>>>>>>> Given that Edge has interest in the feature, there would be at >>>>>>>>>>>>> least one other browser that implements it. The feature involves >>>>>>>>>>>>> additive >>>>>>>>>>>>> changes (new web app manifest entry, new JS API, new CSS env >>>>>>>>>>>>> variables) and >>>>>>>>>>>>> modifications (changes to frame, new use of >>>>>>>>>>>>> env(safe-area-inset-*), but no >>>>>>>>>>>>> removals, so the compatibility risk is minimal. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Gecko: defer >>>>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/529 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> WebKit: No signal >>>>>>>>>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031865.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Web developers: Positive >>>>>>>>>>>>> >>>>>>>>>>>>> https://twitter.com/firt/status/1385238446046859268?s=20 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://twitter.com/AnaestheticsApp/status/1408727417330573314?s=20 >>>>>>>>>>>>> >>>>>>>>>>>>> https://twitter.com/bashik7/status/1385821988208275457?s=20 >>>>>>>>>>>>> >>>>>>>>>>>>> https://twitter.com/abraham/status/1385201046767738880?s=20 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Ergonomics >>>>>>>>>>>>> >>>>>>>>>>>>> The changes associated with this feature will only be enabled >>>>>>>>>>>>> for PWAs that opt-in to it, so there are minimal risks posed to >>>>>>>>>>>>> the browser >>>>>>>>>>>>> as a whole. A PWA that opts-in to the feature should also have >>>>>>>>>>>>> minimal >>>>>>>>>>>>> ergonomics risk since the manifest already needs to be parsed on >>>>>>>>>>>>> startup to >>>>>>>>>>>>> determine the correct display mode in which the app should be >>>>>>>>>>>>> launched, so >>>>>>>>>>>>> adding one extra manifest check on startup should have minimal >>>>>>>>>>>>> impact. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Activation >>>>>>>>>>>>> >>>>>>>>>>>>> The activation risk is low since this feature includes all the >>>>>>>>>>>>> tools needed to create an app that uses the full extent of the >>>>>>>>>>>>> window: new >>>>>>>>>>>>> UA-provided window controls overlay, JS APIs to query the size of >>>>>>>>>>>>> the >>>>>>>>>>>>> overlay, and CSS environment variables to layout content around >>>>>>>>>>>>> the overlay. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> What do we expect developers to do as a fallback in >>>>>>>>>>>> non-supporting browsers? >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Security >>>>>>>>>>>>> >>>>>>>>>>>>> The major risk is that giving sites partial control over the >>>>>>>>>>>>> top of the app window allows developers to spoof content in what >>>>>>>>>>>>> was >>>>>>>>>>>>> previously a trusted, UA-controlled region. To minimize the risk >>>>>>>>>>>>> of >>>>>>>>>>>>> spoofing, the app will open by default in “standalone” mode with >>>>>>>>>>>>> a full >>>>>>>>>>>>> width title bar, and the user can toggle window controls overlay >>>>>>>>>>>>> on and off >>>>>>>>>>>>> via a button in the title bar/overlay. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OK, so both the app *and* the user need to opt-in? >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Debuggability >>>>>>>>>>>>> >>>>>>>>>>>>> The feature itself can be easily debugged by installing the >>>>>>>>>>>>> PWA. Since it is a visual feature on the window itself, it is >>>>>>>>>>>>> easy to test. >>>>>>>>>>>>> Nonetheless, making sure parsing the “display-override” mode and >>>>>>>>>>>>> associated >>>>>>>>>>>>> values correctly is desired, which should be incorporated into >>>>>>>>>>>>> the >>>>>>>>>>>>> application tab of devtools, where all the other manifest >>>>>>>>>>>>> warnings are >>>>>>>>>>>>> displayed. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>>>>>> ? >>>>>>>>>>>>> >>>>>>>>>>>>> 3170531: dpwas: WPT Tests for window-controls-overlay | >>>>>>>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/3170531 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Flag name >>>>>>>>>>>>> >>>>>>>>>>>>> #enable-desktop-pwas-window-controls-overlay >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>>>> >>>>>>>>>>>>> False >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>> >>>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=937121 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Launch bug >>>>>>>>>>>>> >>>>>>>>>>>>> https://crbug.com/1108107 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sample links >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://amandabaker.github.io/pwa/explainer-example/index.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>> >>>>>>>>>>>>> OriginTrial desktop last >>>>>>>>>>>>> >>>>>>>>>>>>> 96 >>>>>>>>>>>>> >>>>>>>>>>>>> OriginTrial desktop first >>>>>>>>>>>>> >>>>>>>>>>>>> 93 >>>>>>>>>>>>> >>>>>>>>>>>>> Expected Release >>>>>>>>>>>>> >>>>>>>>>>>>> 97 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>> >>>>>>>>>>>>> https://chromestatus.com/feature/5741247866077184 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>>> >>>>>>>>>>>>> Intent to prototype: >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/cper6nNLFRQ/hU91kfCWBQAJ >>>>>>>>>>>>> >>>>>>>>>>>>> Intent to Experiment: >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/HNHbpxvrECA/m/JJoXKQI3BAAJ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>>>> <https://www.chromestatus.com/>. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *Diego González-Zúñiga* >>>>>>>>>>>>> >>>>>>>>>>>>> PM, Microsoft Edge >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>>>> >>>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>>>> it, send an email to blink-dev+...@chromium.org. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/VI1PR83MB041666BD26451656C388347CCCBE9%40VI1PR83MB0416.EURPRD83.prod.outlook.com >>>>>>>>>>>>> >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/VI1PR83MB041666BD26451656C388347CCCBE9%40VI1PR83MB0416.EURPRD83.prod.outlook.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0dd2b7ba-8307-43dc-b0a4-32e775bed90dn%40chromium.org.
