Why does attributeChangedCallback fire when a new attribute value is the same?

[trusktr]

Calling .setAttribute('foo', 'bar') repeatedly on the same element will continually trigger it's attributeChangedCallback.

This means I have to add conditional checking to my custom elements:

attributeChangedCallback(attr, old, new) {
  if (old != new) {
    // ...
  }
}

I didn't notice this before because I just assumed that the attributeChangedCallback fired when an attribute... changed.

This seems strange. Why is this?

Related: https://github.com/whatwg/dom/issues/520

[annevk]

For consistency with mutation observers.

I don't understand why you'd have to add that check though, it's a fault of the caller.

[trusktr]

it's a fault of the caller.

Maybe, but easily avoidable by the engine.

Is the reasoning to avoid implementation complexity? Or something else?

The only thing I can imagine is using the act of setting attributes as method calls (sort of like how jQuery uses strings for method calls).

elm.setAttribute('doSomething', 'arg')
// ...
elm.setAttribute('doSomething', 'arg') // do it again later

but the custom element can also just provide an actual method.

[annevk]

I gave the reason above, consistency.