Re: [w3c/webcomponents] Undocumented behaviour with regards to attributeChangedCallback and DOM access (#767)

I updated the test to show that indeed all attributes are available. I first thought their availability would depend on the order in which the callback is called, but it looks like all attributes are available.

I agree that the fact children are not available makes sense, and I don't think the behaviour is wrong. I think it's more an issue with the clarity of the spec.

The issue we have is that we are using `document.importNode()` on the content of a Template Element, which causes custom elements in the newly created DocumentFragment to upgrade. Our code depends on the DOM not changing shape during this process, which was (or so we thought) a reasonable assumption since manipulating children is not allowed in the `constructor`. However, since there is nothing indicating that there are cases where it is not allowed in the `attributeChangedCallback`, it is possible that developers accidentally manipulate the children during this callback, which causes our code to break. More clarity from the spec may help alleviate this issue.

As a developer, the current spec reads like "during the constructor, children are not available, but everywhere else, they are", since it is [explicitly documented as a special case for the constructor](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-conformance), but not mentioned anywhere else. I think it would be beneficial to have some sort of note explaining that children may not be yet be attached at other points in the lifecycle.

-- 
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/767#issuecomment-429679140