You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During TPAC several of us agreed that the name app-region is not meaningful. This CSS property is used to define an area from where the user can point and drag a window in a desktop environment. The name draggable should be avoided to circumvent confusing with the global draggable attribute in HTML.
Starting to bikeshed on a new name for app-region:
Though not mentioned in the spec, the existing implementation (at least in Edge) extends not only the draggable nature of the titlebar to this element, but also other native titlebar behaviors like the default contents of the right-click menu. It seems like this is desirable, as the intended use is to replace the titlebar, so the user agent choosing to adopt other titlebar-like behaviors would be a good thing.
Given that, what about a CSS property like titlebar-area?
Alternatively (if there is strong pushback on the above direction):
If keeping this to only dragging the window, and controllable via CSS, @emilio's window-drag seems like the right direction. Maybe window-dragging?
If keeping this to only dragging the window, but potentially not as a CSS property, what about expanding the draggable HTML property to include a new with-window value. Similar to contenteditable having true/false/plaintext-only options.
I hadn't notice that the context menu still works! I like the window-drag proposal @emilio mentioned above. I think there might be reasons where a developer might want to allow dragging from other areas that are not the top of the window. (side panels, other navigation areas, etc).
@mhochk Nonetheless it'd mean in Edge we'd want to remove this context menu as it's weird that that UX appears on untrusted area if you think about it?
I chatted with @diekus a bit on this and now agree that CSS (not HTML) is the right place for this to live so that this can be cleanly controlled inside a CSS media query. As such, I withdraw my suggestion to extend draggable.
As for naming based on 'replaces the titlebar' vs 'drags the window', I still don't have a strong opinion, but now lean slightly towards 'drags the window'. Diego raised that modern apps, particularly on Mac, are using traditional-looking titlebars less. Likely because of this, the developer-facing native APIs for making a region that drags the window are moving to be less tied to the titlebar (though they are still very tied to it currently).
All that said, tossing out a few different ideas in case any feel particularly appropriate or inspire anyone else to come up with a perfect idea:
New year's update and ping! We're proposing the name window-drag, I'll be Agenda+ing this to get a resolution on name and hopefully behaviour as defined in #13101
The CSS Working Group just discussed New name for `app-region` property?, and agreed to the following:
RESOLVED: rename to window-drag:none|move
The full IRC log of that discussion
<TabAtkins> diekus: I think next two item sin agenda are related. start with app-region name
<TabAtkins> diekus: we have convo at TPAC. as reminder, app-region property sets an element to being the drag target for a window, in a standalone app page
<TabAtkins> diekus: two issues came out of the meeting in tpac
<TabAtkins> diekus: first, as Tim pointed out, app-region isn't very descriptive
<TabAtkins> diekus: we started an issue to look for new names
<TabAtkins> diekus: I think there's a vibe to window-drag
<fantasai> +1
<fantasai> much clearer
<TabAtkins> diekus: so if people are okay with that, great, or if people have other ideas to discuss
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask about values
<TabAtkins> fantasai: window-drag sounds way clearer, +1. what are the proposed values?
<TabAtkins> diekus: drag | nodrag
<smfr> q+
<TabAtkins> astearns: we don't usually repeat part of the property name in the values
<dbaron> TabAtkins: border-collapse: collapse
<TabAtkins> TabAtkins: not true, we have several properties that do so. border-collapse:collapse
<bramus> `nowrap` is another one
<dbaron> smfr: background-repeat: no-repeat
<astearns> ack smfr
<TabAtkins> smfr: background-repeat:repeat
<tantek> box-sizing is another example of such naming with content-box and border-box
<TabAtkins> smfr: is this doing anything on platforms that don't have a window dragging concept? like on mobile
<fantasai> I like the suggestion in the issue for `none | move`
<TabAtkins> diekus: I think it's scoped to the idea of desktop paradigm
<TabAtkins> diekus: if you have an app that can behave like a desktop environment, it might work there. but it woudln't do anything in an environment where you don't move the frame of a window, like on phones
<astearns> ack fantasai
<TabAtkins> fantasai: on value naming, there was a none|move suggestion, think that's reasonable
<fantasai> window-drag: none | move
<TabAtkins> (I do like avoiding the ugly "nofoo" pattern we've shackled ourselves to)
<TabAtkins> astearns: Kevin had another suggestion, is that okay?
<lwarlow> +1 to none and move
<TabAtkins> kbabbitt: I'm happy with window-drag:none|move
<TabAtkins> smfr: is this applied on an element basis?
<TabAtkins> diekus: yes, but that's related to next issue
<TabAtkins> smfr: I feel like at some point we'll want clip-region, etc...
<TabAtkins> diekus: oh, no, if you put this on something round it'll be a round target. the pretend rectangle corners won't be drag handles
<TabAtkins> smfr: okay, so it follows border-shape and respects clip-path? normal hit-testing rules.
<TabAtkins> diekus: correct
<TabAtkins> astearns: proposed resolution: rename to window-drag:none|move
<lwarlow> +1
<TabAtkins> +1
<TabAtkins> RESOLVED: rename to window-drag:none|move
The CSS Working Group just discussed New name for `app-region` property?, and agreed to the following:
RESOLVED: add a note to the spec mentioning that 'app-region' might be a supported alias for the feature
The full IRC log of that discussion
<fantasai> kyerebo: Wanted to revisit the renaming issue wrto compat
<emilio> q+
<fantasai> kyerebo: We wanted to rename the property, but we're showing .26% of page loads using 'app-region' and .8% are using '-webkit-app-region'
<ntim> See https://github.com//issues/13102#issuecomment-4158686161
<fantasai> kyerebo: considering the standardized advice for electron, is it worth the web compatibility risk to rename this
<astearns> ack emilio
<fantasai> emilio: On what percentage of page loads, does that property have an actual effect?
<fantasai> emilio: This is maybe electron and maybe installed web-apps, right?
<fantasai> emilio: This seems like a much smaller blast radius
<TabAtkins> And Electron is locked on a particular chromium rev, right?
<fantasai> kyerebo: I did an http archive query, there were a lot of templates using it
<fantasai> kyerebo: It goes to show that it's not a non-trival amount of usage
<fantasai> kyerebo: Developers using WCO would need to make changes or deal with breaking websites.
<fantasai> emilio: My point is, all those things, they're just not doing anything. Is there a counter that actually counts when that property has an actual effect?
<fantasai> emilio: That's much more interesting than how often is this property in a stylesheet
<astearns> q?
<fantasai> iank_: The use counters for standard web won't have an effect.
<ntim> like how many times a window has been dragged from that property
<TabAtkins> (what is WCO?)
<fantasai> iank_: A lot of sites will use the same HTML/CSS for their electron app, which we don't have insight into
<fantasai> emilio: Then other quesiton is can you alias the property so 'app-region' is an alias for 'window-drag'
<fantasai> kyerebo: It's already alias of '-webkit-app-region'. But the values are different.
<fantasai> emilio: There's precedent for that. For example page-break.
<fantasai> emilio: Should be pretty doable.
<fantasai> kyerebo: Question here is, if this is already implemented and used by web developers already, is it worth the breaking changes with the increased amount of clarity
<fantasai> kyerebo: Especially since not a lot of data
<fantasai> emilio: Both of those things are fixable. if you alias the property, there's no breakage. And getting data seems generally doable. Maybe harder for electron, but electron could do their own thing if they need to.
<astearns> ack fantasai
<TabAtkins> fantasai: The usage on this is not very high and it's not very critical feature that'll fundamentally break the app layout
<TabAtkins> fantasai: plus we can alias it. Electron could alias it forever if needed
<TabAtkins> fantasai: in terms of clarity, I think the previous name was extremely confusing, nobody knew what it was doing
<TabAtkins> fantasai: so I think that's a pretty high value for renaming. even with a higher % of usage i'd recommend renaming
<TabAtkins> fantasai: we renamed word-wrap to overflow-wrap; it had double-digit usage. it's not often, but we do it when it's worth ti
<ntim> +1 to fantasai
<TabAtkins> fantasai: so a 0.8% usage is very low here, especially for something that's not layout-breaking.
<TabAtkins> fantasai: so we should rename, allow impls to alias if they need
<TabAtkins> astearns: I was wondering if you'd convinced diego
<TabAtkins> kyerebo: API owners were pretty adamant about any real usage in the wild should cause us to reconsider renaming
<TabAtkins> kyerebo: but I'm hearing that it would be worth it even with some usage. i'll take that back to API owners
<dandclark> q+ to confirm the API Owner perspective
<TabAtkins> astearns: ok, and note that an alias can be done if they think it's needed for compat
<fantasai> https://www.w3.org/TR/css-cascade-4/#aliasing
<TabAtkins> fantasai: I don't think we should require an alias in the spec. *Blink* can add one themselves, but WebKit and Firefox don't need it.
<astearns> ack dandclark
<Zakim> dandclark, you wanted to confirm the API Owner perspective
<TabAtkins> dandclark: as an API owner, the % is definitely above the removal threshold
<TabAtkins> dandclark: alias seems reasonable
<TabAtkins> dandclark: what was the word-wrap threshold? did the spec enumerate the alias?
<TabAtkins> fantasai: for that one, it had >10% usage across the web. there was no way to remove it.
<ntim> q+
<TabAtkins> TabAtkins: The spec does mandate the alias
<TabAtkins> fantasai: just because Blink has the alias, doesn't mean that other browsers should need to implement it if there's no compat need for it
<TabAtkins> TabAtkins: I think it's fine to have a note in the spec about the optional alias
<TabAtkins> ntim: agree with a note
<ntim> optional note
<TabAtkins> dandclark: note seems fine, to make it clearer for devs
<TabAtkins> astearns: should we resolve on the optional alias, or wait?
<TabAtkins> kyerebo: with Dan here giving the API owners opinion, I think we can just resolve on the optional alias
<TabAtkins> astearns: proposed is we add a note to the spec mentioning that 'app-region' might be a supported alias for the feature
<TabAtkins> astearns: objection?
<TabAtkins> RESOLVED: add a note to the spec mentioning that 'app-region' might be a supported alias for the feature
<dandclark> To be clear on the above I don't speak for all Blink API Owners, this is my own perspective only :)
Activity
diekus commentedon Nov 24, 2025
During TPAC several of us agreed that the name
app-regionis not meaningful. This CSS property is used to define an area from where the user can point and drag a window in a desktop environment. The namedraggableshould be avoided to circumvent confusing with the global draggable attribute in HTML.Starting to bikeshed on a new name for
app-region:drag-areadrag-pointdrag-behavioremilio commentedon Nov 24, 2025
FWIW Gecko's version of this was
-moz-window-dragging. Since this only affects the top level page, maybewindow-dragor so?mhochk commentedon Dec 1, 2025
Building on the earlier #7017 (comment)
Though not mentioned in the spec, the existing implementation (at least in Edge) extends not only the draggable nature of the titlebar to this element, but also other native titlebar behaviors like the default contents of the right-click menu. It seems like this is desirable, as the intended use is to replace the titlebar, so the user agent choosing to adopt other titlebar-like behaviors would be a good thing.
Given that, what about a CSS property like
titlebar-area?Alternatively (if there is strong pushback on the above direction):
window-dragseems like the right direction. Maybewindow-dragging?draggableHTML property to include a newwith-windowvalue. Similar tocontenteditablehavingtrue/false/plaintext-onlyoptions.diekus commentedon Dec 2, 2025
I hadn't notice that the context menu still works! I like the
window-dragproposal @emilio mentioned above. I think there might be reasons where a developer might want to allow dragging from other areas that are not the top of the window. (side panels, other navigation areas, etc).@mhochk Nonetheless it'd mean in Edge we'd want to remove this context menu as it's weird that that UX appears on untrusted area if you think about it?
mhochk commentedon Dec 2, 2025
I chatted with @diekus a bit on this and now agree that CSS (not HTML) is the right place for this to live so that this can be cleanly controlled inside a CSS media query. As such, I withdraw my suggestion to extend
draggable.As for naming based on 'replaces the titlebar' vs 'drags the window', I still don't have a strong opinion, but now lean slightly towards 'drags the window'. Diego raised that modern apps, particularly on Mac, are using traditional-looking titlebars less. Likely because of this, the developer-facing native APIs for making a region that drags the window are moving to be less tied to the titlebar (though they are still very tied to it currently).
All that said, tossing out a few different ideas in case any feel particularly appropriate or inspire anyone else to come up with a perfect idea:
drag-behavior:move-window,normaldrag-target:window,selfdrags: window,selfdrags-window:true,falsewindow-dragging:true,falsewindow-drag:true,falsediekus commentedon Dec 5, 2025
just out of curiosity, @LeaVerou , is there any nomenclature to follow or recommendations when naming CSS properties?
kbabbitt commentedon Dec 5, 2025
The TAG design principles do have some naming guidance for CSS properties: https://www.w3.org/TR/design-principles/#css-naming
As another naming suggestion, since we have
touch-actionalready, maybe:Or perhaps integrate draggability into
touch-actionitself?diekus commentedon Jan 7, 2026
New year's update and ping! We're proposing the name
window-drag, I'll beAgenda+ingthis to get a resolution on name and hopefully behaviour as defined in #13101css-meeting-bot commentedon Jan 21, 2026
The CSS Working Group just discussed
New name for `app-region` property?, and agreed to the following:RESOLVED: rename to window-drag:none|moveThe full IRC log of that discussion
<TabAtkins> diekus: I think next two item sin agenda are related. start with app-region name<TabAtkins> diekus: we have convo at TPAC. as reminder, app-region property sets an element to being the drag target for a window, in a standalone app page
<TabAtkins> diekus: two issues came out of the meeting in tpac
<TabAtkins> diekus: first, as Tim pointed out, app-region isn't very descriptive
<TabAtkins> diekus: we started an issue to look for new names
<TabAtkins> diekus: I think there's a vibe to window-drag
<fantasai> +1
<fantasai> much clearer
<TabAtkins> diekus: so if people are okay with that, great, or if people have other ideas to discuss
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask about values
<TabAtkins> fantasai: window-drag sounds way clearer, +1. what are the proposed values?
<TabAtkins> diekus: drag | nodrag
<smfr> q+
<TabAtkins> astearns: we don't usually repeat part of the property name in the values
<dbaron> TabAtkins: border-collapse: collapse
<TabAtkins> TabAtkins: not true, we have several properties that do so. border-collapse:collapse
<bramus> `nowrap` is another one
<dbaron> smfr: background-repeat: no-repeat
<astearns> ack smfr
<TabAtkins> smfr: background-repeat:repeat
<tantek> box-sizing is another example of such naming with content-box and border-box
<TabAtkins> smfr: is this doing anything on platforms that don't have a window dragging concept? like on mobile
<fantasai> I like the suggestion in the issue for `none | move`
<TabAtkins> diekus: I think it's scoped to the idea of desktop paradigm
<TabAtkins> diekus: if you have an app that can behave like a desktop environment, it might work there. but it woudln't do anything in an environment where you don't move the frame of a window, like on phones
<astearns> ack fantasai
<TabAtkins> fantasai: on value naming, there was a none|move suggestion, think that's reasonable
<fantasai> window-drag: none | move
<TabAtkins> (I do like avoiding the ugly "nofoo" pattern we've shackled ourselves to)
<TabAtkins> astearns: Kevin had another suggestion, is that okay?
<lwarlow> +1 to none and move
<TabAtkins> kbabbitt: I'm happy with window-drag:none|move
<TabAtkins> smfr: is this applied on an element basis?
<TabAtkins> diekus: yes, but that's related to next issue
<TabAtkins> smfr: I feel like at some point we'll want clip-region, etc...
<TabAtkins> diekus: oh, no, if you put this on something round it'll be a round target. the pretend rectangle corners won't be drag handles
<TabAtkins> smfr: okay, so it follows border-shape and respects clip-path? normal hit-testing rules.
<TabAtkins> diekus: correct
<TabAtkins> astearns: proposed resolution: rename to window-drag:none|move
<lwarlow> +1
<TabAtkins> +1
<TabAtkins> RESOLVED: rename to window-drag:none|move
Updates css-ui-4 with `window-drag`
11 remaining items
css-meeting-bot commentedon Apr 1, 2026
The CSS Working Group just discussed
New name for `app-region` property?, and agreed to the following:RESOLVED: add a note to the spec mentioning that 'app-region' might be a supported alias for the featureThe full IRC log of that discussion
<fantasai> kyerebo: Wanted to revisit the renaming issue wrto compat<emilio> q+
<fantasai> kyerebo: We wanted to rename the property, but we're showing .26% of page loads using 'app-region' and .8% are using '-webkit-app-region'
<ntim> See https://github.com//issues/13102#issuecomment-4158686161
<fantasai> kyerebo: considering the standardized advice for electron, is it worth the web compatibility risk to rename this
<astearns> ack emilio
<fantasai> emilio: On what percentage of page loads, does that property have an actual effect?
<fantasai> emilio: This is maybe electron and maybe installed web-apps, right?
<fantasai> emilio: This seems like a much smaller blast radius
<TabAtkins> And Electron is locked on a particular chromium rev, right?
<fantasai> kyerebo: I did an http archive query, there were a lot of templates using it
<fantasai> kyerebo: It goes to show that it's not a non-trival amount of usage
<fantasai> kyerebo: Developers using WCO would need to make changes or deal with breaking websites.
<fantasai> emilio: My point is, all those things, they're just not doing anything. Is there a counter that actually counts when that property has an actual effect?
<fantasai> emilio: That's much more interesting than how often is this property in a stylesheet
<astearns> q?
<fantasai> iank_: The use counters for standard web won't have an effect.
<ntim> like how many times a window has been dragged from that property
<TabAtkins> (what is WCO?)
<fantasai> iank_: A lot of sites will use the same HTML/CSS for their electron app, which we don't have insight into
<fantasai> emilio: Then other quesiton is can you alias the property so 'app-region' is an alias for 'window-drag'
<fantasai> kyerebo: It's already alias of '-webkit-app-region'. But the values are different.
<fantasai> emilio: There's precedent for that. For example page-break.
<fantasai> emilio: Should be pretty doable.
<fantasai> kyerebo: Question here is, if this is already implemented and used by web developers already, is it worth the breaking changes with the increased amount of clarity
<fantasai> kyerebo: Especially since not a lot of data
<fantasai> emilio: Both of those things are fixable. if you alias the property, there's no breakage. And getting data seems generally doable. Maybe harder for electron, but electron could do their own thing if they need to.
<astearns> ack fantasai
<TabAtkins> fantasai: The usage on this is not very high and it's not very critical feature that'll fundamentally break the app layout
<TabAtkins> fantasai: plus we can alias it. Electron could alias it forever if needed
<TabAtkins> fantasai: in terms of clarity, I think the previous name was extremely confusing, nobody knew what it was doing
<TabAtkins> fantasai: so I think that's a pretty high value for renaming. even with a higher % of usage i'd recommend renaming
<TabAtkins> fantasai: we renamed word-wrap to overflow-wrap; it had double-digit usage. it's not often, but we do it when it's worth ti
<ntim> +1 to fantasai
<TabAtkins> fantasai: so a 0.8% usage is very low here, especially for something that's not layout-breaking.
<TabAtkins> fantasai: so we should rename, allow impls to alias if they need
<TabAtkins> astearns: I was wondering if you'd convinced diego
<TabAtkins> kyerebo: API owners were pretty adamant about any real usage in the wild should cause us to reconsider renaming
<TabAtkins> kyerebo: but I'm hearing that it would be worth it even with some usage. i'll take that back to API owners
<dandclark> q+ to confirm the API Owner perspective
<TabAtkins> astearns: ok, and note that an alias can be done if they think it's needed for compat
<fantasai> https://www.w3.org/TR/css-cascade-4/#aliasing
<TabAtkins> fantasai: I don't think we should require an alias in the spec. *Blink* can add one themselves, but WebKit and Firefox don't need it.
<astearns> ack dandclark
<Zakim> dandclark, you wanted to confirm the API Owner perspective
<TabAtkins> dandclark: as an API owner, the % is definitely above the removal threshold
<TabAtkins> dandclark: alias seems reasonable
<TabAtkins> dandclark: what was the word-wrap threshold? did the spec enumerate the alias?
<TabAtkins> fantasai: for that one, it had >10% usage across the web. there was no way to remove it.
<ntim> q+
<TabAtkins> TabAtkins: The spec does mandate the alias
<TabAtkins> fantasai: just because Blink has the alias, doesn't mean that other browsers should need to implement it if there's no compat need for it
<TabAtkins> TabAtkins: I think it's fine to have a note in the spec about the optional alias
<TabAtkins> ntim: agree with a note
<ntim> optional note
<TabAtkins> dandclark: note seems fine, to make it clearer for devs
<TabAtkins> astearns: should we resolve on the optional alias, or wait?
<TabAtkins> kyerebo: with Dan here giving the API owners opinion, I think we can just resolve on the optional alias
<TabAtkins> astearns: proposed is we add a note to the spec mentioning that 'app-region' might be a supported alias for the feature
<TabAtkins> astearns: objection?
<TabAtkins> RESOLVED: add a note to the spec mentioning that 'app-region' might be a supported alias for the feature
<dandclark> To be clear on the above I don't speak for all Blink API Owners, this is my own perspective only :)
[css-ui-4] add the `window-drag` text (#13801)
Rename app-region to window-drag for WPTs
Rename app-region to window-drag for WPTs
Rename app-region to window-drag for WPTs
Bug 2039328 [wpt PR 59854] - Rename app-region to window-drag for WPT…
Rename app-region to window-drag for WPTs
Bug 2039328 [wpt PR 59854] - Rename app-region to window-drag for WPT…
Bug 2039328 [wpt PR 59854] - Rename app-region to window-drag for WPT…
Bug 2039328 [wpt PR 59854] - Rename app-region to window-drag for WPT…
Add support for window-drag as surrogate of app-region
Bug 2039328 [wpt PR 59854] - Rename app-region to window-drag for WPT…