We now have, for dragging actions, roughly in this order: window-drag = unpreventable unobservable window drags draggable = default drag action will initiate drag and drop, but developer can preventDefault text selection (controlled by user-select) And we want to let developers specify whether pointer drags should be treated as writing or scrolling, or whether mouse drags should scroll <https://github.com/w3c/pointerevents/issues/512>.
Do you think there's a compatible future API shape where a single source property determines the default action for a drag that wasn't prevented, without different specs competing on the order of handling for the same interaction? On Wed, Jun 24, 2026 at 11:12 AM Vladimir Levin <[email protected]> wrote: > LGTM3 > > On Wednesday, June 24, 2026 at 11:12:26 AM UTC-4 Rick Byers wrote: > >> 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/1e3ac757-c941-4df0-aef8-217ba5aff10dn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1e3ac757-c941-4df0-aef8-217ba5aff10dn%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/CAJh39TOnvkQJafFzjcHGP55%3DHxDtP%2B5Ypxuy5TB7uEWr-Tobng%40mail.gmail.com.
