Re: [w3ctag/design-reviews] Borderless mode (Issue #852)

Thank you for your detailed feedback. We agree that probably it makes sense to first go through the IWA proposal/review before a feature which depends on it strongly. Here’s some pointers to the feedback.

IWAs
It is important to note that the borderless feature is primarily designed for use in high-trust environments (IWAs) and not intended for the broader web platform in its current form. In the event that we’d consider expanding its use to the broader web, additional mitigations and fallbacks to address potential risks should definitely be explored. Our main goal w.r.t. the web platform is making sure that this design doesn't prevent future mitigations or fallbacks in the future if they are needed.

Webkit-prefix
Someone from Microsoft is working on addressing this issue [crbug.com/1447586](http://crbug.com/1447586). 

Draggability
Actually in some scenarios, non-draggable windows are the desired outcome, such as for when the app wants to open non-draggable modal dialogs or right-click menus from the VDI session. I made a [PR](https://github.com/WICG/manifest-incubations/pull/84) to highlight such use-cases better in the explainer.

Sharp cliff
There is already the existing Window Controls Overlay feature which can be seen as the “simple case” for most users providing minimal draggable area. However, as discussed on the explainer this would not be sufficient for our trusted partner's use cases.

Accessibility
Web content allows the creation of accessible websites. We would expect our trusted partners to leverage the existing capabilities (together with the upcoming [AWC](https://github.com/ivansandrk/additional-windowing-controls/blob/main/awc-explainer.md)) to ensure accessibility in their isolated web apps. This is something I added to the new accessibility section in the explainer [LINK](https://github.com/WICG/manifest-incubations/blob/gh-pages/borderless-explainer.md#accessibility). However we want to make sure that we are not missing something and we’ll make sure to contact our accessibility experts at Google again. During the launch process there was already an internal accessibility review step which was approved.

Fullscreen Popups
We’ve brought this explainer to the attention of the Second Screen WG, but there are relatively few parallels between this IWA manifest display-mode proposal and the Window.open() `fullscreen` feature proposed in [Fullscreen Popup Windows](https://github.com/bradtriebwasser/fullscreen-popup/blob/main/EXPLAINER.md). While they share a permission and some security considerations, this application setting relies on the additional trust of Isolated Web Apps, and fullscreen popups mainly offer a new entrypoint to the transient HTML Fullscreen window state.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/852#issuecomment-1720910502
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/852/1720910502@github.com>