-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Borderless mode #852
Comments
We discussed this during our vF2F. While we see potential use cases which could benefit from this functionality, we'd like to discuss a couple things that are points of concern. First of all, this depends on a feature that no other implementation has provided any signal on - which somewhat jeapordizes its future path on the web platform. We'd probably want to hear some level of feedback from other implementors on the dependency proposal (IWA) as it is a architecturally complex topic which we should carefully approach. Even if this is gated behind a protected context of some form (IWAs?) - draggability should be a key consideration, especially the guarantees of having the user to be able to do so. The proposal as it stands does not seem to have mitigations from applications (be it malicious or not) breaking usability by making undraggable windows - and we believe that is not a positive pattern. Similar situation with the window controls. Reading the IWA explainer, we had a hard time understanding how that as a mechanism can prevent bad patterns coming from user-experience degrading applications. We are also concerned that the feature introduces a sharp cliff in terms of usability: While many use cases are as simple as adding a control to the title bar, there is no way to do this without recreating the entire title bar, windowing controls and all. It would be better to introduce a layered solution, that makes simple cases easy and complex cases possible. The drag feature being coupled to a webkit-prefix style is definitely not a recommended pattern, and unless this is a prototype/trial, having yet another feature depend on a webkit prefixed feature is a pattern we should avoid. And we would recommend you have a conversation with the Second Screen working group, who are working on Fullscreen Popup Windows. Their use case is slightly different, but it would be good if you could align your approaches and attributes. @bradtriebwasser, @michaelwasserman, @inexorabletash, and @anssiko are your main contacts for that. Finally, we see there is no discussion about the accessibility risks associated with removing the window controls from the user interface. This can have detrimental effects on the usability in the context of AT needs. P.S. A web platform explainer should not have any Googler-only links. |
Thank you for your detailed feedback. We agree that probably it makes sense to first go through the IWA review before a feature which depends on it strongly. Here’s some pointers to the feedback. Let me know if there's more concerns raised in regards to anything. IWAs Webkit-prefix Draggability Sharp cliff Accessibility Fullscreen Popups |
(Non-TAG member with a few comments)
I think the explainer/spec could be written to avoid directly depending on IWAs and instead just use a more generic idea of a "high-trust environment". Leave it unspecified but state that the user agent "MUST" only expose this in environments where the user has indicated through some unspecified mechanism a higher degree of trust in the application. This is a stop-gap measure. We really need a way, in general, of talking about "high-trust contexts" in specs which have well-understood definitions, and can therefore pave the way for user agents to introduce things like IWAs which fit that definition, without literally prescribing that the APIs need to be exposed in IWAs.
I agree, I think WCO feature provides Alan Kay's "simple things easy" whilst Borderless provides the "complex things possible" use cases. However, in line with comments I made in March on the pull request, I think that justification means that Borderless should act as an extension of WCO rather than being quite a different design. To me, that means using a similar user-opt-in mechanism (a toggle control on the border itself, which then clearly denotes how to "untoggle" it via an animation), rather than a permission prompt for something that is fundamentally not a permission, but a different UI mode. |
Hi @sonkkeli we discussed today in our TAG breakout. We don't think this should be standardized in it's current form on the web platform. We understand the use case. However there is a dependency on the idea of "trusted" applications - and this is an area that is in development - e.g. isolated webapps which we're also concerned with and is currently not stable enough for other things to be built on top of it. In any case, we are concerned with the lack of agency of the user - e.g. with dragability and accessibility issues. We're going to close this review for now. |
こんにちは TAG-さん!
I'm requesting a TAG review of borderless mode.
Currently all the possible app display and display_override modes rely on apps having at least some format of a title bar - something between the full Chrome title bar and currently most minimized window-controls-overlay (WCO). Despite WCO having some same qualities as what we are trying to achieve, it is still not offering enough flexibility for some use-cases. To enable such use-cases, this explainer will explain how the title bar will be completely removed and so-called borderless mode enabled. This way the title bar area is replaced with web content and so giving the developers full control on how the title bar would look like.
Further details:
You should also know that...
This feature will only be available for Isolated Web Apps.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify sonkkeli, dmurph
The text was updated successfully, but these errors were encountered: