[css-anchor-position-1] Ability of logical / physical combo positioning

[xiaochengh]

The feature comparison table (see #9117) currently says:

Feature	Inset-based (current spec)	Grid-based
Logical / physical combo positioning	❌?	✅

I assume this is the about top / start use case from Apple's earlier presentation:

While the current spec has some difficulties to achieve the same, this should no longer be an issue with the inset-area that we newly agreed to add (#9145 (comment)), and the syntax should be almost identical.

So I think this is no longer an issue, and we can modify that row into double green ticks, with a reference to #9145?

@fantasai @jensimmons

---

Note: without inset-area, the current spec needs to know the writing mode & direction of the current element and its containing block in advance, so that it knows which inset properties to set.

For example, assuming they have horizontal writing mode and same direction, it is:

.anchor-positioned-element {
  top: anchor(bottom);
  inset-inline-end: anchor(start);
}

But if they have different directions:

.anchor-positioned-element {
  top: anchor(bottom);
  inset-inline-start: anchor(start);
}

Things can get even more complicated if the writing modes are different.

With inset-area, it simply becomes:

.anchor-positioned-element {
  inset-area: top / start;
}

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position-1] Ability of logical / physical combo positioning, and agreed to the following:

• RESOLVED: this issue is closed

The full IRC log of that discussion

<emeyer> TabAtkins: One of the cool bits of the Apple proposal was the grid-based positioning
<emeyer> …Doing a 3x3 grid based on containing block and anchor is cool
<emeyer> …We want to adopt this as an `inset-area` shorthand that expands to setting either 0 or the anchor
<emeyer> …We think this request is resolved and we can close this issue
<emeyer> …And then we might change the comparison to have a green checkmark in both
<emeyer> fantasai: I think we agree
<emeyer> astearns: Other comments?
<emeyer> (silence)
<emeyer> TabAtkins: So we propose to consider this issue as closed
<emeyer> astearns: This is different proposal than what’s in the spec?
<emeyer> TabAtkins: No
<emeyer> …There’s another issue where we resolved to add it and we want to close this as no l onger a point of contention between proposals
<emeyer> astearns: Concerns?
<emeyer> (silence)
<emeyer> RESOLVED: this issue is closed