*Contact emails* [email protected] *Specification* https://drafts.csswg.org/css-ui-4/#window-drag
*Summary* The `window-drag` CSS property allows web content to designate regions of an installed desktop web app’s UI that should behave as draggable window titlebar areas. When applied, user pointer interactions (e.g., click-and-drag) on that region move the top-level application window rather than triggering normal page interaction. This is primarily used by desktop PWAs or apps using features like Window Controls Overlay to implement custom title bars and draggable areas when the browser-provided title bar is hidden. This feature standardizes and renames the existing `app-region` CSS property, changes its value names to `move` and `none`, and adds explicit inheritance behavior. This property is used by installed web apps and Electron-based applications for the same purpose. *Blink component* Blink>CSS <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> *Web Feature ID* Missing feature (Feature request <https://github.com/web-platform-dx/web-features/issues/3948>) *Motivation* The CSS Working Group resolved to standardize the property under the name `window-drag` to better reflect its behavior. This feature adds support for the standardized `window-drag `property as a new CSS property in Chromium. Chromium is not deprecating or removing `app-region` or `-webkit-app-region`. Both legacy properties will remain fully supported. Internally, `app-region` is implemented as a surrogate that maps to `window-drag`, making this an additive change with no migration burden on existing content. Supporting the standardized name aligns Chromium with the CSSWG resolution while keeping the cost and risk minimal. *Initial public proposal* Standardizing `app-region` for draggable app windows · Issue #7017 · w3c/csswg-drafts <https://github.com/w3c/csswg-drafts/issues/7017> *Search tags* WCO <https://chromestatus.com/features#tags:WCO>, app-region <https://chromestatus.com/features#tags:app-region>, window-drag <https://chromestatus.com/features#tags:window-drag> *TAG review* *No information provided* *TAG review status* Not applicable *Risks* *Interoperability and Compatibility* Historically, this feature evolved entirely within Chromium prior to standardization. The original prefixed property, `-webkit-app-region`, shipped as part of Window Controls Overlay, and was later unprefixed to `app-region` and shipped broadly before any formal CSS Working Group specification work. Feedback from other browser vendors and CSSWG participants on the naming and generality of the property only emerged after shipping, at which point concerns were raised that `app-region` was unintuitively named. In response, the CSS Working Group resolved to standardize the behavior under the clearer name `window-drag`, while retaining the already-shipped properties for compatibility. Renaming `app-region` to `window-drag` carries some interoperability risk because the feature is currently only implemented in Chromium, and other engines do not yet support either the legacy or renamed property. In the near term, this means the rename will not immediately improve cross-browser compatibility. However, this risk is moderated by the CSSWG resolution to standardize on `window-drag` and the existence of corresponding spec text in CSS UI Level 4, which places the platform on a clearer path toward eventual interoperability while preserving backward compatibility with existing content. *Gecko*: Positive ( https://github.com/mozilla/standards-positions/issues/1409) *WebKit*: No signal ( https://github.com/WebKit/standards-positions/issues/668) *Web developers*: Positive (https://issues.chromium.org/issues/40616128) Attached original tracking bug for WCO with 45+ upvotes from the community. `app-region` and `window-drag` are explicitly tied to WCO functionality in Chromium. *Other signals*: *Ergonomics* The ergonomics impact of this change is expected to be low. The property is primarily used in installed web app scenarios, often in conjunction with APIs like Window Controls Overlay, where `app-region` and `-webkit-app-region` are already established patterns. Renaming to `window-drag` improves clarity and alignment with CSS naming conventions without changing the underlying usage model. Chromium will continue to support existing `app-region` usage as a legacy alias, ensuring that current content continues to function while developers gradually migrate to the standardized name, reducing the risk of breakage or developer friction. This change also introduces explicit inheritance on the `window-drag`, `app-region`, and `-webkit-app-region` keywords. There would be a potential additive change in behavior for child elements that overflow out of a draggable parent container, now becoming draggable as well. However, Chromium `app-region` has no effect if WCO is not enabled, and WCO is only present in .13% of page loads as of June 2026. A further subset of this would be developers using `app-region` in conjunction with WCO. Taking into account this data and the specificity of the edge case, the actual risk is very low. *Activation* There are no significant activation risks associated with this change. The rename from `app-region` to `window-drag` does not introduce new functionality or require additional permissions, and continues to operate within the same installed web app contexts (alongside Window Controls Overlay). Existing usage patterns remain unchanged. *Security* This change does not introduce new security risks. The `window-drag` property provides the same behavior as `app-region`, which is limited to defining draggable regions in installed web app windows and does not expose new capabilities or access to sensitive data. As the rename is purely a syntactic and standardization change, it does not expand the attack surface. *WebView application risks* Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No *Debuggability* `window-drag` will be exposed as a CSS property at the same capacity as `app-region`, viewable through DevTools when examining the CSS. *Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* Yes *Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* Yes Manual WPT: https://github.com/web-platform-tests/wpt/blob/master/appmanifest/display-override-member/display-override-member-window-drag-window-controls-overlay-manual.tentative.html Chromium side, we have an internal web test confirming support for all 3 properties: `-webkit-app-region`, `app-region`, and `window-drag`. This test is not surfaced as a WPT since `window-drag` is the only standardized property, but we support the legacy surrogate in Chromium. Internal web tests: https://chromium-review.googlesource.com/c/chromium/src/+/7858427/5/third_party/blink/web_tests/fast/css/window-drag-app-region-surrogate.html *Flag name on about://flags* *No information provided* *Finch feature name* CSSWindowDrag *Rollout plan* Will ship enabled for all users *Requires code in //chrome?* False *Tracking bug* https://issues.chromium.org/issues/477608113 *Availability expectation* Feature is fully supported in Chromium browsers on launch. With standardization in the css-ui-4 spec, the chances that other vendors will adopt this are higher. *Adoption expectation* Feature is considered a best practice for custom window interactions within 12 months of reaching Web Platform baseline. *Adoption plan* The adoption plan is to update references from `app-region` to `window-drag` across relevant specifications and developer-facing documentation, including the Window Controls Overlay spec and platform-specific guidance such as Electron’s custom window interaction docs. Chromium will continue to support `app-region` as a legacy alias during the transition to enable gradual migration without breaking existing content. MDN Document Request being tracked at https://issuetracker.google.com/issues/514738005 *Non-OSS dependencies* Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function? None. *Estimated milestones* Shipping on desktop 151 *Anticipated spec changes* Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way). None expected. *Link to entry on the Chrome Platform Status* https://chromestatus.com/feature/5201338641285120?gate=5822390643851264 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ba01357-ddd6-4eb8-b361-f78425484654n%40chromium.org.
