- From: <bugzilla@jessica.w3.org>
- Date: Tue, 27 Aug 2013 02:15:03 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22928
--- Comment #2 from Dominic Cooney <dominicc@chromium.org> ---
(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>.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 27 August 2013 02:15:05 UTC