Don't invoke document.register before CustomElements.ready about core

[smcmurray]

Actually, checking for document.readyState === 'complete' isn't enough when using Polymer. We should check for CustomElements.ready.

And we need a WebComponentsReady event listener, not a DOMContentLoaded listener. Polymer fires a WebComponentsReady event when it sets CustomElements.ready.

[csuwildcat]

X-Tag linens for WebComponentsReady as the trigger for DOMComponentsLoaded
;)
On Oct 1, 2013 9:15 AM, "smcmurray" [email protected] wrote:

Actually, checking for document.readyState === 'complete' isn't enough
when using Polymer. We should check for CustomElements.ready.

And we need a WebComponentsReady event listener, not a DOMContentLoaded
listener. Polymer fires a WebComponentsReady event when it sets
CustomElements.ready.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-25464715
.

[smcmurray]

@csuwldcat Yes, I noticed that DOMComponentsLoaded triggers from a WebComponentsReady event.

Btw, googlearchive/CustomElements#65 points to some problems with Polymer's WebComponentsReady.

How implementation-specific are CustomElements.ready and WebComponentsReady? Are those what we want to use?

[csuwildcat]

Ugh, I told the Google folks to add the interactive state check a long time
ago. I'll ping their team again.
On Oct 1, 2013 9:35 AM, "smcmurray" [email protected] wrote:

@csuwldcat https://github.com/csuwldcat Yes, I noticed that
DOMComponentsLoaded triggers from a WebComponentsReady event.

Btw, https://github.com/Polymer/CustomElements/pull/65/files points to
some problems with Polymer's WebComponentsReady.

How implementation-specific are CustomElements.ready and
WebComponentsReady? Are those what we want to use?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-25466508
.

[smcmurray]

https://github.com/smcmurray/core/blob/WebComponentReady/src/core.js invokes document.register from an event handler.

This complicates the return value of xtag.register

[csuwildcat]

@smcmurray this has nothing to do with the X-Tag code catching WebComponentsReady and dispatching its own event, it's an issue with the polyfill bootstrapping code. I'm going to close out this issue in favor of an issue I just filed with the CustomElements polyfill: https://github.com/Polymer/CustomElements/issues/68

[smcmurray]

@csuwldcat Separate from the issue of interactive readystate, there is still the issue that document.register can't be invoked until CustomEvents.ready. That's an x-tag issue, which among other things complicates the return value of xtag.register.

[csuwildcat]

"Separate from the issue of interactive readystate, there is still the issue that document.register can't be invoked until CustomEvents.ready. That's an x-tag issue, which among other things complicates the return value of xtag.register."

X-Tag is loaded after the polyfill, so document.register() is defined. In the polyfill, they cache the registrations and call them when the polyfill is ready to do so. All X-Tag requires is that doc.register() be defined.