situations where custom elements get registered and upgraded?

[Eric Bidelman]

TL;DR

To ajaxify pp.org, I've been trying to test custom elements in an XHR'd document (e.g. xhr.responseType='document'). The elements don't pick up their element definitions from the main document. Why?

---

I threw together http://jsbin.com/gaquyeha/1/edit to test when/where custom elements are registered and upgraded. Some of the results are surprising and I'm hoping someone can shed light. I also might be in crazy town.

View of the console from http://jsbin.com/gaquyeha/1/edit.

TEST 1:<polymer-ajax> declared in main document runner-3.11.7.min.js:1

✔ not an HTMLUnknownElement runner-3.11.7.min.js:1

✔ go() is defined runner-3.11.7.min.js:1

TEST 2: <polymer-ajax> in a <template> in the main document runner-3.11.7.min.js:1

✔ not an HTMLUnknownElement runner-3.11.7.min.js:1

✘ go() is defined runner-3.11.7.min.js:1

TEST 3: <polymer-ajax> in a newly created document runner-3.11.7.min.js:1

✔ not an HTMLUnknownElement runner-3.11.7.min.js:1

✔ go() is defined runner-3.11.7.min.js:1

TEST 4: <polymer-ajax> in an XHR'd document runner-3.11.7.min.js:1

✘ not an HTMLUnknownElement runner-3.11.7.min.js:1

✘ go() is defined runner-3.11.7.min.js:1

TEST 1: Expected.

TEST 2:  according to Dominic, custom elements in <template> are inert and don't pick up the definitions in the main document. These results indicate polymer-ajax gets registered but isn't upgraded. Why?

TEST 3: Expected.

TEST 4: an XHR'd document (e.g. xhr.responseType='document') doesn't pick up the definitions and the elements are not upgraded. Why?

Thanks,

Eric

[Steve Orvell]

Test 2 is expected. Templates are intended to be inert so it makes sense that elements inside them do not upgrade. Upgrading these elements would be a performance penalty.

Test 4: I'm not sure this behavior is well defined, but I'm sure Dominic knows more. If it's not defined, perhaps we can post a spec bug. It does indeed seem convenient to me that these documents use the main document's element registry.

Eventually, HTMLImports will be ideal for this. Right now polymer prevents upgrade inside imports because test 2 is not yet fully supported under native custom elements.

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CACGqRCAyvD58tc_R15xGfAgr2MZPCHSYhcTaZYW1aFx36E-VhA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Eric Bidelman]

On Tue, Feb 18, 2014 at 1:10 PM, Steve Orvell <sor...@google.com> wrote:

Test 2 is expected. Templates are intended to be inert so it makes sense that elements inside them do not upgrade. Upgrading these elements would be a performance penalty.

What confused me from that thread was: "...want the Custom Elements in the template to pick up the definitions registered with the main document...". I see now that "pick up the definitions" translates to "upgrade to their definitions".

 

Test 4: I'm not sure this behavior is well defined, but I'm sure Dominic knows more. If it's not defined, perhaps we can post a spec bug. It does indeed seem convenient to me that these documents use the main document's element registry.

Dominic, any insight to the ajax case?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CA%2BrMWZjDnia%3DEu1owPoyrK9xTcK-Y0Rea1_YiV%2Br%3D072a9Y%3DVQ%40mail.gmail.com.

[Dominic Cooney]

This is defined here: <http://w3c.github.io/webcomponents/spec/custom/#creating-and-passing-registries>.

In general, something like "X not a foo" in red is hard to understand because it's a double-negative. Something like "X should be a foo" in red might be easier to understand.

More inline.

On Wed, Feb 19, 2014 at 6:10 AM, Steve Orvell <sor...@google.com> wrote:

Test 2 is expected. Templates are intended to be inert so it makes sense that elements inside them do not upgrade. Upgrading these elements would be a performance penalty.

Test 4: I'm not sure this behavior is well defined, but I'm sure Dominic knows more. If it's not defined, perhaps we can post a spec bug. It does indeed seem convenient to me that these documents use the main document's element registry.

This changed in Chrome 34, FWIW. More below.

 

Eventually, HTMLImports will be ideal for this. Right now polymer prevents upgrade inside imports because test 2 is not yet fully supported under native custom elements.

On Tue, Feb 18, 2014 at 12:40 PM, Eric Bidelman <ebi...@gmail.com> wrote:

TL;DR

To ajaxify pp.org, I've been trying to test custom elements in an XHR'd document (e.g. xhr.responseType='document'). The elements don't pick up their element definitions from the main document. Why?

---

I threw together http://jsbin.com/gaquyeha/1/edit to test when/where custom elements are registered and upgraded. Some of the results are surprising and I'm hoping someone can shed light. I also might be in crazy town.

View of the console from http://jsbin.com/gaquyeha/1/edit.

TEST 1:<polymer-ajax> declared in main document runner-3.11.7.min.js:1

✔ not an HTMLUnknownElement runner-3.11.7.min.js:1

✔ go() is defined runner-3.11.7.min.js:1

TEST 2: <polymer-ajax> in a <template> in the main document runner-3.11.7.min.js:1

✔ not an HTMLUnknownElement runner-3.11.7.min.js:1

✘ go() is defined runner-3.11.7.min.js:1

TEST 3: <polymer-ajax> in a newly created document runner-3.11.7.min.js:1

✔ not an HTMLUnknownElement runner-3.11.7.min.js:1

✔ go() is defined runner-3.11.7.min.js:1

TEST 4: <polymer-ajax> in an XHR'd document runner-3.11.7.min.js:1

✘ not an HTMLUnknownElement runner-3.11.7.min.js:1

✘ go() is defined runner-3.11.7.min.js:1

TEST 1: Expected.

TEST 2:  according to Dominic, custom elements in <template> are inert and don't pick up the definitions in the main document. These results indicate polymer-ajax gets registered but isn't upgraded. Why?

This is what "we" discussed; IIRC Raf argued that template documents should have a registry, and Scott argued that elements in a template shouldn't upgrade, and where we ended up was that template documents did have a registry but didn't share the registry with the main document. Here's the spec bug. Now that I look in the spec, I think this change went further and said template documents shouldn't have a registry at all. We should fix the spec or the implementation. Any objection to making the implementation match the spec?

 

TEST 3: Expected.

TEST 4: an XHR'd document (e.g. xhr.responseType='document') doesn't pick up the definitions and the elements are not upgraded. Why?

This is because "In all other cases, new documents must not have a registry." XHR's response document is one of these other cases. FWIW this was fixed recently.

 

Thanks,

Eric

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CACGqRCAyvD58tc_R15xGfAgr2MZPCHSYhcTaZYW1aFx36E-VhA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

[Steve Orvell]

we ended up was that template documents did have a registry but didn't share the registry with the main document.

Yes, this is what we want.

This is because "In all other cases, new documents must not have a registry." XHR's response document is one of these other cases.

This makes sense. Thanks for the explanation Dominic. I think we've agreed that the longer term plan is to have an api for sharing/modifying element registries. Associating a registry with an XHR'd document will be an interesting use case for us to consider when we design that api.

In the meantime, to get custom elements out of XHR'd documents, the user must re-create the dom in the XHR document in a document with the desired registry.

HTMLImports are a better fit for this kind of use case since imported documents do share the main document's registry.

[Dominic Cooney]

On Fri, Feb 21, 2014 at 12:30 AM, Steve Orvell <sor...@google.com> wrote:

we ended up was that template documents did have a registry but didn't share the registry with the main document.

Yes, this is what we want.

OK, I have reopened spec bug 23839.

I think the implementation is the way you want it so nothing to change there. This needs a spec change.

--