[css-anchor-position-1] Bikeshed name of inset-area

[jensimmons]

Una tweeted the other day about Anchor Positioning.
https://twitter.com/Una/status/1777424771254222948

It reminded me that I do not believe inset-area is the best name for this property. It's the area for the thing, cool. But it's insetting from what? Why is it called inset area? If I'm a developer trying to remember the name of the property cold, as I write CSS to create an anchor and put it someplace, why am I going to think "oh, I need to describe the area for the inset"?

I think we can find a property name that describes the tool developers will be reaching for. Perhaps position-area or anchor-area.

[tabatkins]

The rename of anchor-default to position-anchor was predicated on the idea that the anchor-* prefix should be used for properties on the anchor element, not the positioned element, so anchor-area would be out.

I'm not sure why position-area is particularly better than inset-area, tho. Both of them are words related to abspos. We chose inset-area because it's most directly about modifying how the inset-* properties behave (by modifying the containing block). In the common case, you'll use either inset or inset-area, but usually not both; it feels appropriate to me that their names match up like that when they occupy nearly identical functional spaces. position-area wouldn't be inappropriate, but I personally don't find it better, either.

(The two big renames we've done so far - position-anchor and position-try - both had pretty strong consistency arguments for making them, either consistency with the anchor-/position- dichotomy, or consistency with the redesigned @position-try rule. I'd prefer to have at least a moderate speedbump for renames at this point in the spec's life.)

[nt1m]

I agree position-area is a better name. inset-area made more sense when the inset properties were reset by inset-area, but from what I heard, this is no longer the case, which makes it very confusing.

It also makes sense to make position-area a longhand of position IMO.

Anything that controls the behavior of inset should be position-*, inset-* should be reserved to longhands of inset only.

[nt1m]

cc @mfreed7 @tabatkins

[una]

@nt1m I disagree that putting inset-area in the position shorthand makes sense. inset-area positioning only works with absolute or fixed positioning, so combining it with other position options (such as relative, or sticky) would be invalid. I.e. position: relative top span-left would be invalid if you try to combine them into a shorthand. They seem like very different developer affordances to me.

[nt1m]

@una The syntax for the shorthand could be static | relative | sticky | [ [ absolute | fixed ] || <'position-area'> || <'position-anchor'> ] or something similar. Or at the very least, position-area could be reset-only subproperty of position, like position-anchor currently is.

Anyway, I'm advocating for the position- prefix here, mainly because @fantasai just taught me the spec allows you to use inset-area along with inset which wasn't clear to me from the naming, e.g.:

inset-area: bottom left;
inset: 2px;

will move the containing block to the bottom left of the anchor, then inset 2px from that containing block.

It would be a lot more explicit that this is how things work if the property was named position-area. With the name inset-area, I have a tendency to think that inset-area resets inset or vice-versa and that only one of the two apply.

[nt1m]

I believe the original naming of inset-area came from when the spec used to make inset-area reset the inset values to anchor(...), where the name made sense, but it no longer makes sense with the current definition.

[mfreed7]

I believe the original naming of inset-area came from when the spec used to make inset-area reset the inset values to anchor(...), where the name made sense, but it no longer makes sense with the current definition.

I thought it came from the fact that you were picking an area within the inset- modified-containing-block? In terms of explaining what this property does for developers, I actually think it's pretty important to tie it to insets, so they know it lives within the IMCB. Calling it position-area feels more confusing actually.

[nt1m]

I thought it came from the fact that you were picking an area within the inset- modified-containing-block?

From #9145:
"In the current spec you'd write that as bottom: anchor(top); right: anchor(right);; in this proposal you'd alternately be able to write inset-area: top / start center; and get the same effect."

The very first proposal in that issue saw inset-area as an alternative to setting two of the inset longhands.

I thought it came from the fact that you were picking an area within the inset- modified-containing-block? In terms of explaining what this property does for developers, I actually think it's pretty important to tie it to insets, so they know it lives within the IMCB. Calling it position-area feels more confusing actually.

My mental model is that there is a containing block that is picked by position, and inset-area modifies that containing block, just like position-anchor does. It does not pick an area inside the containing block, but modifies the containing block itself.

The problem with the inset-* naming is that it implies overriding the other inset properties. It's not obvious you can use both inset-area and inset together to inset from the containing block that inset-area has defined.

[fantasai]

I believe the original naming of inset-area came from when the spec used to make inset-area reset the inset values to anchor(...), where the name made sense, but it no longer makes sense with the current definition.

I thought it came from the fact that you were picking an area within the inset- modified-containing-block? In terms of explaining what this property does for developers, I actually think it's pretty important to tie it to insets, so they know it lives within the IMCB. Calling it position-area feels more confusing actually.

@mfreed7 Actually it's exactly the opposite? inset-area specifies the area that contains the inset-modified containing block.

Finding the available space for an abspos follows three steps:

1. Identify the containing block generating element (defaulting to initial containing block).
2. If grid-area or inset-area applies, use the specified area's edges, otherwise use the containing block's padding edge.
3. Apply inset properties to reduce to the inset-modified containing block. This is the rectangle the abspos is sized and positioned into.

[fantasai]

Considering this together with #10321 what renaming allows us to do is to create position as a shorthand of all the positioning properties other than inset (which is lengths, kinda margin-ish, and feels more separate). Something like:

position: <type> <anchor>? [ / <container>]? [ <area> [, <try>]? ]?

Examples
-------

position: fixed --foo bottom, top;
          /* fixed to anchor --foo, try bottom then top */

position: absolute / --container;
          /* absolute within --container */

position: fixed --foo bottom span-right, flip-block, bottom, top;
          /* fixed to anchor --foo's with fallbacks*/

position: absolute --foo / --container left;
          /* abspos in the left track of --foo inside --container */

(Allowing this is why, of the two syntaxes we came up with, we went with the position-* variants in https://fantasai.inkedblade.net/style/specs/css-anchor-exploration/#anchor-positioning )

[una]

@fantasai - how would this work with position-try-options? What if you skip the inset-area and want to use named @position-try values instead? I.e. position: fixed --foo --bottom, --top;?

[nt1m]

Regardless of shorthanding, I think we should do this. It's inconsistent that this is named inset-area while all properties that control the containing block are prefixed with position-. The shorthanding is a good addition, but my main motivation for this renaming is to make it clear that this changes the containing block, and not the inset properties themselves.

@astearns Would it be possible to add this to the next agenda?

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] Bikeshed name of `inset-area` , and agreed to the following:

• RESOLVED: Change inset-area back to position-area

The full IRC log of that discussion

<flackr> ntim: right now anchor positioning has a property called inset-area. It's confusing as it suggests by it's prefex that you can't use this and inset at the same time but they're independent properties that can work together
<flackr> ntim: in some ways this is a property to pick the containing block, these usually have a position prefix. So I'd suggest position-area
<TabAtkins> q+
<astearns> ack fantasai
<Zakim> fantasai, you wanted to add a historical note
<kizu> +1 to position-area, not a strong one, but convinced by the arguments in the issue
<flackr> fantasai: When we first proposed it, it was called position-area. It was renamed to inset-area because it didn't use to contain the containing block, just the interpretation of auto on the properties so it was more closely tied to other inset properties
<astearns> ack TabAtkins
<flackr> fantasai: since then we've switched it back to changing containing block, so i agree it would make sense to rename back
<flackr> TabAtkins: I'm neutral on the name either way. I do still like inset-area as it's named because it occupies the same mental area as insets. Most of the time you won't use both because inset-area does most of what you need so having them in the same syntactic space seems nice
<flackr> TabAtkins: more broadly, because it's a value neutral rename, it's late enough in the spec lifecycle i'm happy to pushback on renames that don't hvae a clear value. I was happy to rename fallbacks but there are impls / tutorials that use the existing name. If there's no problem with the existing name would prefer not to change it
<flackr> astearns: prefer but not object?
<flackr> TabAtkins: lightly objecting, not formally
<flackr> TabAtkins: we've changed a lot of things where there was a good argument for it
<flackr> astearns: in terms of the timing, this was put on in may. The lateness was in part because we didn't get to it in a timely fashion
<flackr> TabAtkins: this was originally filed a few days after I2S after years of discussing the spec
<astearns> ack kizu
<flackr> kizu: I am more inclined for position-area. Thinking as an author it works as an inset, but many authors don't use insets for positioning things so there's no disconnection. Thinking about positioning something position-area is a good name and removes the connection to insets
<flackr> kizu: I was convinced by the arguments for position-area in the issue
<fantasai> Note, it wasn't years after discussing the spec -- the proposal for position-area (and inset-area) wasn't presented until about a year ago.
<flackr> astearns: with chair hat off, i also am convinced to change back to position-area
<flackr> jen: i think what matters most is developer ergonomics when someone is writing things so that they don't have to look things up
<flackr> jen: inset-area feels like an oddball compared to the other position properties
<TabAtkins> position-container + position-area both also seem to do very similar things (and they kinda do); the slight difference that the changed prefix brings might be a good thing.
<flackr> TabAtkins: I was saying the association with inset seems good to me, but seems fairly neutral either way
<flackr> TabAtkins: I'm merely pushing back on the grounds that it has been out for a while
<flackr> astearns: it sounds like others believe the reasons are strong enough to make the change
<ntim> q+
<flackr> TabAtkins: I will say there are many here who feel against making the change
<astearns> ack ntim
<flackr> ntim: the chrome team did say they would be okay making breaking changes even after shipping. This rename has developer experience benefit as jensimmons said and better describes what the property does, also implying inset can be used alongside it
<flackr> ntim: so i think this is a general improvement for dev exp
<ntim> q+
<flackr> TabAtkins: point of order, we promised we would be happy to make reasonable changes even if they are breaking, not any and all changes. We will still push back on changes that don't have a strong argument for them
<astearns> ack fantasai
<dbaron> Here's a list of breaking changes that are implemented or in progress in Chrome: https://groups.google.com/a/chromium.org/g/blink-dev/c/jGTYNuidPRs/m/4oY6JFVyBAAJ
<flackr> fantasai: 2 more spec things about the rename. 1. we should consider this in conjunction with position-try fallbacks. This takes inset-area directly into it. Sharing a common prefix helps associate them.
<fantasai> position-area: top left; position-try: bottom left, bottom,etc.
<flackr> fantasai: if that's inset area it's harder to associate that those represent the same idea
<miriam> q+
<ntim> q-
<flackr> fantasai: 2nd, if we do figure out shorthanding, having it prefixed with position sets us up better for this relationship
<astearns> ack miriam
<ntim> +1 to what fantasai said :)
<jensimmons> q+
<flackr> miriam: I'm unconvinced by some of the arguments, e.g. having inset as a prefix doesn't imply it can't be used with inset. But I find fantasai's argument convincing. It sounds worthwhile for this
<astearns> ack jensimmons
<ChrisL> fair point about no resolution on the earlier name change
<flackr> jensimmons: For process, is it too late to change the name if the name change isn't a certain amount of benefit? This was originally proposed as position-area. The name was changed when it was written into the spec but we didn't have a CSSWG resolution for the name change. Apple has repeatedly felt like we were being obnoxious about bikeshedding names to wait for things to mature, now we're circling back to say we still believe this is better
<flackr> astearns: any other comments?
<flackr> ntim: fantasai also reminded me why inset-area was chosen, becuase it was defined differently before, to change the computed value of insets. Now it doesn't so it's complementary to insets, not replacing them
<TabAtkins> I don't understand this argument - we have complementary properties both with and without common prefixes all the time.
<flackr> astearns: I think i'm hearing we should resolve on changing it back to position-area
<ChrisL> +1
<flackr> astearns: TabAtkins okay with resolving on this?
<flackr> TabAtkins: okay
<flackr> RESOLVED: Change inset-area back to position-area