Breaking Out of the Box

CSS is all about styling containers. In fact, the whole website is made of containers, from the website viewport to components on a webpage. However, every now and then a new function appears that prompts us to reevaluate our design philosophy.

Square features, for instance, make it fun to play with round picture areas. Mobile screen notches and electronic keyboards present difficulties in how to best manage content that stays out of sight. And two display or portable devices make us reassess how to best utilize available space in a number of various device postures.

These new evolutions of the internet system made it both more demanding and more exciting to design products. They give us a fantastic opportunity to leave our triangular containers.

I’d like to talk about a new feature similar to the above: the Window Controls Overlay for Progressive Web Apps ( PWAs ).

Liberal Web Apps are bridging the gap between websites and apps. They combine the best of both worlds. On the one hand, they are flexible, linkable, and stable, just like websites. On the other hand, they provide more effective features, work online, and read documents just like local apps.

PWAs are really exciting as a style area because they challenge us to consider how blending online and device-native customer interfaces may be. On desktop products in certain, we have more than 40 years of history telling us what software may look like, and it can be hard to break out of this mental concept.

PWAs on pc are ultimately limited to the top of a square with a name club.

Here’s what a standard desktop PWA app looks like:

Sure, as the author of a PWA, you get to choose the color of the title bar (using the Web Application Manifest theme_color home ), but that’s about it.

What if we could assume differently and regain the full glass of the app? Doing so would give us a chance to create our applications more wonderful and feel more included in the operating system.

This is exactly what the Window Controls Overlay provides. This innovative PWA operation makes it possible to take advantage of the full floor area of the app, including where the name bar usually appears.

About the glass and title bar settings

Let’s begin with an explanation of what the title bar and glass controls are.

The name club, which typically contains the phone’s name, appears at the top of an game glass. Window settings are the affordances, or buttons, that make it possible to decrease, increase, or near the app’s windows, and are also displayed at the top.

Window Controls Overlay removes the physical constraint of the title bar and window controls areas. The title bar and window control buttons can be overlayed on top of the application’s web content, allowing it to free up the entire height of the app window.

If you are reading this article on a desktop computer, take a quick look at other apps. They’re probably already doing something similar. In fact, the very web browser you are using to read this uses the top area to display tabs.

Spotify displays album artwork all the way to the top edge of the application window.

Microsoft Word uses the available title bar space to display the auto-save and search functionalities, and more.

The goal of this feature is to give you the ability to use this space with your own content while also providing a way to account for the window control buttons. And it enables you to offer this modified experience on a range of platforms while not adversely affecting the experience on browsers or devices that don’t support Window Controls Overlay. PWAs are all about progressive enhancement, so this feature offers a chance to make the most of this additional space available.

Let’s use the feature

We’ll be working on a demo app for the remainder of this article to learn more about how to use the feature.

The demo app is called 1DIV. Users can create designs using only CSS and a single HTML element in this straightforward CSS playground.

The app has two pages. The first lists your existing CSS designs:

The second page enables the creation and editing of CSS designs:

Since I’ve added a simple web manifest and service worker, we can install the app as a PWA on desktop. What it appears to be on macOS is shown below:

And on Windows:

Our app looks good, but the first page’s white title bar is a waste of space. In the second page, it would be really nice if the design area went all the way to the top of the app window.

To enhance this, let’s use the Window Controls Overlay feature.

Enabling Window Controls Overlay

The film is still in its experimental phase right now. To try it, you need to enable it in one of the supported browsers.

It has currently been incorporated into Chromium as a result of a collaboration between Microsoft and Google. We can therefore use it in Chrome or Edge by going to the internal about: //flags page, and enabling the Desktop PWA Window Controls Overlay flag.

Using the overlay of Window Controls

To use the feature, we need to add the following display_override member to our web app’s manifest file:

{ "name": "1DIV", "description": "1DIV is a mini CSS playground", "lang": "en-US", "start_url": "/", "theme_color": "#ffffff", "background_color": "#ffffff", "display_override": [ "window-controls-overlay" ], "icons": [ ... ]}

On the surface, the feature is incredibly simple to use. This manifest change is the only thing we need to make the title bar disappear and turn the window controls into an overlay.

We’ll need a little bit of CSS and JavaScript code to make the most of the title bar area in our design and provide a great experience for all users regardless of device or browser they use.

Here is what the app looks like now:

Our logo, search field, and NEW button are now partially covered by the window controls, but the title bar has been removed, which is what we wanted.

It’s similar on Windows, with the difference that the close, maximize, and minimize buttons appear on the right side, grouped together with the PWA control buttons:

Screenshot of the Windows operating system’s Window Controls Overlay-enabled 1DIV app thumbnail display. The separate top bar area is gone, but the window controls are now blocking some of the app’s content.

CSS to avoid window controls

Along with the feature, new CSS environment variables have been introduced:

titlebar-area-x
titlebar-area-y
titlebar-area-width
titlebar-area-height

You can position your content where the title bar would have been by using these variables with the CSS env function to prevent it from overlapping with the window controls. In our case, we’ll use two of the variables to position our header, which contains the logo, search bar, and NEW button.

header { position: absolute; left: env(titlebar-area-x, 0); width: env(titlebar-area-width, 100%); height: var(--toolbar-height);}

The titlebar-area-x variable gives us the distance from the left of the viewport to where the title bar would appear, and titlebar-area-width is its width. (Remember, this is not equivalent to the width of the entire viewport, just the title bar portion, which as noted earlier, doesn’t include the window controls.)

By doing this, we make sure our content remains fully visible. We’re also defining fallback values (the second parameter in the env() function) for when the variables are not defined (such as on non-supporting browsers, or when the Windows Control Overlay feature is disabled).

Our header now adapts to its surroundings, and it doesn’t seem like the window control buttons were left out. The app looks a lot more like a native app.

Changing the window controls the background color so that it blends in

Now let’s take a closer look at our second page: the CSS playground editor.

Not very good. Our CSS demo area does go all the way to the top, which is what we wanted, but the way the window controls appear as white rectangles on top of it is quite jarring.

We can remedy this by altering the app’s theme color. There are a couple of ways to define it:

Websites can use the theme-color meta tag as well. It’s used by browsers to customize the color of the UI around the web page. For PWAs, this color can override the manifest theme_color.

In our case, we can set the manifest theme_color to white to provide the right default color for our app. The OS will read this color value when the app is installed and use it to make the window controls background color white. This color works great for our main page with the list of demos.

The theme-color meta tag can be changed at runtime, using JavaScript. So we can do that to override the white with the right demo background color when one is opened.

Here is the function we’ll use:

function themeWindow(bgColor) { document.querySelector("meta[name=theme-color]").setAttribute('content', bgColor);}

With this in place, we can envision how using color and CSS transitions can smooth transition from the list page to the demo page and make the window control buttons blend in with the rest of the app’s interface.

Dragging the window

Now, getting rid of the title bar entirely does have an important accessibility consequence: it’s much more difficult to move the application window around.

Users can use the Window Controls Overlay feature to move the window, but this area becomes limited to where the control buttons are, and they must very precisely aim between these buttons to move the window. However, the title bar offers a sizable area for users to click and drag.

Fortunately, this can be fixed using CSS with the app-region property. This property is, for now, only supported in Chromium-based browsers and needs the -webkit- vendor prefix.

To make any element of the app become a dragging target for the window, we can use the following:

-webkit-app-region: drag;

Additionally, it is possible to expressly make an element non-draggable:

-webkit-app-region: no-drag;

These options can be useful for us. We can make the entire header a dragging target while also making the NEW button and search field non-draggable so they can still be used as normal.

However, because the editor page doesn’t display the header, users wouldn’t be able to drag the window while editing code. Let’s take a different strategy, then. We’ll create another element before our header, also absolutely positioned, and dedicated to dragging the window.

...

.drag { position: absolute; top: 0; width: 100%; height: env(titlebar-area-height, 0); -webkit-app-region: drag;}

With the above code, we’re making the draggable area span the entire viewport width, and using the titlebar-area-height variable to make it as tall as what the title bar would have been. This way, our draggable area is aligned with the window control buttons as shown below.

And now to make sure our search field and button are usable:

header .search,header .new { -webkit-app-region: no-drag;}

With the above code, users can click and drag where the title bar used to be. Users are expecting to be able to move windows on their desktops, and we are not breaking this expectation, which is good.

Adapting to window resizing

It may be useful for an app to know both whether the window controls overlay is visible and when its size changes. The search field, logo, and button would need to be pushed down a little bit if the user made the window very narrow.

The Window Controls Overlay feature comes with a JavaScript API we can use to do this: navigator.windowControlsOverlay.

The API offers three intriguing features:

navigator.windowControlsOverlay.visiblelets us know whether the overlay is visible.
navigator.windowControlsOverlay.getBoundingClientRect()lets us know where the title bar’s area is located and how big it is.
navigator.windowControlsOverlay.ongeometrychangelets us know when the size or visibility changes.

Use this to check the size of the title bar area and lower the header if necessary.

if (navigator.windowControlsOverlay) { navigator.windowControlsOverlay.addEventListener('geometrychange', () => { const { width } = navigator.windowControlsOverlay.getBoundingClientRect(); document.body.classList.toggle('narrow', width < 250); });}

In the example above, we set the narrow class on the body of the app if the title bar area is narrower than 250px. We could do something similar with a media query, but using the windowControlsOverlay API has two advantages for our use case:

It’s only fired when the feature is supported and used, we don’t want to adapt the design otherwise.
We can see the title bar area across different operating systems, which is great because the window controls ‘ size is different on Mac and Windows. Using a media query wouldn’t make it possible for us to know exactly how much space remains.

.narrow header { top: env(titlebar-area-height, 0); left: 0; width: 100%;}

When the window is too small, we can use the above CSS code to move our header down and the thumbnails down in accordance with this.

Thirty pixel of creative pixie dust

Using the Window Controls Overlay feature, we were able to take our simple demo app and turn it into something that feels so much more integrated on desktop devices. Something that transcends the typical window restrictions and offers a user with a unique experience.

In reality, this feature only gives us about 30 pixels of extra room and comes with challenges on how to deal with the window controls. However, these additional space and those difficulties can be used to create creative challenges.

More devices of all shapes and forms get invented all the time, and the web keeps on evolving to adapt to them. To make it easier for us web authors to integrate more and more fully with those devices, new features are added to the web platform. From watches or foldable devices to desktop computers, we need to evolve our design approach for the web. We can now think beyond the rectangular box when building for the web.

So let’s embrace this. Use the common technologies at our disposal and experiment with new concepts to create personalized experiences for all devices, all using a single codebase!

If you get a chance to try the Window Controls Overlay feature and have feedback about it, you can open issues on the spec’s repository. You can help make this feature even better because it’s still in its early stages of development. Or, you can take a look at the feature’s existing documentation, or this demo app and its source code.