There is a PR waiting to be merged that adds a note about developers using reasonable fallbacks on unsupported browsers, I will let you know once it gets merged.
On Wednesday, 1 December 2021 at 17:29:03 UTC Diego González wrote: > 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/c151eb9e-4454-4dfc-bc55-616447d74d32n%40chromium.org.
