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

On Fri, Sep 27, 2013 at 2:27 PM, 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,
>

What spec is DOMComponentsLoaded/WebComponentsReady in? I think that this
is part of x-tags and not anything under the purview of WebApps.

I see this bug, but I don't see any clear conclusions on that: <
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20189>


> 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
>



-- 
<http://goto.google.com/dc-email-sla>