This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22928 - [Custom]: Callbacks timing and HTML Imports
Summary: [Custom]: Callbacks timing and HTML Imports
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
: 23069 (view as bug list)
Depends on:
Blocks: 14968
  Show dependency treegraph
 
Reported: 2013-08-13 00:00 UTC by Dimitri Glazkov
Modified: 2013-08-30 22:47 UTC (History)
3 users (show)

See Also:


Attachments

Description Dimitri Glazkov 2013-08-13 00:00:17 UTC
This feature is probably more relevant to custom elements than imports, so putting it into custom elements pile.

Consider this situation:

x-foo.html:
<polymer-element name="x-bar">
...

index.html:
<script> document.register('polymer-element', ...
...
<link rel=import href="x-foo.html">
...
<x-foo></x-foo>

The desired created callback order here is:

polymer-element
x-foo

However, since imports are loaded asynchronously, it's pretty likely that the order will actually be:

x-foo
polymer-element

... which will result in sadness (polymer-element registers x-foo).

It smells like we need some sort of extra-ordering to callbacks for imports?
Comment 1 Dimitri Glazkov 2013-08-26 16:50:11 UTC
*** Bug 23069 has been marked as a duplicate of this bug. ***
Comment 2 Dominic Cooney 2013-08-27 02:15:03 UTC
(In reply to comment #0)
> Consider this situation:
> 
> x-foo.html:
> <polymer-element name="x-bar">
> ...
> 
> index.html:
> <script> document.register('polymer-element', ...
> ...
> <link rel=import href="x-foo.html">
> ...
> <x-foo></x-foo>
> 
> The desired created callback order here is:
> 
> polymer-element
> x-foo
> 
> However, since imports are loaded asynchronously, it's pretty likely that
> the order will actually be:
> 
> x-foo
> polymer-element

How would that arise? No callbacks for x-foo happen until it is registered. If the polymer-element is the thing that registers x-foo, then the callback order must be polymer-element, x-foo.

The example on bug 23069 is more persuasive...
 
> It smells like we need some sort of extra-ordering to callbacks for imports?

My gut feeling is that <element> was put on hiatus because of timing complexity, and we're bringing the complexity back because someone wants to wrap document.register into a declarative form. In particular, imports aren't special; wouldn't you have the same issue with async external scripts?

I think any ordering we define is going to be complex. Instead I think we should either:

A. Do nothing. <polymer-element> can define its own system for deferring until base definitions are available.

B. Add an event publicising when a definition is registered. Then <foo-element> can interoperably wait until a definition is available.

If a page needs to synchronize with imports, it should do it with <script>.
Comment 3 Dimitri Glazkov 2013-08-30 22:47:34 UTC
https://dvcs.w3.org/hg/webcomponents/rev/4bf5aad1b9cb