Define possibly inheritable behaviour for `app-region` (now `window-drag`)

[diekus]

Builds on #7017

Research 'inheritable' behaviour of `app-region to better understand use cases and if the feature should only work if the title bar is disabled.

(also update the explainer to reflect this information)

[diekus]

Following up on the discussion at TPAC for #7017, The app-region property does inherit, both the drag and no-drag values.

I've also looked at the behaviour of native apps on Windows and macOS to determine if this is functionality that should work always. It was not clear at TPAC if certain apps could be moved from the left navigation sidebar. I've looked at how apps behave on macOS, and not Finder, not Maps nor the System Settings have this UX. Windows also does not expose this functionality to move windows from the side panel.

I therefore think the behaviour should remain as-is, with the CSS property only working when the default's platform moving surface disappears.

I have updated the explainer accordingly to reflect these findings.

cc @emilio

[emilio]

FWIW I didn't mean the application sidebar, but the toolbar. E.g. the KDE system settings on Linux (and Firefox, and probably other QT apps) can be dragged by the toolbar even when using system window decorations.

Also Chromium on Linux, FWIW...

[diekus]

Thanks for the extra context. When you say "system window decorations", is it this? I don't see why modifications of the appearance of the theme of the platform would alter the behaviour of the CSS property. The default window chrome would continue to behave as expected on the platform, and if this UX surface disappears (because the developer might want to create custom UX) then the property is enabled to facilitate moving the window.

If a developer wanted to create a custom title bar/toolbar combo they could use something like WCO (if supported) to achieve this. Everything else is up to the platform. I've tried Chrome on ChromeOS (closest I have atm to Chromium on Linux :P) and don't get the behaviour, but Firefox on Windows I do get dragging from the custom title/tool bar. Nonetheless, this would also be done via WCO, as it is not the default's OS UX.

Now if I understand correctly if I wanted an installed web app to try to achieve the same UX that Firefox has, I need WCO, which enables app-region.

I can do a web app that looks like the previous screenshot, but I need WCO + app-region for that.

Unless I am missing something?

[emilio]

@diekus I mean checking the Titlebar checkbox in here which uses the system controls.

[emilio]

(But that doesn't work on Windows, apparently, it's a Linux and macOS thing)

[diekus]

Ok, so agree, and to do this type of UX in a web app you need WCO enabled.

Windows, macOS, even KDE with plasma 's default UX to move a window is a title bar.

If you wanted to create more complex UX with title bars/side panels/toolbars or different controls on the title bar area (like modern apps on Windows, macOS or Firefox's UX) you need WCO.

right?

[diekus]

even with the title bar checked and visible, a web developer could recreate this UX with WCO and the draggable CSS property to achieve the behaviour you mention.

so I might be missing something, but also the default for platforms seems to be title bar for moving the window, and everything else is custom/not the default, hence why I am not convinced the property should work with the default platform's UX.

[emilio]

No, sorry, I think we're talking past each other. Let me upload a screen recording of what I mean:

Screencast_20251124_221505.webm

You can see how, even with the native decorations, I can drag the application from it's toolbar.

[diekus]

I see now. Interesting. I'm not opposed to having the feature work when web apps are in standalone windowed mode. I still lean towards keeping the behaviour triggered when the default moving window UX goes away.

The reason is that both cases that you depict in the screencast can already be replicated if the developer wanted by enabling a feature like WCO. Furthermore, keeping it as-is maximizes behaviour compatibility between platforms.

I also notice that the use cases of this working are in highly specialised apps like a browser. This is rather different from the default app (macOS, Windows, ChromeOS, native or not) and I'd like to see more use cases of regular apps that exhibit this behaviour to justify making this the default.

Does this make sense?

[emilio]

@diekus the same is true of less special apps like "settings" or a bunch of other native KDE applications at least. Gnome doesn't have non-native decorations. I'd have to check on an Apple machine to see what the state is there.

The reason is that both cases that you depict in the screencast can already be replicated if the developer wanted by enabling a feature like WCO. Furthermore, keeping it as-is maximizes behaviour compatibility between platforms.

Not quite right? If you do want the system titlebar, you might not be able to replicate it with wCO.

[diekus]

The 2 examples of Firefox and Chromium using the system title bar could be replicated very easily with WCO. From what I see in the screen recording, the "system title bar" consists of an icon, the app name and the window controls. This is reproduceable with WCO. Even if the intention was to create a "system"-like custom-background-colored title bar (let's say, with a hot neon pink), this would be very easy with WCO and it'd be the way to go.

I checked on macOS and there doesn't seem to be the case of the dual title bar/toolbar. Most native apps already combine both concepts and allow to draw from what would be the top title bar area.

In the end it could be an vendor implementation decision. I am not convinced that having the property enabled by default would be particularly beneficial for developers. I am not convinced it'd be particularly detrimental either.

Since this property is used jointly with WCO for more advanced UX scenarios in most apps (creation of custom title bar UX or removing the title bar altogether but still having a draggable area (like this app) I would lean to keep it for when a developer knows what they are doing and why (hence would need to trigger it by removing the default platform's UX surface). Specially since elements with this property become like a black hole that just absorbs all pointer events.

[emilio]

Well, my system titlebar is very simple, but those allow a lot of customization that is not always reasonable for an application to do client-side, see this for example.

[diekus]

I think it makes sense and I don't see this changing the current behaviour. Went through some cases where WCO is already used and I don't think it'd create an issue. @emilio let's make it work in a standalone window instead of only when the default UX disappears.