Standardizing `app-region` for draggable app windows

[diekus]

Hola CSS WG

The WICG has produced a draft for a proposed new feature to extend the web content to the area that would generally be utilized by the title bar, named Window Controls Overlay:
https://wicg.github.io/window-controls-overlay/

The feature consists of an extension to the navigator interface, an new value for the display_override in the manifest and a way to define draggable sections through the CSS property app-region, as seen in the appropriate section in the spec:
https://wicg.github.io/window-controls-overlay/#defining-draggable-sections

I am reaching out to you to ask for feedback and comments, and to evaluate the option (and guidance) of going forward with the standardization process for this property.

Thank you very much!

[tabatkins]

There doesn't appear to be much, if any, detail of what you're actually proposing on the CSS side; the entirety of the section is currently just "To define which regions or elements in the title bar are draggable, this specification defines the CSS app-region property."

Do you have any further details that could be shared? There's nothing for us to review right now. ^_^

[diekus]

Hola @tabatkins . Indeed, I will provide more context, sorry about that!

The CSS property already exists, as part of the "Webkit CSS extensions". Its current form is that of webkit-app-region.

There is surprisingly very little information on the css property in general, but basically what it allows is to define a an element as draggable, which means that holding down the and moving on said element (dragging) it moves the window in the UI (desktop/windowing) environment.

The spec does not mention the implementation of the CSS property since it should work the same as already existing -webkit-app-region. What would we require in order to define the app-region property as a standard? I am completely new to this and eager to learn.

-webkit-app-region: drag
-webkit-app-region: no-drag

[tabatkins]

Heh, the MDN page also doesn't do anything more than mention the existence of the property.

So first it would just involve defining what the property is - what its values are and what they mean, what they apply to, what (if anything) they do in other situations, etc. I presume from your comment that the current -webkit-prefixed version just has the values drag and no-drag? That'd be a start, yeah.

[emilio]

FWIW, as a precedent, Gecko has -moz-window-dragging: {drag, no-drag}, for similar purposes. Apparently it's exposed to the web, ugh.

[emilio]

(Not that it does anything in regular websites though)

[diekus]

Let's give this a try. The behaviour of the app-region CSS property is to allow to drag (or not) a window from the element that sets the property. Hence, if a DOM element has this property set to drag, let's say, a div for example, the user can click/tap and move the window around, but at the same time if an element inside this div has the app-region:no-drag (for instance, a textbox or other form control) no dragging can occur over it.

The property's app-region 2 possible values are: drag and no-drag.

This (through the -webkit-app-region existing property) already works as described and is used in electron. As an example, you can refer to this documentation.

What we'd like is to remove the webkit prefix and start the standardization process for app-region to be able to define regions in the window of an installed web application where the user can drag to reposition a window.

[ivansandrk]

Hey folks, polite ping, any movement here? :)

[diekus]

Polite ping here as well. (Polite ping ...squared? which means squared politeness, not squared ping).

[bfgeek]

@diekus The first step here is to explicitly try to define what the current implementations are doing - and to cover various edge cases that exist (and ensure this behaviour is actually want people want). E.g. does this property respect paint order? which properties will suppress this behaviour: visibility ? pointer-events ? What types of elements does this apply to? (e.g. inlines?) What happens when transforms/animations/etc are present?

Ian

[leaanthony]

Hey all 👋 I'm the maintainer of Wails - an electron alternative for Go. Having this standardised would be amazing for us (as I'm sure it would be for other frameworks such as Tauri) as currently we have to hack this functionality in using JavaScript. Recently, Microsoft announced that WebView2 would support app-region and sure enough it works fine, however in their implementation, right clicking on any element with app-region: drag brings up a title bar menu, which was somewhat unexpected. I reported that as a bug here however the response was that it was working as intended.

So why am I bringing this up here? Well, if you read the proposal in the initial comment, everything mentioned in it is geared around the title bar as, for sure, that's how it'll be used in the majority of use cases. However, I'd argue that app-region: drag doesn't reflect that the intent is for it to live at the top of the page as a title bar at all.
Currently, if you right click on a drag region in Electron it does show the title bar menu (at least on Windows) so you could argue that Microsoft is being consistent and drag should work this way. But I believe a far more accurate value for this behaviour would be app-region: titlebar which indicates it should work like an OS titlebar, right click menu and all.

I'll end with a couple of questions:

• With regards to the standard, should "drag" be read as "titlebar"? If so, I think it should be stated explicitly.
• Should this proposal also cover whether a "drag region" should be implemented strictly as a title bar or can we also have a value that indicates that the region should be "drag only", e.g. app-region: drag-only and shouldn't be implemented as a title bar (no titlebar menu on right click)?

Thank for your time 🙏