Clarification on Element reflected IDL attribute steps

[josepharhar]

What is the issue with the HTML Standard?

https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes%3Aelement

Consider the following:

<button id=mybutton>button</button>
<div id=mypopover popover=auto>popover</div>
<script>
mybutton.popoverTargetElement = mypopover;
mybutton.setAttribute('popovertarget', '');
mybutton.popoverTargetElement; // What should this return?
</script>

The latest implementation in chromium returns null for popoverTargetElement, and firefox returns the popover element. The reason that chromium returns null is because of these steps in the spec (which is implemented here):

For element reflected targets only: the following attribute change steps, given element, localName, oldValue, value, and namespace, are used to synchronize between the content attribute and the IDL attribute:

1. If localName is not attr or namespace is not null, then return.
2. Set element's explicitly set attr-element to null.

When the attribute is set to the empty string, then it sets the explicitly set attr element to null. A WPT change was made here which tests this: web-platform-tests/wpt#44634

@ziransun @emilio which behavior is correct?

[emilio]

Hmm, so I think this was an oversight on my side when reviewing the patch that introduced the test.

So the setter's step 2 is:

Run this's set the content attribute with the empty string.

So setAttribute('popovertarget', '') is setting the value to the same.

However, per spec, https://dom.spec.whatwg.org/#concept-element-attributes-set-value does run the attribute change steps, even if the attribute didn't change. Apparently this is consistent with mutation events too.

So I think this is a Firefox bug, and we also need to clear the explicit element even if the attribute doesn't change...

Unless someone disagrees? I find it quite weird that setAttribute("foo", getAttribute("foo")) has side effects, but that's already the case so...

[emilio]

cc @smaug---- in case you have opinions.

[emilio]

https://bugzilla.mozilla.org/show_bug.cgi?id=1881075 has a fix for that.

[josepharhar]

Thanks!

So the setter's step 2 is:

Run this's set the content attribute with the empty string.

So setAttribute('popovertarget', '') is setting the value to the same.

So the spec as written would clear the explicitly set attr element every time you set it?

[emilio]

Yeah, unless I'm misreading.

[smaug----]

Setting an attribute value means setting an attribute value - doesn't matter whether the value is the same or not :)

[annevk]

Can this be closed?

[emilio]

Yeah... We might want a different name for the attribute change steps (maybe attribute set or remove steps? Though that's a mouthful)

[annevk]

We could use "mutation" to align with mutation observers (or poke/meddle), but fundamentally you have to know these steps always run. If you want to make a change (hah) like that, prolly best discussed over in whatwg/dom.