I'm somewhat concerned about the precedent that window drag replaces the
normal event processing. In particular,
1. What does that mean? Does the page see any events targeted over a window
drag region? Or does it only take over after a click and drag? If so, what
events does the page see such that it doesn't look like a held pointer? Do
we send over/enter/move and then stop before sending the down or do we send
the down as well? If we send the down what do we send after the drag starts
to ensure the event stream doesn't look like the pointer is still down?
2. How would developers recreate something like the chrome UI - the natural
way to write the HTML would be something like
<div id=header style="window-drag: move">
<div id=window-controls><button aria-label="Close"></button>...</div>
<div id=tabstrip>
<div class=tab draggable=true>
<div class=tab draggable=true>
<div class=tab draggable=true>
</div>
</div>
Will the developer have to set window-drag: none over each UI element that
has some other interactions? Can they still handle clicks on the draggable
header area? What events would they see when a click happens? Right clicks?
It seems to me that draggable at least should take precedence over window
dragging, maybe the UA should have a default style rule [draggable] {
window-drag: none } so that unless something inside the draggable was
window-draggable it does the drag action.
On Fri, Jun 26, 2026 at 9:46 PM 'Alexander Kyereboah' via blink-dev <
[email protected]> wrote:
> One shape that I could think of would be to have separate gesture
> observation and default drag behavior, with a single property that
> determines what an unprevented drag gesture does.
> For example, pointer events would get a chance to observe or cancel a
> given gesture, and then a single "default drag action" property could
> select among behaviors such as window movement (window-drag),
> drag-and-drop, text selection, panning/scrolling, ink/writing, etc. The
> individual features would contribute values within that property's
> framework rather than defining their own precedence rules.
> I'm not sure we'd want or be able to retrofit all existing features into
> such a model, but conceptually it seems cleaner than having multiple specs
> independently establish ordering for overlapping drag behaviors.
> For window-drag specifically, the CSS UI spec already defines it as
> replacing normal event processing for the gesture rather than participating
> in it, which kind of feels directionally aligned with a future "default
> drag action" abstraction if the platform ever converges on one.
> On Wednesday, June 24, 2026 at 8:54:17 AM UTC-7 [email protected] wrote:
>
>> 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/e9cf8849-fa7c-49a7-9e13-fea8e861e99dn%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e9cf8849-fa7c-49a7-9e13-fea8e861e99dn%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/CAJh39TN0RJ2NWBHS0mFDQKOOcg5h_s8fuDSUb5%3Da09pZ7fYp4A%40mail.gmail.com.
