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/CAL5BFfWDUhgjsdOvHWD_rars%2BgHa0dDwnBfUuxYNHxegy9C_1A%40mail.gmail.com.
