On Fri, Feb 21, 2014 at 12:30 AM, Steve Orvell <[email protected]> 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<https://www.w3.org/Bugs/Public/show_bug.cgi?id=23839> . I think the implementation is the way you want it so nothing to change there. This needs a spec change. > 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> >> > > -- <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/CAHnmYQ_JBtgXRkzq3doOzypWHfYQ%3D%3D5_%3Duw7A7zOcRSUBr-P5w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
