attributeChangedCallback should not be called if the attribute has not changed

[dmarcos]

attributeChangedCallback should not be called if the attribute has not changed

[WebReflection]

which browser does that? there are at least 3 internal branches for attributes changes, I need to know where I can reproduce this. Thank you.

[dmarcos]

The native implementation of document.registerElement in Chrome latest version (47.0.2526.73 (64-bit)) doesn't call attributeChangedCallback if the attribute value doesn't change. Below a screenshot of my console after adding a console.log in the attributeChangedCallback method of my custom element:
It makes sense to me that attributeChangedCallback is not called when the attribute doesn't change but I could not find what's the expected behavior anywhere in the spec: http://www.w3.org/TR/custom-elements/

[dmarcos]

In Firefox Latest Version that doesn't have a document.registerElement native implementation the polyfilll always calls attributeChangedCallback regardless if the attribute value has changed or not. This is the branch that is called:
https://github.com/WebReflection/document-register-element/blob/master/src/document-register-element.js#L542

[WebReflection]

That's the unclear bit to me. AFAIK MutationObserver also calls it more than once (can you please test your code in Safari?) and if specs are not clear, I don't want to blindly follow Chrome.

• why are you reassigning the same attribute over and over?
• what if you pass a boolean or number, would a comparison after casting to string work as well or if you have el.getAttribute('num') === "123" and you el.setAttribute('num', 123) it should trigger?
• what does Chrome do in the latter case?

Thanks for your collaboration. FWIW I agree that triggering a change twice doesn't male much sense but I also belive is there for a reason: either Chrome was acting like that earlier and I wrongly took it as reference, or MutationObserver and DOMAttrModified were doing weird things and it has been normalized like that.

[WebReflection]

OK, you know what? I've fixed it for all browsers. There's no coercion check though, just remember that attributes are also strings ;-)

Version 0.5.2 fixed this.

[dmarcos]

Thanks. I think it's a good decision. I checked the document.registerElement native implementation in Firefox that is hidden behind a flag (dom.webcomponents.enabled) and it matches the Chrome behavior: attributeChangedCallback is not called if the attribute value doesn't change.