Just as a heads up, all concerns have been addressed and the latest version of the spec is in a state where I believe we are all happy with. Thanks for all the feedback and comments!
On Wednesday, 1 December 2021 at 18:26:03 UTC luig...@microsoft.com wrote: > 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/de69002a-a62a-483a-a799-1269b11b573bn%40chromium.org.
