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.

[foolip]

@josepharhar before I take another look, can you resolve conflicts and ensure the build runs without errors? (Otherwise the preview might not be updated.)

[josepharhar]

I fixed the compile error and merged with tip of main. I'm not sure why the bot hasn't updated the commit message with the new build, based on the checks thing it looks like it worked

[josepharhar]

I pushed another commit to try to make it build again, and it did but it looks like there was an HTTP related error in the build server

[josepharhar]

With the last commit it looks like the build finally worked

[emilio]

To me it feels a bit weird to rely on dom attributes directly from layout, I think generally we've been trying to avoid it...

This feels mostly syntax sugar, though it seems like directly assigning and getting .anchorElement could perhaps address some use cases about cross-shadow anchoring?

Is there any ability this gives you (other than convenience) that I might not have thought of?

The other thing is that it feels very weird for .anchorElement to just reflect the anchor property. It means that if you override it with anchor-name then it no longer returns the anchor you're actually positioned against, right? That feels like a very weird API...

[emilio]

What's the intention behind this rule? Doesn't this basically end up showing at the static position? Which is still a bit problematic, see w3c/csswg-drafts#9939.

[foolip]

Some more editorial review, and this is the last full pass through, I don't think I will uncover anything else in a third look.

[foolip]

Didn't catch this before, but "get an attribute by name" will return an Attr node, but what you want is the element in the same tree with that ID. Maybe wording like "the element in the something tree with the something ID, if any". I couldn't find any easily copy-pastable examples :)

[zcorpan]

https://html.spec.whatwg.org/#attr-label-for

[josepharhar]

The reason I used "get an attribute by name" is because it uses the Element? reflection machinery from the DOM spec here: https://dom.spec.whatwg.org/#concept-element-attributes-get-by-name

Can I just extract the element from the Attr somehow...? Or should I just copy exactly what https://html.spec.whatwg.org/#attr-label-for does?

[foolip]

The bit you could copy and adjust from https://html.spec.whatwg.org/#attr-label-for is:

If the attribute is specified and there is an element in the tree whose ID is equal to the value of the for attribute, and the first such element in tree order is a labelable element, then that element is the label element's labeled control.

I don't think you have any use of an Attr node, in code what you want is basically root.getElementById(element.getAttribute('anchor')), right?

[josepharhar]

Ok, I did my best to merge this paragraph into the above one and replace the text with the attr-label-for text. how does it look?

[mfreed7]

Thanks for the discussion yesterday in WHATNOT about this PR. I heard several points made:

• It is confusing that foo.anchorElement might return an element that isn’t actually used (by CSS) as the anchor, in the case where the CSS specifies the anchor name directly. E.g. position-anchor: --another-name or top: anchor(--another-name bottom).
• There’s a potential concern about using DOM attributes as part of the layout algorithm. I don’t quite understand this one fully - if someone (@emilio?) can help me understand, I’d appreciate it!
• It might be confusing to developers that one attribute (anchor) controls both anchor positioning and popover nesting.

Some solutions I heard:

• Rename anchor to implicitAnchor or fallbackAnchor or hostAnchor. Pro: this would make it more clear how the reference is actually used by the CSS anchor positioning spec. Con: it’s a little less clear that it would affirmatively be used for the popover linkage behavior.
• Mint a unique anchor name, and have anchor be a presentation attribute that maps to position-anchor: --new_magic_name. This would also have to (very magically) turn into a presentation (non-)attribute on the “target” element, mapping to anchor-name: --new_magic_name. Pro: this would not require reference to DOM attributes from layout. Cons: the fact that it affects the styles on the target element feels very new. Also, the magic name would be observable via myElement.style.anchorName.
• Use something like (or exactly) the CSS element() function, and have anchor be a presentation attribute that maps to position-anchor: element(idref). Pro: this avoids the magic naming mentioned in the point above, and (likely?) avoids having a reflected foo.anchorElement at all. Con: it could still be overridden by author CSS that sets position-anchor and might therefore still confuse authors. Also the same questions exist about how it’s exposed via CSSOM.
• Don’t define an attribute at all, and let the developer work it out. E.g. use data-* attributes and refer to them in CSS, e.g. anchor-name: attr(data-anchor-name);. Pro: no need for a spec change. Con: does not connect nested popovers, and forces the developer to do all of the work with a lot of boilerplate.
• Slight modification of the above: assume IDs on a page are unique, and just create anchor names from idrefs directly: button[id] {anchor-name: attr(id)} and then for the anchored element: menu[anchor] {position-anchor: attr(anchor)}. Pro: again, no need for a spec change. Con: does not connect nested popovers, and does not necessarily resolve the same way that idrefs do, e.g. when there are duplicates.
• Define the anchor attribute (probably renamed) as only having the popover-nesting behavior. Treat the UA style rule that maps to CSS as a separate possibility that developers could add, or we could decide to add.

Thoughts and ideas appreciated!

[tabatkins]

Having an easy way for the popover to position itself relative to the activating element seems very useful, so removing implicit anchors would be very disappointing. We designed the concept of implicit anchors into the spec very early precisely so we could hook into this exact behavior, because it's useful.

Forcing authors to do things manually is also disappointing. It requires either (a) authors manually uniquify an anchor name for every single popover, and then specify it twice in style attributes or equivalent (once as anchor-name on the button, and again as position-anchor on the popover), or (b) authors explicitly nest the popover markup inside the button, so they can rely on anchor-scope to let them reuse a name on all the instances. Both kinda suck, when we (the UA) already know exactly what the connection is between the two. Hiding this from authors doesn't seem to be helpful to anyone.

All the other suggestions seem to invoke approximately the same amount of magic - the UA still exposes the implicit linkage between the button and the popover, it just plumbs it into the style system in slightly different ways. I prefer the method already designed into the Anchor Positioning spec, as it involves no new generic mechanisms that we'd have to work thru the implications of. It's tightly targeted at this use-case and doesn't cause any issues outside of Anchor Positioning.

Looking thru the notes, note the important aspect here that, because there's no DOM relationship between the button and popover except the invocation mechanism itself, you cannot rely on presentation attributes. You need to add styles on both elements that somehow reference each other (or that both reference some shared knowledge), and that is the fundamentally difficult part here that requires some sort of new magic.

[lukewarlow]

Is there a reason why this and the associated attribute have been added to just HTML elements? Is there a reason to prevent the case where you can anchor an SVG or MATHML element to something else?

[josepharhar]

I forget if this has been discussed already for this attribute, but the popover attribute is also only on HTML elements. There was probably also a discussion there, but it will be hard to find since there are 2 PRs, at least one issue, and over 1,000 comments.

I moved it completely to HTML element here, but not with a huge reasoning: #9144 (comment)

I'm not opposed to moving if to Element if we have a good reason, but imo restricting to HTML elements makes things easier.

[lukewarlow]

Okay I'm not going to relitigate if the working group has already discussed this sort of thing. I will add my two cents though.

Imo we should need good reason for a global attribute to only be on HTML elements. Not the other way around.

Especially when anchor is so tightly coupled to CSS anchor positioning (which afaik and hope) has no limitations wrt to element namespaces.

[annevk]

Well, SVG and MathML specifications are not up to the same level of quality so determining the impact is tricky. There's an issue that goes into porting more of HTML's global attributes to SVG and MathML (and possibly making them superglobal as id and class are), but it's extra work and given the current state of the ecosystem not at all straightforward.

[lukewarlow]

That sounds like a fairly good reason, thanks!