This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"when the attribute is modified with setAttribute, setAttributeNS, removeAttribute, or removeAttributeNS methods of the custom element, as well as setting the value property of the custom element's attribute, the callback must be invoked immediately." I think remove (called on the attribute's value text node) this affects attribute values, (I *think*, but the spec is a little abstract.) Maybe others. In Blink textContent, appendChild, etc. affect attribute values. But apparently that is contrary to the DOM spec.
I am leaning toward explicitly defining callback-queue-draining points in the spec and using these points universally for all callbacks. My naive hypothesis is that if we do this right, then if setAttribute() invokes lifecycle callbacks, the only callbacks in the queue would be attributeChanged callback queued by this setAttribute.
(In reply to comment #1) > I am leaning toward explicitly defining callback-queue-draining points in > the spec and using these points universally for all callbacks. I think this is a bad idea. I am explaining my view on bug 22459. I would love to know what rafaelw thinks about this.
There is some discussion of attributes on https://www.w3.org/Bugs/Public/show_bug.cgi?id=22459#c10, #c11, #c12 that probably should be here. Basically--what is the type of attributeChanged? It looks like this pleases most people: callback void (DOMString name, DOMString? oldValue, DOMString? newValue) If an attribute is added, oldValue is null. If an attribute is removed, newValue is null. If an attribute is changed, the values of oldValue and newValue are the values of the attribute before and after the change (ie when the callback is queued. Because of callback delivery, what you get from getAttribute may be different.)
https://dvcs.w3.org/hg/webcomponents/rev/8d2ad875c8e6