Multiple Anchor Names on a Single Element

Why You'd Want This

Imagine an avatar with two anchored decorations: a presence dot at the bottom-right and a notification count at the top-right. They both anchor to the same avatar but conceptually they're different targets. Giving the avatar two anchor names keeps the relationships explicit.

.avatar {
  /* Multiple names, comma-separated */
  anchor-name: --avatar-corner-tr, --avatar-corner-br;
}

.unread-count {
  position: absolute;
  position-anchor: --avatar-corner-tr;
  position-area: top-end;
  transform: translate(40%, -40%);
}

.presence-dot {
  position: absolute;
  position-anchor: --avatar-corner-br;
  position-area: bottom-end;
  transform: translate(40%, 40%);
}

Why not just use position-area on one anchor name?

You can! The two-name version is equivalent in this simple case. The benefit appears when:

1. The decorations have different lifetimes: maybe .unread-count is rendered conditionally based on a notification API, while .presence-dot is always present. Distinct names make refactoring safer.
2. The decorations come from different parts of your component tree: a notification system mounts .unread-count from a global portal, while .presence-dot is rendered inline. Distinct names avoid accidental coupling.
3. One target needs to follow a different position-area than the other: with one name and position-area per target this works, but with two names you can also vary which anchor element each target follows by repointing position-anchor independently.

Naming convention

Use semantic names that describe the relationship:

• --menu-trigger-1, --menu-trigger-2, ... for repeating trigger buttons
• --card-handle for a draggable handle inside a card
• --row-action-anchor for a per-row action menu in a table

Avoid --anchor-1, --anchor-2 in production code — once you have 20+ anchor names, semantic names become essential.

Scope and uniqueness

Anchor names are scoped to the document by default. The anchor-scope property (Chrome 131+) lets you scope them to a subtree, which is essential for component libraries: each instance of a tooltip component can use the same internal name without colliding with sibling instances.