- 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