I agree that carrying three different properties for the same feature long-term is not ideal! I also don’t think we should expect that either legacy spelling is safely removable at the same time we ship `window-drag`. The ChromeStatus cites non-trivial usage for both existing names: `-webkit-app-region` at 0.79% of page loads and `app-region` at 0.24% as of June 2026.
That being said, with the CSS UI 4 spec now standardizing `window-drag` as the canonical property, I think we can work towards deprecating at least one of the supported shorthands. I propose we keep the existing aliases initially for compatibility, update developer-facing documentation (Electron) to prefer `window-drag`, and track usage so we can revisit removal later. Based on today’s signals, app-region is the more plausible eventual deprecation candidate once window-drag has had time to gain adoption; -webkit-app-region looks less plausible to remove near-term because usage is higher and it represents older compatibility content (we support a lot of -webkit prefixed <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/css_properties.json5;l=1913?q=css_properties.json5>legacy properties in Chromium). I’m happy to explicitly add that follow-up plan to the ChromeStatus entry and track it as a CRBug so we’re not treating the extra names as permanent. Thank you, Alex On Thursday, June 11, 2026 at 2:45:01 PM UTC-7 Alexander Kyereboah wrote: > *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/4b897395-4611-4299-9ecf-5cb0fa822849n%40chromium.org.
