Ok thanks Alex, that sounds like an OK compromise to me. LGTM2 On Wed, Jun 17, 2026 at 2:41 PM 'Alexander Kyereboah' via blink-dev < [email protected]> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4b897395-4611-4299-9ecf-5cb0fa822849n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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/CAFUtAY9PEZdOa45taioyv9bFg3yAQR_V_-Gwq5zK%3DWRE%2BWmqLA%40mail.gmail.com.
