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/c90bf88b-e641-46e0-b305-afd428900a13n%40chromium.org.
