On Dec 8, 2013, at 5:21 PM, Dominic Cooney <domin...@google.com> wrote: > On Fri, Dec 6, 2013 at 12:49 PM, Ryosuke Niwa <rn...@apple.com> wrote: > On Dec 5, 2013, at 7:32 PM, Scott Miles <sjmi...@google.com> wrote: > > >> We don't think decoupling custom elements and shadow DOM completely is > > >> useful given that most important and natural use cases of custom > > >> elements involve the use of shadow DOM. > > > > Separating concerns is always useful, especially when it involves > > contentious standards. > > > > I also would like to point out that Mozilla's X-Tags/Brick custom elements > > library is built entirely without Shadow DOM. > > Could you elaborate on what value does document.register add in that world? > Web developers could use mutation observers to manipulate elements of a given > name and add a bunch of properties already. > > Custom Elements adds a lot of value over Mutation Observers. Mutation > Observers are great, but for other things. A couple of the benefits are: > > Instances get callbacks/the right prototype more eagerly than they do with > Mutation Observers. If element authors follow local discipline, they end up > with a composition of elements that is consistent. This makes it easier to > create more robust applications. Technically, more eager callbacks (more > eager than typical uses of Mutation Observers, but less eager than Custom > Elements) are possible with Mutation Observers through takeRecords. However > it turns out this is infeasible because developers end up cargo-culting > takeRecords. (It doesn't work? Add a call to the thing that flushes changes > with takeRecords! Something else broke? ...)
That seems like a problem/limitation with mutation observers that we should fix regardless of custom elements. > It is easier to get consistent availability of the element than it is with > Mutation Observers. For example, Custom Elements are upgraded even if the > element instance is not in the document. With Mutation Observers this is > extremely difficult because it requires registering observers as subtrees are > disconnected... and modifications including disconnections may have happened > in the interim. With Custom Elements, the responsibility of understanding how > operations affect elements lies with the UA, which has comprehensive > knowledge of this now and into the future, and not with the author. On the other hand, this is a good point. Thanks for the clarification. If we should probably include it in http://w3c.github.io/webcomponents/spec/custom/#motivations - R. Niwa
