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/de226ab2-e3b8-4063-acee-eb82577dc1dbn%40chromium.org.
