Ready/created, inserted, removed, and attributeChanged are the minimum must-havs for developers - we heavily rely on each one of these callbacks in the components we've developed thus far. The usefulness of this API is neutered without these hooks - they're table stakes, plain and simple. Jonas, how are non-bubbling callbacks so crushing? Are we honestly designing for the dev who decides to ignore all the best practices, tutorials, evangelist demos, etc and run a crushing loop every time an attribute value changes despite the obvious idiocy of their actions? This is not an API that will be widely used by every Bobby Tables and Samantha Script Kitty on the block - let's not design API features and 99%-case ergonomics for a phantom developer persona that is a fringe-at-best factor.
On Fri, Mar 8, 2013 at 10:49 AM, Jonas Sicking <jo...@sicking.cc> wrote: > On Mar 6, 2013 2:07 PM, "Dimitri Glazkov" <dglaz...@google.com> wrote: > > > > Here are all the callbacks that we could think of: > > > > * readyCallback (artist formerly known as "create") -- called when the > > element is instantiated with generated constructor, createElement/NS > > or shortly after it was instantiated and placed in a tree during > > parser tree construction > > > > * attributeChangedCallback -- synchronously called when an attribute > > of an element is added, removed, or modified > > This will have many of the same problems that mutation events had. I > believe we want to really stay away from synchronous. > > So yes, this looks dangerous and crazy :-) > > / Jonas >
