- From: cynthia <notifications@github.com>
- Date: Thu, 03 Aug 2023 02:17:03 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/852/1663603667@github.com>
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](https://www.w3.org/TR/design-principles/#high-level-low-level) 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](https://www.w3.org/TR/design-principles/#simplicity:~:text=As%20Alan%20Kay%20said%2C%20%22simple%20things%20should%20be%20simple%2C%20complex%20things%20should%20be%20possible.%22. 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](https://github.com/w3ctag/design-reviews/issues/840). 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. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/852#issuecomment-1663603667 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/852/1663603667@github.com>
Received on Thursday, 3 August 2023 09:17:08 UTC