Add anchor attribute

[josepharhar]

The anchor attribute can be used to set up CSS anchor positioning by setting an implicit anchor element: https://drafts.csswg.org/css-anchor-1/#implicit-anchor-element.

The CSS properties used to set up anchor positioning relationships are perfect for repeating patterns, such as:

<div class=anchor></div>
<div class=positioned></div>
<div class=anchor></div>
<div class=positioned></div>
<div class=anchor></div>
<div class=positioned></div>
<style>
  .anchor { anchor-name: --foo; }
  .positioned { position-anchor: --foo; }
</style>

However, for structural patterns, such as when using a Popover, an HTML attribute has less boilerplate and makes the relationship much more directly observable:

<button id=button1>Pick something #1</button>
<div popover anchor=button1>Popover for button1</div>

This structural pattern can apply to other use cases also, where unique elements are paired.

When used with the Popover API, the anchor attribute also naturally helps to create a relationship that ensures popovers are properly nested:

<button id=button>Menu 1</button>
<menu popover anchor=button>
  <li id=item1>Item 1</li>
  <li id=item2>Item 2</li>
</menu>
<menu popover=hint anchor=item1>
  Helpful tooltip about item 1
</menu>
<menu popover=hint anchor=item2>
  Helpful tooltip about item 2
</menu>

This PR adds the anchor attribute to HTML and connects it to the Popover API.

• At least two implementers are interested (and none opposed):
  • Chrome
  • HTML anchor attribute WebKit/standards-positions#216
  • HTML anchor attribute mozilla/standards-positions#836
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/html/dom/elements/global-attributes?label=master&label=experimental&aligned&q=the-anchor-attribute
• Implementation bugs are filed:
  • Chromium: Already implemented
  • Gecko: …
  • WebKit: …
• MDN issue is filed: …

---

/dom.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/popover.html ( diff )
/references.html ( diff )
/rendering.html ( diff )

[annevk]

Before looking at this I'd like to see topic: popover The popover attribute and friends shrink a whole lot first.

[jpzwarte]

I've moved my previous comment to #9311.

[cwilso]

@annevk I'm not sure I understand why this work is blocking on popover. Although popover is one place anchor would be useful, of course, it's not the only scenario - and it seems like popover's needs are addressed here. What is the scope of your concern for what needs to be investigated before anchor work can proceed?

[nt1m]

@josepharhar @tabatkins My initial thought looking at this is whether we can leverage presentation hints in some way instead of an "implicit anchor element", while still making it work conveniently for developers.

The idea behind this seems fine to me though.

[annevk]

@cwilso my concern is that popover landed in the standard with lots of issues that need to be addressed and it's been taking quite a long time for them to be addressed. That makes me uncomfortable about new features.

[tabatkins]

whether we can leverage presentation hints in some way instead of an "implicit anchor element", while still making it work conveniently for developers.

I'm not sure how that would be possible. Without an implicit anchor element, you need a named anchor element, which means that, assuming we could craft an appropriate selector (not certain that's true, haven't thought about it enough) we'd have to reserve a name just for this use-case. And an element can only have one anchor name, so it would conflict with authors using an anchor name on the element for other purposes. (Even if we change to allow multiple anchor names, which there's an open issue about, we'd still conflict since CSS has never gained a way to add to a list.) So I don't think it's possible to do this, no.

Skipping past the feasibility, tho, can I ask why you want to do this? If there's a particular reason you want to lean on presentational hints instead, I'd like to know in case it impacts other things architecturally.

[josepharhar]

We want to ship this soon in chrome along with CSS anchor positioning so they can be used together.
I will continue to work on the remaining popover issues, but any feedback on this attribute in the meantime would be greatly appreciated so we have time to make changes if needed.

[chrisdholt]

Forgive a potentially dumb question, but we've had problems leveraging the current anchor positioning API with custom elements. Is it reasonable to assume that the anchor attribute would work with Web Components as though they were native elements? To be specific - there is no element within the shadow root where reference target would be necessary, the element itself is the target.

Anchor positioning should "work" on custom elements in the same way as regular elements. If you've found something that isn't working on the Blink implementation, perhaps file a bug?

Can do - essentially, we're finding (unless it's user error) that we can't use anchor() without creating a constructable stylesheet in the light DOM; the adopted stylesheet is adopted to the shadow root which is our current hypothesis. I'll have someone open a bug. Thanks @mfreed7.

As far as the question above, I just want to elevate the edge case where Reference Target isn't applicable.

[davatron5000]

Looped in by @chrisdholt, I was working on an anchored tooltip this week and have a reduced example.

Given the DOM structure ....

<button id="anchor" popovertarget="tooltip">Text</button>
<tool-tip id="tooltip" popover>Content</tool-tip>

The following CSS works in Light DOM...

<style>
  #anchor { anchor-name: --my-name; }
  #tool-tip { 
    position-anchor: --my-name; 
    bottom: anchor(--my-name, top); 
  }
</style>

But moving that into the Shadow DOM doesn't work.

<style>
  #anchor { anchor-name: --my-name; }
</style>
<button id="anchor" popovertarget="tooltip">Text</button>
<tool-tip id="tooltip" popover>
  <template shadowrootmode="open">
    <style>
      :host { 
        position-anchor: --my-name; 
        bottom: anchor(--my-name, top); 
      }
    </style>
    <slot></slot>
  </template>
  Content
</tool-tip>

The "CSS ref" to --my-name is lost when traversing the shadow boundary. That means anchor(--my-name ...), etc won't work in the Shadow styles either. And (just in case someone is curious) assigning --anchor: --my-name to a CSS Custom Property doesn't work either.

An anchor attribute would be awesome, but ideally accessible/referenceable from the ShadowRoot :host as well as shadow children.

[mfreed7]

The following CSS works in Light DOM...
But moving that into the Shadow DOM doesn't work.

The "CSS ref" to --my-name is lost when traversing the shadow boundary. That means anchor(--my-name ...), etc won't work in the Shadow styles either. And (just in case someone is curious) assigning --anchor: --my-name to a CSS Custom Property doesn't work either.

Ahh - thanks for the clarification. Note that finding an anchor says:

...
el’s anchor name and anchor spec are both associated with the same tree root.

and also this:

Note: An anchor-name defined by styles in one shadow tree won’t be seen by anchor functions in styles in a different shadow tree, preserving encapsulation. However, elements in different shadow trees can still anchor to each other, so long as both the anchor-name and anchor function come from styles in the same tree, such as by using ::part() to style an element inside a shadow. (Implicit anchor elements also aren’t intrinsically limited to a single tree, but the details of that will depend on the API assigning them.)

So in your example, you'd have to position the tooltip using your first ("working") CSS, where you are anchoring in the light DOM, and not the one where you set position-anchor on :host from inside the shadow root, because in that case you're trying to cross shadow root bounds with the anchor reference.

Also note that last sentence, which alludes strongly to this issue about the anchor attribute.

[amn]

I agree that in its currently proposed form, the anchor attribute makes for a clear layout-vs-presentation problem. Ideally I'd see HTML not mix back in what comes across as a only thinly disguised presentation-level kludge, after things like <font> and <center> were banished long ago.

For what it is worth, and I am sure this has been mentioned already, I for one wouldn't necessarily object to a means of associating popover elements with some other element(s), since semantics of a popover may in the very least optionally permit it to relate to some element. For instance, form elements present what is essentially a popover element, to communicate e.g. validation errors, and said popover element would then naturally be related to the form control being validated.

In fact, one could make the case that the association of a popover element with some other element is implicit, even if one is not specified, in which case the popover is associated with the entire document body.

Which leads me to preliminarily conclude that there could be made a case for some HTML attribute to associate a popover element with another element. If the element related to a popover element, were to be removed [from the document], for instance, then it would by default remove (or at least hide) the popover element, such is the nature of the association proposed -- regardless of whether the popover element is in the other element's tree.

For instance, there may be a popover element related to an entire table, but cannot be placed directly in the table since the latter doesn't admit elements of arbitrary type (node name), so the removal described above cannot rely on the popover element being in its "anchor" element's tree.

Conclusively, anchor may or may not be a good name for an attribute relating a popover element to its "anchor", but indeed it's a slippery slope -- is there no other name that can better reflect the semantics of the relationship governed by HTML, not taking CSS into account (ideally)?

[Jxck]

Does creating custom ident dynamically via ident() in CSS cover this proposal ?
w3c/csswg-drafts#9141

[tabatkins]

No, using ident() still means you need to explicitly link the two elements with a name. At best, it lets you write your CSS more generically, and push the name into the HTML.