> > 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. On Wed, Feb 19, 2014 at 10:27 PM, Dominic Cooney <[email protected]>wrote: > 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 <[email protected]> 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 <[email protected]> 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<http://www.polymer-project.org/discuss.html?place=msg%2Fpolymer-dev%2Fqkl8l3c_SUU%2FGBPs9uOEIk4J>, >>> 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. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=23839> Now > that I look in the spec, I think this > change<https://github.com/w3c/webcomponents/commit/1d4c8e006a7b07c1f5ad36ed029505b37d41423f>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<https://code.google.com/p/chromium/issues/detail?id=339431> > . > > >> 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 [email protected]. >>> 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. >>> >> >> > > > -- > <http://goto.google.com/dc-email-sla> > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CA%2BrMWZgnbfV0tYFDk6oueVns8cEE%3DEjpqH81c9xc_BJAE9zMsA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
