On the web you can make videos and pages and apps fullscreen. But there is no way to just remove the upper tab bar and navigation controls, and leave the OS UI in place. Just like the fullscreen API, a fulltab api is also needed.
What do I mean by fulltab? Remove the tab and make a border-less window with just OS UI and none of browser UI. Some apps are better suited to their own UI. Since we allow full screen, why not have this capability too?
window.open() allows you to open a window without most browser UI (the location/address bar still appears by default in major browsers):
window.open("https://mozilla.org/", "_blank", "toolbar=no,close=no");
And Progressive Web Apps on the Desktop render apps without any browser UI. Do either of these features satisfy your use case?
No on desktop PWA’s they don’t satisfy the use case, because there is still a window bar. We cannot customize the minimize, close or other buttons on that or even hide it and use that space ourselves to implement custom buttons.
window.open also has the window bar at top, as well as a url bar, and its intended usage is different. Even PWA’s on desktop (Chrome) have the bar at top, which can be removed in fullscreen mode, but than it removes the OS UI as well. What this is about is borderless window.
For a better understanding, compare Steam Desktop or Photoshop vs regular programs. Here is an image for difference:
If we have fulltab api access https://i.ytimg.com/vi/k8GPb6y11KY/maxresdefault.jpg
If we dont https://i.ytimg.com/vi/28W2Dya1-2A/maxresdefault.jpg
Notice the window bar at top. We want to get rid of that because it takes up the screen estate even though it serves no purpose for our usecase. More precisely a border less window is what we are looking for instead of complete fullscreen.
A PWA does solve the expected requirement. You’d make a Web App Manifest and within that define that you want a standalone experience using the display property.
The issue with removing the OS border (which wasn’t clear in the initial post where you requested just the OS UI left in place, that is what the titlebar is) is that if users want to minimize or maximize/shrink the window they wouldn’t really have a clear way of doing it visually. The web doesn’t provide APIs to do that like window.close() to let users close a window out.
A site author also shouldn’t be making this decision for users generally. Could you please provide a use-case for why you want to have this much control over the window UX of a web app?
For our use case, it is because we have tabbed controls similar to ms word which we want to dock on top. The os window makes it ugly.
For minimize and maximize api, yeah maybe we should also have them too. But first priority for us is to be able to hide the window bar. We’re shipping in 3 months. Please make it happen wicg!
Perhaps there could be an option to only have part of the frame which includes the window controls.
Nothing is happening in that time frame. If this is too move forward their needs to be a good look at the implications of allowing the OS Titlebar to be removed and how to handle that.
You should just ship knowing the bar is going to be there and do the best you can.
Perhaps there could be an option to only have part of the frame which includes the window controls.
This is perfect. Just allow us to control the background texture of the buttons in addition to that.
There are zero implications. I’ve been making native windows software for years with borderless window, and custom minimize/maximize/close buttons. There is no security concern regarding that, nor does it make phishing any more easier. The level of control in this is already less than request fullscreen API, and this should only be possible when the WebAPK or WebAPP in installed.
Anyways, right now we’ll hack around with the fullscreen API but 3 months is enough to ship this behind a Chrome flag.
I’ll edit the specification to explain the behavior in more clarity and consider the implications of that in the modified document.
