Re: [w3c/webcomponents] Define order for attributeChangedCallback invocation? (#474)

OK, so this is about https://w3c.github.io/webcomponents/spec/custom/#upgrades step 8 only, I believe. Currently it says "in order", because I assumed attributes were stored in the attribute list in some kind of order.

What I am hearing is that that is true, but that in the case of parser-created elements, the order is not defined? In which case, https://w3c.github.io/webcomponents/spec/custom/#parsing step 8 will also need to change.

How else is this order observable? `element.attributes`, I guess, and the new `element.getAttributeNames()`. Is there a possibility of moving the "reshuffle these in whatever implementation defined order you want" logic to `element.attributes`'s indexed getter?

If we want to have parsing use implementation-defined order for appending the attributes, but attributeChangedCallbacks be called in some order, I guess we'd need to do some weird stuff like changing https://w3c.github.io/webcomponents/spec/custom/#dfn-invoke-custom-element-actions to reorder the attributeChangedCallbacks, or maybe adding a flag to the element during parsing that causes it to do reordering during that time, but not in subsequent mutations.

This seems like a lot of mega-hacks to allow browsers to continue with implementation-defined behavior, which in general we try to eradicate. I'd prefer to not do that and just have the parser append attributes in source order. But I don't have the historical background in this issue that @annevk has.

@esprehn, @rniwa, @travisleithead, thoughts?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/474#issuecomment-205481056

Received on Monday, 4 April 2016 20:31:15 UTC