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+unsubscr...@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/CAL5BFfUcDLfCiiitD2ROM_EGOd9Hg1QEz5otrOYoEXu9BxON-Q%40mail.gmail.com.
