search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.5k stars 661 forks source link

Standardizing `app-region` for draggable app windows #7017

Open diekus opened 2 years ago

diekus commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

emilio commented 2 years ago

(Not that it does anything in regular websites though)

diekus commented 2 years ago

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 commented 2 years ago

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

diekus commented 2 years ago

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

bfgeek commented 2 years ago

@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 commented 1 year ago

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:

Thank for your time πŸ™

dmurph commented 3 months ago

I believe @amandabaker has resolved most of the technical implementation edge cases for a more consistent behavior. So now we just need to have this specified.

Noahs007 commented 3 months ago

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 πŸ™

hey，I have also encountered this problem, please ask if you have a good way now, about hiding the right-click menu