> On Jan 14, 2015, at 10:41 AM, Domenic Denicola <d...@domenic.me> wrote: > > From: Ryosuke Niwa [mailto:rn...@apple.com] > >> See Boris' responses in another thread [1] and [2]. Jonas outlined how this >> could work in the same thread [3] > > Thanks for the references. But avoiding this problem is exactly what Arv and > I were talking about. > > The mechanism that createdCallback (and all other custom element callbacks) > operate via is to batch up all user code after the parser, but before > returning control to script. So in the example of setting innerHTML then > reading it on the next line, you let the parser run, *then* run the > constructors, then run the next line. > > Again, I might be missing something, but if you just do > s/createdCallback/constructor in the existing spec, I think you get what > we're describing.
Let me restate the problem using an example. Suppose we're parsing <my-element></my-element><my-other-element></my-other-element>. Once the HTML is parsed, the DOM tree is constructed with two DOM elements. Now we call the constructors on those elements. Without loss of generality, let's assume we're doing this in the tree order. We call the constructor of my-element first. However, inside this constructor, you can access this.nextSibling after calling super(). What's nextSibling in this case? An uninitialized my-other-element. The only way around this would be constructing the tree (or connecting elements) only after constructors are called. This is not how createdCallbacks are called. - R. Niwa
