Re: [w3c/manifest] DisplayModeType Borderless (#684)

There are heaps of other edge cases to consider here.

- What if the operating system doesn't put the 3 buttons on the top-left or top-right?
- What if the operating system uses that title-bar space for other business? We do on Chrome OS, in various ways: we show the origin during window-open (that is a security requirement). We show permission icons (also a security requirement), which can display arbitrarily many icons. We show extension icons.
  - Because a lot of these are security requirements, we'll be very afraid to let the app draw into the title bar space, because then it would allow the app to spoof those security features.
- What if the operating system doesn't have a concept of a title bar at all? Mobile OSes satisfy this, as to tiling window managers on Linux.
- What if the operating system doesn't give us access to draw into the top bar space at all? e.g., Linux (though on Linux we'll probably have to draw an entirely custom title bar, due to this).
- What if the user agent wants to add more UI into the title bar in a future version (e.g., we are considering adding a "Back" button to the top-left in Chrome).

Arguably, the answer to many of these is that "display: borderless" is a best-effort thing. If the host platform supports overdraw into the title bar, then we let the application overdraw, otherwise we don't, and the application just has to sort it out. If we do allow it, we then need APIs to communicate exactly which rectangles of the title bar are available for overdraw, which can change dynamically (e.g., as the "Back" button pops in and out). And then developers need to test against many different platforms, including those that do and do not allow overdraw.

> And at last an api for dragging could be introduced to dom element ia in app that can make window drag able. This could only work when app is installed to prevent abuse on webpages.

That's a huge amount of complexity with lots of edge cases. We lived through this with Chrome Apps where we (for some reason) encouraged developers to create a borderless window and provide their own title bar UI, using a dragging API. We are explicitly afraid of the complexity in the window-dragging space. Again, more territory for developers to mess up and create a broken experience on some platforms.

This is potentially doable (and will be something that apps can really take advantage of), but introduces massive complexity (for user agents and developers), compat issues (if developers do a poor job of testing, for example drawing over parts that are free in Windows but not macOS, making for a bad user experience on other platforms and boxing us into a corner with regards to future UI changes) and potential security risks (due to our use of the title bar for spoofing).

This may be something we try to tackle some day, but it's certainly not trivial, and not something I think we want to look at any time soon (with heaps more pressing issues to deal with).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/684#issuecomment-396826117