Re: [webcomponents] Per-type ready event for Custom Elements

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 <
domenic@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" <daniel@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
>
>