New name for `app-region` property?

[diekus]

Builds on #7017

New name for app-region CSS property.

[diekus]

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:

• drag-area
• drag-point
• drag-behavior

[emilio]

FWIW Gecko's version of this was -moz-window-dragging. Since this only affects the top level page, maybe window-drag or so?

[mhochk]

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):

• 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.

[diekus]

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?

[mhochk]

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, normal
• drag-target: window, self
• drags: window, self
• drags-window: true, false
• window-dragging: true, false
• window-drag: true, false

[diekus]

just out of curiosity, @LeaVerou , is there any nomenclature to follow or recommendations when naming CSS properties?

[kbabbitt]

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-action already, maybe:

drag-action: none | move-window

Or perhaps integrate draggability into touch-action itself?

[diekus]

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

[css-meeting-bot]

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