While Promises would address this concern, I'm reluctant to go with that solution because it imposes yet-another-polyfill-dependency on the web component polyfills/libs. If Promises had preceded Web Components by a few years, and were presently at 80-90% penetration, it would be a different story - but as it stands, I don't think it is the most sensible route.
On Thu, Sep 26, 2013 at 10:35 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote: > I am not sure I entirely understand the problem, but generally ready > events should be promises instead, since they allow you to subscribe even > after the promise has been fulfilled and then still get called back. That > sounds like it would be helpful for those users. > > I believe the new font load events spec is making good use of them for > exactly this purpose. > > > On 27 Sep 2013, at 01:29, "Daniel Buchner" <dan...@mozilla.com> wrote: > > > > > > We're seeing issues with custom element ready state awareness under > various common async load patterns like AMD, CommonJS, etc. Essentially, > when a developer brings in their definitions via one of these systems, the > DOMComponentsLoaded/WebComponentsReady event has already fired, leaving > them with race conditions. There was previously an event that fired for > _every_ element node when each one was ready, and it was pulled due to > various feasibility issues (which is understandable). The proposal here is > different: fire one event (customelementready?) when all known in-source > elements of a type/name are parsed and ready for interaction, *regardless > of when that occurs*. > > > > The use case here is simple: > > > > Let's say a dev defines a new custom element with document.register() 10 > minutes after the page is loaded. Unphased by the fashionably late arrival > of a new custom element definition, the parser crawls through the in-source > elements, augments any matching nodes, and fires a single event when > finished with the lot of them. There would be a property on the event > (tagName, customElementName?) to inform the developer as to what type of > custom element was ready for interaction. > > > > Make sense? Thoughts? (do we already have this covered some other way?) > > > > - Daniel > >
