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 w3c/html-aam#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.

[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.

[josepharhar]

Now that we have implicit anchors set up with invokers and the showPopover source argument, I don't think we need the anchor attribute anymore.

[chrisdholt]

Now that we have implicit anchors set up with invokers and the showPopover source argument, I don't think we need the anchor attribute anymore.

Thanks @josepharhar - my understanding from this given the state of both invokers and showPopover is that custom element authors still need to do workarounds. Is this accurate?

[josepharhar]

What is the custom element scenario that needs workarounds? I wonder if reference target would help? #10707