[css-anchor-position]: consistent naming convention for anchor-related properties

[AleksandrHovhannisyan]

Hello! This is my first time contributing an issue to this repo. I'm not sure if this is the place to ask questions, especially for something one could consider to be a matter of opinion or personal preference.

I was reading up on the CSS anchoring API and was wondering why some properties use the anchor- prefix while others use position-. For example:

.target {
  anchor-name: --my-anchor;
}
.anchored-element {
  position-anchor: --my-anchor;
  position-area: end end;
}

My understanding is that the anchoring API is just a natural extension of CSS positioning, allowing us to position elements relative to each other as opposed to just statically, absolutely, or fixed to the viewport. I assume this is why those names were chosen.

But as an end user, I normally expect related properties to share a common naming convention. This improves the developer experience by reducing mental load and the need to remember two naming schemes. It also makes it easier to find the properties you're looking for in editors that have autocomplete. If I know I want to work with the anchoring API, I'd just type anchor- and expect to see all available properties.

For example, I would argue that code like this reads more naturally and is easier to remember:

.target {
  anchor-name: --my-anchor;
}
.anchored-element {
  anchor-target: --my-anchor;
  anchor-[position|point|whatever]: end end;
}

Since the anchoring API was already released over a year ago in Chrome, I assume a change like this wouldn't be realistic at this point in time (but again, I'm new to this process, so maybe it would?).

[tabatkins]

The API does use a consistent naming scheme, it just distinguishes between properties that go on the anchor (anchor-*) and properties that go on the positioned element (position-*): https://drafts.csswg.org/css-anchor-position/#property-index

[AleksandrHovhannisyan]

I guess I just don't see how that distinction is helpful in practice. The element that serves as the anchor and the element that attaches to the anchor are both participating in the same anchor API. One doesn't do anything meaningful without the other. So in my mind it would make sense for them to be part of the same namespace: anchor-name, anchor-[target | to | source], anchor-position, etc.

Were there any other discussions along similar lines in the past? Sorry, just asking because I wasn't able to find any mentions of this in the repo so I wanted to open this issue for discussion.

[fantasai]

@AleksandrHovhannisyan I think both approaches make sense. There wasn't much discussion of the option you're describing here, because nobody proposed it. Might have been an interesting discussion to have had earlier, but I suspect at this point it's to late to make syntactic changes that don't have very compelling "this is super confusing as-is" arguments?

Fwiw, I think people are often confused by "these properties go on the container vs these properties go on the child", so having this distinction encoded in the syntax might not be a bad outcome here.

All that said, I think the issue you filed is really great. You not only took the initiative to go from "this bit of the spec bugs me" to filing an issue, you did a really good job of outlining your concern and explaining it. And it's a reasonable and useful input to have into the design of the Anchor Positioning spec! I wish we'd had it a little earlier in the process--whether or not it resulted in any changes, it would have helped us think about these things deeper and make sure we have the right design. :)