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

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

Received on Friday, 27 September 2013 05:36:13 UTC